6.6. Jogging

Jogging moves the robot continuously as long as a jogging command is repeatedly sent. Unlike the point-to-point (Point-to-Point (PTP)), linear (Linear (LIN)), or circular (Circular (CIRC)) motion commands, jogging does not specify a target pose. Instead, it specifies a velocity that the robot follows until the command is no longer refreshed. This makes jogging well-suited for manually moving the robot, for example during setup or teaching.

Two jogging variants are available:

  • Single-DOF jogging (MoveJogging) moves exactly one degree of freedom (a single axis or a single Cartesian direction) at a time, see Single-DOF Jogging.

  • Multi-DOF jogging (MoveJoggingMultiDof) moves several degrees of freedom simultaneously by specifying a full velocity vector, see Multi-DOF Jogging.

In contrast to the queued motion commands, a jogging command is not placed in the motion command queue (see Queue Overview). It is executed as a continuous command and must be refreshed cyclically to keep the robot moving (see Continuous Command Behavior).

Note

The robot must be in READY or ACTIVE state to accept jogging commands, and no queued motion command may be active or pending. See section Prerequisites for Command Acceptance for more details on the general prerequisites for motion command acceptance, and Error Conditions for jogging-specific conditions.

Note

A pause or stop also decelerates a running jogging motion to standstill within the configured userStop duration. Jogging commands received while a stop is in progress are ignored. For details, see Pause & Unpause and Stop.

6.6.1. Parameters

Single-DOF Jogging

The MoveJogging command moves a single degree of freedom and accepts the following parameters:

Table 95 Single-DOF Jogging Parameters

Parameter

Type

Description

JoggingCS

Integer (enum)

Coordinate system in which the robot is jogged. See Interpretation in Motion Commands. For jogging in the Camera CS, the origin lies at the camera, so a rotational jog rotates the TCP about the camera while the camera position stays fixed.

Direction

Integer

Signed, one-based index of the degree of freedom to move. The absolute value selects the degree of freedom (for example, 1 selects the first axis or the \(X\) direction), while the sign selects the motion direction. The value must not be 0. In the joint coordinate system the absolute value must not exceed the number of axes. In a Cartesian coordinate system it must not exceed 6 and must be consistent with the plausible Cartesian degrees of freedom of the robot, e.g. a SCARA robot does not allow rotation about the \(X\) or \(Y\) axis.

Velocity

Double

Target velocity of the selected degree of freedom. Interpreted in \([\mathrm{rad/s}]\) for rotational degrees of freedom and in \([\mathrm{m/s}]\) for translational degrees of freedom. Must not be negative. The value is capped to the configured jogging limits, see Velocity and Acceleration Limits.

Acceleration

Double

Acceleration used to ramp the selected degree of freedom up to the target velocity. Interpreted in \([\mathrm{rad/s^2}]\) or \([\mathrm{m/s^2}]\) respectively. Must not be negative.

Multi-DOF Jogging

The MoveJoggingMultiDof command moves several degrees of freedom at once. The motion direction of each degree of freedom is derived from the magnitude and sign of its velocity component, so no separate direction parameter is required.

Table 96 Multi-DOF Jogging Parameters

Parameter

Type

Description

JoggingCS

Integer (enum)

Coordinate system in which the robot is jogged. See Interpretation in Motion Commands. For jogging in the Camera CS, the origin lies at the camera, so a rotational jog rotates the TCP about the camera while the camera position stays fixed.

Velocity

Array of double

Target velocity for each degree of freedom. In the joint coordinate system the array contains one value per axis; in a Cartesian coordinate system it contains 6 values \([v_X, v_Y, v_Z, \omega_X, \omega_Y, \omega_Z]\). Individual components may be negative to select the motion direction. The resulting velocity is capped to the configured jogging limits, see Velocity and Acceleration Limits.

Acceleration

Array of double

