6.7. Start, Stop, Pause & Unpause

In addition to sending individual motion commands, the client application controls the execution lifecycle of the queued motion through a small set of system commands. These commands can pause and unpause an ongoing motion, or stop it entirely.

Unlike motion commands (see Queue Overview), these are system commands: they take effect immediately and are not placed in the motion command queue. A short summary of pause, unpause, and stop is given in Pause, Stop & Unpause of Motion Commands; this section describes the full execution lifecycle in detail.

Table 97 Execution lifecycle commands

Command

OPC UA method

Behavior

Start

(implicit)

There is no dedicated start command. Queued motion commands start executing automatically once the robot is in a valid state. See Starting Motion.

Pause

Pause

Decelerates the robot on the current path until standstill and holds its position, also for motion commands sent afterwards. Only the interpolation is paused; the motion command queue continues to be processed, so new motion commands are accepted and planned, but not executed until Unpause. A pause can therefore be used to plan several motion commands before they are executed. See Pause & Unpause.

Unpause

Unpause

Lifts a requested pause. The robot resumes the interpolation from the position at which it came to a standstill during the pause. See Pause & Unpause.

Stop

Stop

Decelerates the robot on the current path until standstill and discards all remaining motion commands and a requested pause. The motion cannot be resumed. See Stop.

Table 98 contrasts Pause and Stop directly; see Pause & Unpause and Stop for more details.

Table 98 Pause versus Stop

Aspect

Pause

Stop

Accepted in

READY and ACTIVE, not while a stop is in progress or a position stream is active

Not restricted to a specific state

Deceleration

On the planned path to standstill

On the planned path to standstill

Interpolation and motion command queue

Interpolation is preserved; the motion command queue continues to be processed, new motion commands are accepted and planned, but not executed

Both are discarded; new motion commands are discarded until the stop is completed

Resumable

Yes, via Unpause

No, new commands must be sent

Resulting state

Remains READY or ACTIVE; the robot holds its position

Returns to READY; error state during an active position stream

Note

Pause, unpause, and stop are executed as a userStop and therefore always act on the planned path. The stop method of the userStop is fixed to an on-path deceleration and cannot be changed; only its duration is configurable. See Robot Stops for how to configure the userStop duration.

6.7.1. Starting Motion

There is no dedicated start command. Queued motion commands begin executing automatically as soon as the robot is in a valid state and at least one command is available in the motion command queue (see Command Execution). The client application therefore only needs to enqueue motion commands; it does not have to trigger their execution separately.

When the first queued command starts executing, the robot transitions from READY to ACTIVE state. Once the queue has been emptied, it returns to READY. The general prerequisites that must be met before a motion command is accepted and started are described in Prerequisites for Command Acceptance.

Note

Because execution starts implicitly, a previously requested pause remains in effect even for motion commands that are enqueued after the pause, also if the pause was requested in READY state. Newly queued commands are planned and the robot may enter ACTIVE state, but it holds its position until an Unpause is sent.

6.7.2. Pause & Unpause

The pause command (Pause) halts an ongoing motion without discarding it. The robot decelerates on the planned path to standstill within the configured userStop duration (see Robot Stops and Path Stop Time-Based), while the motion command queue and the remaining trajectory are preserved.

The unpause command (Unpause) lifts a requested pause and resumes the interpolation from the position at which the robot came to a standstill during the pause. The robot accelerates on the planned path within the same configured userStop duration and continues with the remaining commands in the queue. Because the motion is resumed on the original path, no re-planning is required.

In contrast to the stop command, motion commands can still be received and queued while a pause is requested. Such commands are accepted and planned, and the robot may enter ACTIVE state, but the robot holds its position until Unpause is sent (see Queue Overview).

Table 99 Pause and Unpause at a glance

Command

Effect

Pause

Decelerates on the current path to standstill and holds the position, also for motion commands sent afterwards. Queue and trajectory are preserved. The robot remains in regulation and stays in READY or ACTIVE state.

Unpause

Lifts the pause, resumes the interpolation from the standstill position reached during the pause, and processes the remaining queue.

Accepting and Rejecting Pause and Unpause

  • A Pause is only accepted in the READY or ACTIVE state, not while a stop is being executed and not while a position stream is active. Otherwise the Pause method call is rejected with a bad status code and the robot keeps its state. If the robot changes its state at the same moment, so that the request is not rejected anymore, it raises an error.

  • A repeated Pause while the robot is already pausing or paused is accepted and has no further effect.

  • An Unpause without a requested pause is rejected with a bad status code. In particular, Unpause never cancels a stop.

