5.3. Linear (LIN)
The linear (LIN) command moves the robot’s tool center point (TCP) along a straight line in Cartesian space from its start pose to a specified target pose. Unlike PTP motions, see Point-to-Point (PTP), the LIN command guarantees a defined, straight-line Cartesian path for the TCP.
The motion is planned in Cartesian space. The path velocity and acceleration are specified independently for translation and rotation, allowing fine-grained control over the TCP motion along the path.
LIN commands are well-suited for tasks that require a predictable and repeatable Cartesian path, such as welding, gluing, or pick-and-place operations along defined trajectories.
Note
The robot must be in READY or ACTIVE state to accept LIN motion commands. See section
Prerequisites for command acceptance for more details on prerequisites for motion command acceptance.
5.3.1. Parameters
The LIN command accepts the following parameters:
Parameter |
Type |
Default |
Description |
|---|---|---|---|
|
Array of double |
— |
Target pose. Interpretation depends on |
|
Integer (enum) |
|
Coordinate system in which the target is specified. See Coordinate Systems in the section below or the section Coordinate Systems Overview for more information. |
|
Double |
|
Maximum translational path velocity in \([\mathrm{m/s}]\). If the start and target poses differ, this must
be > |
|
Double |
|
Maximum translational path acceleration in \([\mathrm{m/s^2}]\). If the start and target poses differ, this
must be > |
|
Double |
|
Maximum angular velocity in \([\mathrm{rad/s}]\). Only used if |
|
Double |
|
Maximum angular acceleration in \([\mathrm{rad/s^2}]\). Only used if |
|
Boolean |
|
If |
|
Integer (enum) |
|
Defines how the TCP orientation is interpolated along the path. See Table 74 for available values. |
|
Boolean |
|
If |
|
Boolean |
|
If |
|
Double |
|
Blending radius. Interpretation depends on |
|
Integer (enum) |
|
Specifies how the blending parameter is interpreted: |
|
Integer (enum) |
|
Specifies which frame arrives at the target, see Table 2 for more details.
Only relevant when |
|
Unsigned integer |
|
Unique identifier for tracking the command. See Command Tracking. |
|
Boolean |
|
If |
5.3.2. Coordinate Systems
The TargetReferenceCS parameter defines the coordinate system in which the target pose is specified. Its value
is the numeric OPC UA identifier of the desired coordinate system, as listed in Table 1 in
section Coordinate Systems Overview.
The chosen value determines how the target pose is interpreted:
0(Joint CS): The target is specified as joint angles in \([\mathrm{rad}]\). The corresponding Cartesian target pose is derived via forward kinematics before path planning.1–19(Cartesian frames): The target is specified as a Cartesian pose relative to the selected frame, e.g. the Robot CS (1), Tool CS (2), Camera CS (3), or one of the User CS (4–19), and is used directly for path planning.
Regardless of the selected coordinate system, the motion planner performs inverse kinematics along the straight-line path to determine the corresponding joint poses at each interpolation step.
For the full list of available coordinate systems, their identifiers, and detailed descriptions, see Coordinate Systems Overview.
5.3.3. Target Coordinates
How the target pose is reached depends on the coordinate system in which it is specified.
Cartesian Coordinates
When the target is specified in a Cartesian coordinate system, the TCP moves along a straight line from the start pose to the target pose. The specified Cartesian target pose is reached exactly as given.
Note
The same orientation can be represented by different angles. Consequently, the resulting orientation angles may differ from the specified value, but they represent the same orientation.
Joint Coordinates
When the target is specified in the joint coordinate system (TargetReferenceCS = 0), the given joint
angles are converted into a Cartesian target pose. The Cartesian pose results from the forward kinematic which
calculates the flange pose. Afterwards, the flange to tool transformation is added.
Since the robot then moves along a straight line to that Cartesian pose, the exact joint configuration at the target cannot be guaranteed. It depends on the robot’s start configuration and rotation settings, see Orientation Interpolation.
5.3.4. Motion Profile
The LIN motion profile is computed in Cartesian space. The TCP follows a straight-line path from start to target pose. Translation and orientation are interpolated by separate motion profiles that are synchronized to a common duration, so that both reach the target simultaneously.
Translation: Interpolation along the path coordinate
The individual Cartesian axes \(X\), \(Y\) and \(Z\) are not interpolated independently. Instead, the robot interpolates along the path itself, using a scalar path coordinate \(s(t)\) that measures progress along the straight line with length \(L\). Fig. 23 illustrates this path coordinate.
Fig. 23 Schematic of the LIN path coordinate \(s(t)\) along the straight line from start to target pose
The configured translational velocity and acceleration are applied to this path coordinate - that is, they limit the speed and acceleration of the TCP along the path, not of the individual \(X\), \(Y\) or \(Z\) components. The path coordinate follows a velocity profile bounded by these limits.
Rotation: SLERP between orientations
The orientation is not interpolated component-wise either. It is interpolated by spherical linear interpolation (SLERP) between the start and target orientation, which produces a smooth rotation about a single fixed axis (see the Orientation Interpolation section below for the available rotation types). This rotation is driven by its own normalized coordinate, to which the configured rotational path velocity and acceleration are applied; that coordinate follows a velocity profile bounded by these limits.
Common duration
The overall motion duration is determined by the slower of the two components (translation or rotation), ensuring that both the position and the orientation reach the target simultaneously.
Note
The configured path velocities and accelerations are treated as upper bounds. If a requested value exceeds the active robot or safety limit, it is reduced to that limit (a warning is logged) rather than rejected; the motion then executes at the reduced value. Consequently, the robot may move slower than requested.
5.3.5. Orientation Interpolation
The orientation of the TCP during the LIN motion is interpolated between the start and target orientation. The following rotation types are available:
By default, the shortest rotation path is used (ShortRotation = true).
5.3.6. Blending
LIN commands support blending with adjacent motion commands, enabling smooth transitions without stopping at intermediate poses. For a detailed description of the Cartesian blending behavior, see Cartesian Blending and PTP-LIN Blending.
To enable blending, set WithBlending to true and specify a BlendingParameter greater than
0.0. The blending parameter can be specified either as a percentage of the shorter adjacent segment
(BlendingType = 0) or as an absolute distance in meters (BlendingType = 1).
The transition between consecutive motion segments is continuous and smooth, so the robot does not stop at the intermediate pose.
5.3.7. Error Conditions
Error conditions are reported at two distinct stages. It is important to distinguish between them, because they require different handling by the client application. See also Prerequisites for command acceptance for general prerequisites that apply to all motion commands.
Rejected on Submission
The following conditions cause the LIN command to be not accepted - it does not enter motion planning and the robot keeps its current state. Depending on the condition, the command is either not queued or silently discarded:
The robot is not in
READYorACTIVEstate.The motion command queue is full. See Queue Overview for the queue capacity and how to handle a full queue.
The general prerequisites in Prerequisites for command acceptance (no stop in progress, position streaming inactive, no conflicting command type) are also checked before the command is accepted.
Errors during Motion Planning
The following conditions are not detected when the command is submitted. The command is accepted into the queue and only fails later, once it is processed by the motion planner. Such a failure raises an error and stops motion execution rather than rejecting the enqueue:
The start and target poses differ and
PathVelocityTranslationis not greater than0.0.The start and target poses differ and
PathAccelerationTranslationis not greater than0.0.The
RotationTypeis1(Standard), the start and target orientations differ, andPathVelocityRotationis not greater than0.0.The
RotationTypeis1(Standard), the start and target orientations differ, andPathAccelerationRotationis not greater than0.0.An invalid coordinate system value is specified.
The target pose violates configured axis position limits (after inverse kinematics).
The motion results in a singularity or the inverse kinematics cannot be solved.