Acceleration used to ramp up the motion. In the joint coordinate system the array contains one value per axis. In a Cartesian coordinate system it contains exactly 2 values: the translational acceleration and the rotational acceleration, so that the motion direction remains constant during acceleration. Each value must be greater than 0.

6.6.2. Velocity and Acceleration Limits

Jogging velocities are intentionally limited for manual operation. In addition to the configured velocity limits, the following jogging velocity limits apply:

  • Axes: 25 °/s for rotational axes and 250 mm/s for prismatic axes.

  • TCP: 250 mm/s translational and 25 °/s rotational.

  • Elbow: 250 mm/s translational, if elbow velocity monitoring is enabled for the robot.

These limits apply in all coordinate systems, both when jogging in the joint coordinate system and in a Cartesian coordinate system. For each limit, the lower of the configured velocity limit and the jogging velocity limit is used. The requested velocity is scaled down so that all of these limits are respected. Values exceeding the limits do not cause an error but are reduced to the maximum allowed value.

The requested acceleration is limited as well. When jogging in the joint coordinate system, the acceleration of each axis is capped to the configured axis acceleration limit. When jogging in a Cartesian coordinate system, the requested acceleration is not limited.

The configured robot limits also apply during jogging. For more details on the configurable limits, see Limitations.

6.6.3. Velocity Reduction Near Limits

Unlike the queued motion commands (Point-to-Point (PTP), Linear (LIN), Circular (CIRC)), whose path is already checked against workspace and joint limits during path pre-interpolation before execution, jogging does not specify a target pose and has no planned trajectory. Because of this, jogging has no path preview: there is no advance information about whether continuing the current motion would violate such a limit.

To compensate for the missing path preview, the jogging velocity is continuously and automatically reduced whenever the robot approaches one of the limits below, so that it can always be stopped before the limit is actually violated. This dynamic reduction is independent of, and applied on top of, the fixed jogging velocity caps described in Velocity and Acceleration Limits. It only takes effect within a limit-specific slow-down distance. Except for singularities, it only applies while the robot moves towards the affected limit; motion that leads away from such a limit is not slowed down, even within that distance.

The jogging velocity is reduced when the robot:

  • approaches a kinematic singularity, a pose in which the requested Cartesian velocity would require excessive joint velocities. This only applies to Cartesian jogging; jogging in the joint coordinate system is unaffected, since singularities are a property of the Cartesian mapping. Unlike the other limits, the velocity also remains reduced while the robot moves away from the singularity, until it has left the slow-down area.

  • moves towards a configured axis position limit, either the absolute minimum/maximum position limit of an individual axis or a relative position limit defined between two axes, see User-Defined Limits and Axes Position Limits Relative.

  • moves towards a self-collision, i.e., the distance between two collision volumes of the collision model falls below the configured ReduceDistance for that collision pair, see Collision Model.

  • moves towards a workspace boundary, i.e., a Cartesian constraint, boundary plane, or forbidden volume, see Continuous Jogging.

While Rescue Mode is enabled, the velocity is no longer reduced when approaching a workspace boundary or a self-collision. This allows the robot to be jogged out of a limit that has already been exceeded.

Note

If the robot still reaches a limit despite the reduced velocity, the resulting limit or safety violation triggers the same stop reaction that applies to all other motion, see Error Conditions.

6.6.4. Continuous Command Behavior

Jogging is a continuous, velocity-commanded motion. A single jogging command does not keep the robot moving indefinitely. Each command has a limited lifetime, after which the robot automatically decelerates and comes to a smooth stop.

The lifetime of a jogging command is a configurable timeout (ManualMode_cycles in Table 16, expressed as a number of control cycles). If no new jogging command is received within this timeout, the current command expires and the robot ramps down.

Note

To keep the robot moving, the client application must refresh the jogging command cyclically before its lifetime expires.

As long as new jogging commands are received in time, the robot continues to move at the commanded velocity. As soon as the commands stop arriving, the robot ramps down to standstill using the acceleration of the last received jogging command. While ramping down, the robot’s motion can be resumed by sending a new jogging command (in the same JoggingCS).

