MLxRobotMoveLinearRelative

For starting this function block. On a rising edge of this input the internal processing will start which is indicated by the Sts_EN status signal.

Internal processing steps typically involve:

• checking if required conditions are met
• sending command data to the robot controller (on the next possible occasion)
• receiving answer data from the robot controller

Since the status bits will only be updated as long as the Enable is active, it is necessary to keep the input enabled until the FB has completed its entire lifecycle which is signalled by the Sts_DN (done) status signal.

Disabling the input too early can mess up the MotoLogix command interface and lead to a hangup situation.

Specifies the motion device targeted by this MotoLogix function.

The MotoLogix data packet supports a maximum of 4 motion devices on one robot contoller. Examples of motion devices are:

• manipulators (e.g. GP7 robot)
• base axes (e.g. gantry system)
• station axes (e.g. servo gripper)

Each motion device gets its own RobotNumber (and slot in the data packet). Some examples:

two robots: R1 and R2

[0]     // R1
[1]     // R2
[2]     // not used
[3]     // not used

two robots on a linear track R1B1 and R2B2

[0]     // R1
[1]     // R2
[2]     // B1
[3]     // B2

robot with a servo gripper R1S1

[0]     // R1
[1]     // S1
[2]     // not used
[3]     // not used

The numbering is fixed in the configuration of the robot controller (cannot be changed by MotoLogix). MLxRobotGetProperties can be used to read this configuration. It will give you practical information for each motion device such as: type, axis names, speed- and motion range.

Relative target position for this motion.

The target is relative to the target of the proceeding motion (or the current position in case of standstill) and relates to the specified CoordFrame .

With the BlendFactor parameter you define at what point the motion should begin to blend into the next queued motion.

Blending is key to a fast and smooth robot motion. For the best blending the robot controller requires at least 3 motions (active motion + 2 motions pre-loaded).

Basically there are 3 choices for blending:

• No blending
• Speed dependent blending (recommended)
• Blend by a predefined distance

The BlendFactor is also important for the last motion before a standstill as it defines the point at which the Sts_PC signal becomes active. Usually you want the robot to be exactly at the target position before proceeding actions can follow (e.g. closing the gripper). This means you have to set BlendFactor 0. Other values will result in Sts_PC becoming high before the robot really reached the target position.

Blending between diffent kinds of motions

Previously it was not possible to blend between diffent kinds of motions (e.g. point-to-point to linear motions or vice-versa) with BlendFactors other than -1.

• On YRC1000 and YRC1000micro this limitation was removed by a system software upgrade . This requires parameter S2C1586=1.
• On DX200 this limitation still exists.

No blending

BlendFactor 0 is used to disable blending for this motion. The robot will move without cutting the corner. This will add some cycle time as the robot will have a short standstill exactly on the target position.

Speed dependent blending

BlendFactor -1 is used for blending depending on the speed of the robot. The faster the robot moves, the more it cuts the corners.

This setting is recommended for most cases as it works for any trajectory. However, if there is a risk of collision (and predictable blending is required) you should blend by a predefined distance.

Fixed distance blending

BlendFactor 1 to 8 are used for blending by predefined distances. This leads to a predictable and consistent blending. However, when using one of these predefined blending distances you have to make sure that the setting is not too large for the motion segment, otherwise it will not blend at all (resulting in non-smooth motion and increased cycle time).

These distances are defined by robot parameters which can be changed by the customer. Below table shows the default settings.

This specifies how the internal path planner should handle the blending into the next motion:

• Usually the blending can be based on the robot’s command position.
• Exception is a conveyor tracking motion with BlendFactor 0 – in this case the blending needs to be based on the robot’s feedback position.

Defines the speed for the motion segment created by this instruction (range: see SpeedUnits ).

Setting the speed for a linear motion is a bit more complicated than for a PtP motion (e.g. MLxRobotMoveAxisAbsolute ). To understand this we need to look at the speed range of the manipulator (use MLxRobotGetProperties to read such data), for example:

• Linear speed: 1500mm/s (MaxLinearSpeed)
• Rotational speed: 360deg/s (MaxAngularSpeed)

By default, the specified speed is interpreted as **linear speed (in absolute units or as percentage of this range). **This is fine for most cases.

However, when the linear distance between 2 points is very small (or even zero) but there is a lot of rotation (e.g. tilting the TCP by 180deg) this can lead to unexpected fast motion.

Since the speed is interpreted as linear speed, the duration of this motion would theoratically be near zero seconds. But: in the same time it will do the 180deg rotation of the TCP. In practice this means that the rotation is done with the MaxAngularSpeed which is probably not what you want.

To handle such situations there is a UseRotationalSpeed parameter, which tells the instruction to interpret the speed as rotational speed.

Verify linear distance

To determine whether setting UseRotationalSpeed is required, the linear distance between two points can be calculated:

