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 continue). 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.

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 & Continue of Motion Commands

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

Table 71 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.
Continue	Resumes execution after a pause. The robot continues from the position where it was paused and processes the remaining commands in the queue.
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 continued. To resume operation, new motion commands must be sent to the robot after the robot reaches standstill.

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.