Because jogging is executed as a continuous command rather than a queued command, it does not interact with the motion command queue described in Queue Overview. Jogging cannot coexist with queued move commands: there are no queued commands while jogging is active, and move commands (PTP, LIN, CIRC) sent while a jogging command is active are silently ignored rather than queued for later execution.

Note

Jogging, queued move commands (PTP, LIN, CIRC), and position streaming are mutually exclusive; only one of them may be active at a time. A jogging command sent while position streaming is active is rejected, and vice versa; likewise, move commands and jogging cannot be active simultaneously. See Error Conditions and Prerequisites for Command Acceptance for the corresponding conditions.

6.6.5. Error Conditions

The OPC UA methods for jogging do not report whether a command is accepted. The command is evaluated afterwards, when it is processed in the motion kernel cycle. Depending on the condition, it then raises an error, is ignored silently, or is executed. Errors can also arise later, while the motion is executed. It is important to distinguish between these cases, because they require different handling by the client application. See also Prerequisites for Command Acceptance for the general prerequisites that apply to all motion commands.

Errors on Command Processing

Because jogging is a continuous command that is not queued or planned ahead (see Continuous Command Behavior), all parameters and preconditions are validated when the command is processed. When one of the following conditions applies, the command is not executed and an error is raised.

  • A queued motion command is still being executed when a new jogging motion is started.

  • Position streaming mode is active.

  • An invalid coordinate system value is specified.

  • The Direction is 0, or its absolute value exceeds the number of axes (joint coordinate system) or 6 (Cartesian coordinate system). (single-DOF jogging only)

  • The Velocity is negative. (single-DOF jogging only)

  • The Acceleration is negative. (single-DOF jogging only)

  • The length of the Velocity array does not match the expected number of degrees of freedom. (multi-DOF jogging only)

  • The length of the Acceleration array does not match the expected size (one value per axis in the joint coordinate system, or two values in a Cartesian coordinate system). (multi-DOF jogging only)

  • A value in the Acceleration array is not greater than 0. (multi-DOF jogging only)

The parameters are validated before the conditions listed under Ignored Commands are evaluated. An invalid jogging command therefore raises an error even if it would otherwise be ignored, for example in automatic mode.

Ignored Commands

In the following situations, incoming jogging commands are ignored silently: the robot does not move, no error is raised, and only a warning is written to the log.

The current robot state does not permit a new motion:

  • The robot is not in READY or ACTIVE state.

  • The robot driver is executing a service routine.

  • A stop is in progress.

  • Queued motion commands are waiting for or undergoing path preparation.

Jogging is a manually controlled motion and is only executed when the robot is in an operating mode that permits manual motion. Jogging commands are therefore also ignored if:

  • The robot is in automatic mode. Jogging is only possible in manual mode.

  • The enabling device is required but not held in its center (enabling) position.

  • Motion is currently prohibited by the safety controller (for example after a safety stop).

  • An axis indexing (referencing) procedure is in progress.

If the operating mode or safety state changes while the robot is jogging, the active jogging command is not aborted but runs out as described in Continuous Command Behavior, unless the safety controller stops the robot.

These conditions are re-evaluated for every incoming jogging command. As long as the client application keeps sending jogging commands, each one is either executed, if the robot state, operating mode and safety state permit motion, or ignored, if they do not.

Errors during Motion Execution

Unlike the queued motion commands, jogging does not undergo a separate motion-planning stage that could fail after the command has been accepted. Once a jogging command is accepted, the requested velocities and accelerations are capped to the configured jogging and axis limits (see Velocity and Acceleration Limits) rather than raising an error. Any limit or safety violation that occurs while the robot is moving triggers the same stop reaction that applies to all motion.

The coordinate system of a jogging command must not be changed while the robot is still moving from a previous jogging command (see Continuous Command Behavior). If a refreshing jogging command specifies a coordinate system that differs from the one currently being executed, an error is raised and the robot transitions to its error state.