// Calculate linear distance between 2 TCP positions (must be in same UF)
linearDistance := SQRT ( (X-Xprev)^2 + (Y-Yprev)^2 + (Z-Zprev)^2 );

// Check if UseRotationalSpeed needed
needsUseRotationalSpeed := (linearDistance < someThreshold);

This calculation only works when both positions are:

• TCP positions
• using the same User Frame

In other cases the calculation will be a bit more complex (transformations/matrix calculations) but still worth investing some time in as it can lead to a solid way of programmatically setting UseRotationalSpeed.

Specifies how the speed setting for the robot motion should be interpreted.

The desired speed for the linear motion can be be specified in various ways. Besides % and units/sec MotoLogix also supports the newer VMAX setting.

VMAX is a speed setting optimized for high speed. Where the other speed settings are based on a rated maximum (manipulator specific, see MLxRobotGetProperties ) which can be achieved at any arm pose, VMAX considers the maximum possible at a given position.

So for a manipulator with a maximum linear speed of 1500 mm/sec VMAX can reach higher speeds in some motion regions. The consequence is that the speed is not constant.

• If constant speed is required, VMAX should not be used
• VMAX is not supported on the DX200 robot controller

Acceleration rate for the motion segment created by this instruction.

Usually a value around 80% is fine. Higher values often do not really improve the cycle time much further and instead just lead to more wear and an increased energy consumption.

Deceleration rate for the motion segment created by this instruction.

Usually a value around 80% is fine. Higher values often do not really improve the cycle time much further and instead just lead to more wear and an increased energy consumption.

Frame used for this relative motion.

Status Enabled signal which tells that the FB is currently enabled. It reflects the status of the Enable input.

A common use for Sts_EN is in combination with the Sts_DN (or Sts_PC) signal. This filters the old status which is important because in the PLC scan where the FB gets enabled the Sts_DN still has the status from its previous run (which is probably high) until the FB call is processed.

CASE state OF
...
10:
  // enabling the FB
  someMLxFB.Enable := TRUE;

  // condition to proceed after FB finished
  // --> Sts_DN still has its old status from previous run
  IF (someMLxFB.Sts_DN AND someMLxFB.Sts_EN) THEN
    state := state + 10;
  END_IF;

20:
  ...
END_CASE;

// FB call
someMLxFB(...);
// --> now Sts_DN has the new status

Status done signal which tells that the FB has finished. This means the Enable input can now safely be disabled as the FB has completed its lifecycle.

This status signal keeps its status until the next time this FB is enabled. See Sts_EN on how to filter any old status.

Status in process signal which is high from the moment of enabling the FB (Sts_EN) until the motion has finished (Sts_PC).

This status signal is not used very often. A use case could be to display the pending state of a motion command where the command is in the robot controller’s motion queue waiting for earlier motion commands to be finished.

// pending state
Pending := (someMLxFB.Sts_IP AND NOT someMLxFB.Sts_AC);

Status active signal which tells that the motion issued by this instruction is currently executing.

While the motion is executing the PercentComplete status informs about the progress.

Status process complete signal which tells that the motion issued by this instruction is completed. This means the Enable input can now safely be disabled as the FB has completed its lifecycle.

The exact timing for switching Sts_PC depends on the BlendFactor which was specified for this motion.

• Sts_PC is often used as the transition condition the application logic

This status signal keeps its status until the next time this FB is enabled. See Sts_EN on how to filter any old status.

Status error signal which tells that the FB has failed. The Enable input can now be disabled as the FB has aborted its lifecycle.

Now it is important to find the cause of the error. In most cases the robot controller has generated an alarm which explains what the problem is.

Recommended next steps:

• Read the alarm details using MLxGetErrorDetail
• Fix the issue described in the alarm details (e.g. parameter out of range)
• Reset the alarm using MLxReset (also clears the motion queue) or MLxResetAndHold (resets the alarm but leaves the motion queue in place).
• Restart the application

If Sts_ER becomes active but the robot controller does not generate an alarm you should check the SystemState and the conditions/prerequisites for using the FB.

This status signal keeps its status until the next time this FB is enabled. See Sts_EN on how to filter any old status.

Informs about the progress of the motion segment created by this instruction. The value is represented as whole number 0-100%.

The MotoLogix variable which acts as the shared memory for a MotoLogix system.

As the PLC runs through its scan cycle each active MotoLogix FB will read from- and write to this MotoLogix variable.

It is also used for processing the data red from- and sent to the robot controller.

There are a few important rules:

• MLxCommunicationRead must be called at the very beginning of the PLC scan cycle.
• MLxCommunicationWrite must be called at the very end of the PLC scan cycle.
• All other MotoLogix FB’s used in your application must be called inbetween.
• All off this must be handled by the same PLC task, respecting above rules.

Failing to follow above rules can lead to inconsistent data being sent to the robot controller which could result in unexpected motion.