Aborting versus Buffered Modes

Some of the Function Blocks have an input called BufferMode. With this input, the Function Block can either work in a Non-buffered mode (default behavior) or in a Buffered mode. The difference between those modes is when they should start their action:

  • A command in a non-buffered mode acts immediately, even if this interrupts another motion,
  • A command in a buffered mode waits till the current Function Block sets its output Done (or InPosition, InVelocity…).

There are several options for the buffered mode. For this reason, this input is an ENUM of type MC_BUFFERMODE. The following modes have been identified:

  • McAborting:Default mode without buffering. The next Function Block aborts an ongoing motion and the command affects the axis immediately.
  • McBuffered:The next Function Block affects the axis as soon as the previous movement is Done There is no blending.
  • McBlendingLow:The next Function Block controls the axis after the previous Function Block has finished (equivalent to MC_Buffered), but the axis will not stop between the movements. The velocity is blended with the lowest velocity of both commands (1 and 2) at the first end-position (1).
  • McBlendingPrevious: Blending with the velocity of Function Block 1 at end-position of Function Block 1.
  • McBlendingNext:Blending with velocity of Function Block 2 at end-position of Function Block 1.
  • McBlendingHigh: Blending with highest velocity of Function Block 1 and Function Block 2 at end-position of Function Block 1.

ABB specific extensions are allowed after these defined Enums.

The following examples describe the different behavior of these modes:

Example 1: Standard behaviour of 2 following absolute Movements

../_images/27b26ee92c0363790a33139001dd89b5

Basic example with two MC_MoveAbsolute on same axis

../_images/4bd9e27e2c0365dc0a33139001351044

Timing diagram for example above without interference between Function Block 1 and Function Block 2

Example 2: Aborting Motion

../_images/5c1b4b622c0369fd0a331390005909e7
../_images/c114aa972c0368190a3313900114bca1

Timing diagram for example above with Function Block 2 interrupting Function Block 1 (McAborting Mode)

Example 3: Buffered Motion

../_images/d7d38a1c2c0372550a33139000771ec0
../_images/45aa50102c036d810a331390008579e0

Timing diagram for example above in Buffered Mode (Stopping to velocity 0 and starting Function Block 2 at that point without delay)

The following table shows an overview of the effects on the defined Function Blocks:

Function Block Can be specified as a buffered command Can be followed by a buffered command Relevant signal to activate the next buffered Function Block
MC_MoveAbsolute Yes Yes Done
MC_MoveRelative Yes Yes Done
MC_MoveAdditive Yes Yes Done
MC_MoveSuperimposed Yes Yes –
MC_MoveVelocity Yes Yes In Velocity
MC_Home Yes Yes Done
MC_Stop Yes Yes Done AND NOT Execute
MC_Power Yes Yes Status
MC_PositionProfile Yes Yes Done
MC_VelocityProfile Yes Yes Done
MC_AccelerationProfile Yes Yes Done
MC_CamIn Yes Yes - (in single mode) EndOfProfile
MC_CamOut Yes Yes Done
MC_GearIn Yes No –
MC_GearOut Yes Yes Done
MC_Phasing Yes Yes –

Note

The (administrative) Function Blocks not listed here are basically not buffered, nor can be followed by a buffered Function Block. However, the supplier may choose to support the various buffering / blending modes.

If an on-going motion is aborted by another movement, it can occur that the braking distance is not sufficient due to deceleration limits.

In rotary axis, a modulo can be added. A modulo axis could go to the earliest repetition of the absolute position specified, in cases where the axis should not change direction and reverse to attain the target position.

In linear systems, the resulting overshoot can be resolved by reversing, as each position is unique and therefore there is no need to add a modulo to reach the correct position..