Discarding a Requested Pause

A requested pause is discarded without resuming the motion by:

  • a Stop (also without an active motion command) or an error stop (including ss1)

  • a monitored standstill or a motion prohibited signal of the safety controller

  • entering any state other than READY or ACTIVE (e.g., regulators switched off, collision reaction, gravitation compensation)

Motion commands sent after the pause has been discarded are executed without an Unpause.

Pause Feedback

The system reports a requested pause to the client application via the status flag RobotMotionPauseRequested. The flag is true from the moment a pause is accepted until Unpause or until the pause is discarded. This includes the deceleration phase and a pause requested in READY state. To distinguish a pausing from a paused robot, additionally check IsRobotInStandstill. The client application can use these flags to reflect the paused state in the voraus.operator.

Note

System and motion commands use separate queues. Wait for RobotMotionPauseRequested = true before sending motion commands that must not start directly.

Note

The commanded values reach standstill at the end of the deceleration, but the robot’s actual position may lag slightly behind, so brief residual motion can occur while it settles onto the last commanded value.

Behavior of Other Motion Types

  • Jogging: A Pause decelerates a running jog to standstill within the configured userStop duration, or faster if the commanded jog acceleration allows it. All jogged axes or Cartesian directions decelerate in the same proportion, so the jogging direction is preserved. While paused, the robot holds its position and jog commands received during the pause do not move it. After Unpause, the robot executes the most recently received jog command with its commanded acceleration, unless that command has already expired.

  • Manually controlled motion commands: They resume after Unpause as long as ContinueManualExecution is still being sent. Otherwise they expire as during motion: the command is discarded, the robot changes to READY and keeps holding its position, and the pause stays requested.

  • Cyclic position commands: Position streams cannot be paused (see Time Override, Pause / Unpause).

6.7.3. Stop

The stop command (Stop) terminates the current motion. As with a pause, the robot decelerates on the current path until standstill (userStop, see Robot Stops). In contrast to a pause, the motion is discarded and cannot be resumed:

  • The preparation of pending motion commands is aborted.

  • All remaining motion commands in the queue are removed.

  • The position stream buffer is reset.

  • A requested pause is discarded, also if no motion command is active (see Pause & Unpause).

While the stop is in progress, motion commands (such as Point-to-Point (PTP), Linear (LIN), Circular (CIRC), jogging, and wait-time commands) are not accepted until the robot is back in READY state. They are silently discarded rather than queued, and no error is raised, so the client application receives no feedback and must resend the command once READY is reached. Other commands, such as setting a digital output, are still processed.

Once the stop is completed, the robot returns to READY state and accepts new motion commands again. To resume operation, the client application must therefore send new motion commands (no reset is required for a userStop, see Robot Stops). Unlike after a pause, new motion commands are executed without an Unpause. A stop during an active position stream, however, puts the robot into an error state instead of READY (see Interactions & Limitations).

Note

Stop is a userStop and is therefore distinct from an errorStop or a safety stop (ss1). For the full list of stop sources, their priorities, and the resulting post-stop behavior, see Robot Stops.

6.7.4. Interactions & Limitations

The execution lifecycle commands interact with the other motion mechanisms of voraus Robot Control as follows:

  • Motion command queue: Pause and unpause preserve the queue, whereas stop clears it. A key difference is that motion commands can still be received and queued while a pause is requested, but are blocked while a stop is in progress. See Queue Overview and Command Execution.

  • Jogging: Jogging is not part of the motion command queue, but a pause or stop decelerates a running jogging motion as well. While a stop is in progress, jogging commands are ignored. See Jogging.

  • Cyclic position commands / position streaming: Position streams cannot be paused. A Pause during an active position stream is rejected, and starting a position stream while a pause is requested raises an error (see Time Override, Pause / Unpause). The Stop command resets all frames immediately, which puts the robot into an error state. To end a position stream without an error, use StopPositionStream instead (see Stopping Position Stream).

Note

A pause and a stop only produce an immediate, visible deceleration while the robot is moving. A Pause requested in READY state has no immediate effect, but it persists and holds back any motion commands enqueued afterwards until an Unpause is sent (see Starting Motion). An Unpause without a requested pause is rejected (see Pause & Unpause).