5.1. Motion Command Handling

Motion commands in voraus Robot Control are managed through an internal command queue. Commands sent by the client application are placed in a first-in, first-out (FIFO) queue and executed sequentially. This section describes how motion commands are queued, executed, and controlled.

Note

Motion commands are distinct from system commands (such as pause, stop, and unpause). System commands are managed in a separate queue and are therefore not placed in the motion command queue. At most one system command is processed per voraus Robot Control cycle.

Because both queues are processed in parallel, the execution order is only guaranteed within each queue, not between them. A motion command may therefore be executed before an earlier system command, even if the system command was sent first.

5.1.1. Queue Overview

When the client application sends a motion command (e.g., MoveJoints, MoveLin, or MoveCirc), the command is placed at the end of the motion command queue. The queue holds up to 100 motion commands at a time. Commands are processed in the order they were received (FIFO principle).

The start position of each queued motion command is automatically derived from the target position of the preceding command. This allows the client application to send multiple consecutive commands without waiting for each individual motion to complete.

Note

Jogging and move commands are mutually exclusive and cannot be queued together. Before switching between the two, the currently executing command must have completed. For example, to run MoveLin, then jogging, then MoveCirc, the client must wait for MoveLin to finish before starting jogging, and wait for jogging to finish before sending MoveCirc.

Queue Capacity

If the motion command queue is full, additional commands are not queued. Client applications should treat the enqueue attempt as failed and retry once capacity becomes available (for example by tracking CommandId progress, see section Command Tracking for more details).

Prerequisites for Command Acceptance

Motion commands are only accepted and queued when the following conditions are met:

  • The robot is in READY or ACTIVE state.

  • No stop operation is currently in progress.

  • Position streaming mode is not active (motion commands and position streaming are mutually exclusive).

  • No conflicting command type is active (jogging and move commands are mutually exclusive; the currently executing command must have completed before switching between the two).

If these conditions are not met, incoming motion commands are not queued.

5.1.2. Command Execution

Motion commands are executed automatically once they are queued. There is no explicit “start” command required to begin execution of queued motion commands. As soon as the robot is in a valid state and motion commands are available in the queue, the motion planner begins processing them. While a pause is requested, the commands are still planned (and the robot may enter ACTIVE), but the robot holds its position until Unpause is sent (see section Pause, Stop & Unpause of Motion Commands).

Execution Pipeline

The execution of a motion command proceeds through the following stages:

  1. Queued: The command has been received and placed in the motion command queue.

  2. Preparation: The motion planner calculates the trajectory for the command. Up to the configured lookahead horizon (lookahead_horizon, see section System Parameter) commands ahead are prepared in advance (lookahead), enabling smooth transitions such as blending between consecutive segments.

  3. Execution: The prepared trajectory is interpolated and sent to the robot drives.

The robot transitions from READY to ACTIVE state when the first motion command begins execution. After the last queued command has been completed and the robot reaches standstill, it transitions back to READY.

Continuous Command Streaming

Because multiple commands can be queued and prepared in advance, the client application can continuously send motion commands while the robot is in motion. This enables uninterrupted execution of complex motion sequences without pauses between individual commands, especially when combined with blending (see Blending Overview).

5.1.3. Pause, Stop & Unpause of Motion Commands

The client application can control the execution of queued motion commands using the following system commands:

Table 78 Motion control commands

Command

Behavior

Pause

Pauses the robot’s motion. The robot decelerates on the current path until standstill. The motion command queue is preserved and execution can be resumed. A pause can also be requested while the robot is idle (READY). Motion commands sent after the pause has been accepted (RobotMotionPauseRequested = true) are accepted and planned, but the robot holds its position until Unpause is sent. Because system and motion commands use separate queues, wait for RobotMotionPauseRequested = true before sending motion commands that must not start directly.

Unpause

Resumes execution after a pause. The robot continues from the position where it was paused and processes the remaining commands in the queue. Without a requested pause, the Unpause method call is rejected with a bad status code.

Stop

Stops the robot’s motion. The robot decelerates on the current path until standstill. Subsequently, all remaining motion commands in the queue are discarded and the motion cannot be resumed. To resume operation, new motion commands must be sent to the robot after the robot reaches standstill. A requested pause is discarded as well.

Pause State

  • 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. If the robot changes its state at the same moment, so that the request is not rejected anymore, it raises an error.

  • RobotMotionPauseRequested is true from the moment a pause is accepted until Unpause or until the pause is discarded, also while the robot is still decelerating. Check IsRobotInStandstill to distinguish a pausing from a paused robot.

  • A requested pause is discarded without resuming the motion by:

    • a Stop 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).

  • Jogging: a Pause or Stop decelerates a running jog to standstill within the configured user stop 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 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 cannot be paused, a Pause during an active position stream is rejected. If the stream starts at the same moment, so that the request is not rejected, it raises an error and stops the stream. Starting a position stream while a pause is requested raises an error as well.

5.1.4. Command Tracking

Each motion command accepts a CommandId parameter (an unsigned 32-bit integer) that can be freely assigned by the client application. This identifier allows tracking the progress of individual commands through the queue.

The following information is provided by the system:

  • Current command: The CommandId of the motion command that is currently being executed.

  • Last successful command: The CommandId of the most recently completed motion command, along with a timestamp indicating when it finished.

By assigning unique identifiers to each motion command, the client application can determine which commands have been completed and which are still pending in the queue.