Move robot and base axis to a relative target (axis- or TCP) position. This uses PtP interpolation. It is a coordinated motion - both robot and base axis start and finish together.
While an axis motion results in the shortest travel time, it does not follow a particular path for the TCP. An axis move is the least likely to cause errors when recovering from positions close to travel limits and singularities.
The user can specify the target position as well as desired speed, accel/decel parameters. These parameters are specified as a percentage of the max (e.g. 50%).
Version history
0.1.0
Changes
- source code ported
- version number reset
- now using semantic versioning
Prerequisites
prerequisite | state |
---|---|
Key switch | REMOTE |
MLX.JoggingMode | FALSE |
Overview
kind | name | type | default | comment |
---|---|---|---|---|
input | Enable | BOOL | Enable this Function Block. | |
input | RobotNumber | DINT | 0 | The robot commanded by this instruction instance. Valid values are 0 to MLX.NumberOfRobots-1. |
input | DeltaPositionRobot | ARRAY[0..7] OF REAL | Target Relative Axis Position of Robot. If Robot has less than 7 axes, only the first n are used where n is the number of axes for the robot. | |
input | DeltaPositionBase | ARRAY[0..7] OF REAL | Target Relative Axis Position of Base. If Base has less than 7 axes, only the first n are used where n is the number of axes for the base. | |
input | BlendFactor | DINT | 0 | Valid values: 0-8. This will define how much this motion should be blended into the next motion. Note: an additional motion will need to be added to the queue for this parameter to work correctly. See User Guide for detailed instructions on using this parameter. |
input | BlendType | BOOL | 0 | 0 = Blend based on command position 1 = Blend based on FB position (FPL) |
input | Speed | REAL | Speed to move axis in % of maximum. | |
input | Acceleration | REAL | Acceleration rate in % of maximum. | |
input | Deceleration | REAL | Deceleration rate in % of maximum | |
output | Sts_EN | BOOL | Enable bit. This bit will stay high as long as the instruction is enabled. | |
output | Sts_DN | BOOL | Done bit. This will turn HIGH when the command has been processed and added to the motion queue. The rung must stay enabled until this bit is active. | |
output | Sts_IP | BOOL | In process bit. This Instruction is actively executing, but another instruction may be commanding the active movement. | |
output | Sts_AC | BOOL | Active bit. HIGH if this motion is currently executing. | |
output | Sts_PC | BOOL | Process complete bit. HIGH if this motion has reached the end of its commanded trajectory. | |
output | Sts_ER | BOOL | Error bit. Indicates an error during instruction execution. Call MLxGetErrorDetail for more information. | |
output | PercentComplete | SINT | Percentage of motion that is completed. | |
in_out | MLX | MLxData | The MLxData Controller Scope tag. |
Details
Enable
BOOL
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)
- tracking motion status
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_PC
(process complete) status signal.
Disabling the input too early can mess up the MotoLogix command interface and lead to a hangup situation.
RobotNumber
DINT
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.
value | explanation |
---|---|
0-3 | Robot number (use
MLxRobotGetProperties
to see the mapping). |
DeltaPositionRobot
ARRAY[0..7] OF REAL
Relative robot target axis position (degrees
) for this motion.
The target is relative to the target of the proceeding motion
(or the current position in case of standstill).
[0] // S
[1] // L
[2] // U
[3] // R
[4] // B
[5] // T
[6] // E (for 7-axis robots)
[7] // 8 (for 8-axis robots)
- Axes which are not relevant for the connected robot are ignored.
DeltaPositionBase
ARRAY[0..7] OF REAL
Relative base axis target axis position (mm
) for this motion.
The target is relative to the target of the proceeding motion
(or the current position in case of standstill).
[0] // 1st axis
[1] // 2nd axis
[2] // 3rd axis
[3] // 4th axis
[4] // 5th axis
[5] // 6th axis
[6] // 7th axis
[7] // 8th axis
- Axes which are not relevant for the connected robot are ignored.
BlendFactor
DINT
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.
parameter | distance [µm] | description |
---|---|---|
S1CxG 33 | 12500 | Blendfactor 1 |
S1CxG 34 | 25000 | Blendfactor 2 |
S1CxG 35 | 50000 | Blendfactor 3 |
S1CxG 36 | 100000 | Blendfactor 4 |
S1CxG 37 | 200000 | Blendfactor 5 |
S1CxG 38 | 300000 | Blendfactor 6 |
S1CxG 39 | 400000 | Blendfactor 7 |
S1CxG 40 | 500000 | Blendfactor 8 |
value | explanation |
---|---|
-1 | speed dependent blending |
0 | no blending |
1-8 | blending fine to coarse |
BlendType
BOOL
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.
value | explanation |
---|---|
0 | blending based on the command position |
1 | blending based on the feedback position |
Speed
REAL
Defines the speed for the motion segment created by this instruction as
percentage of rated maximum (range: 0.01-100%
).
Acceleration
REAL
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.
value | explanation |
---|---|
20-100 | acceleration rate in % of maximum (SCARA manipulators optionally can go up to 130%) |
Deceleration
REAL
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.
value | explanation |
---|---|
20-100 | acceleration rate in % of maximum (SCARA manipulators optionally can go up to 130%) |
Sts_EN
BOOL
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
Sts_DN
BOOL
Status done signal which tells that the command is received by the
robot controller and added to its motion queue. The life cycle of this FB
has just begun (moton did not even started yet) so it is required to keep
the Enable
input high.
Sts_DN
is often used as a condition to enable another FB (for the following motion).- Depending on performance of PLC and fieldbus
Sts_DN
typically comes approx.20ms
after enabling 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.
Sts_IP
BOOL
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);
Sts_AC
BOOL
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.
Sts_PC
BOOL
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.
Sts_ER
BOOL
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) orMLxResetAndHold
(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.
PercentComplete
SINT
Informs about the progress of the motion segment created by this
instruction. The value is represented as whole number 0-100%
.
MLX
MLxData
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.
Implementation
fbRobotMoveAxisRelaWithBase : ARRAY[0..0] OF MLxRobotMoveAxisRelaWithBase;
// fbRobotMoveAxisRelaWithBase[0].Enable := ;
// fbRobotMoveAxisRelaWithBase[0].RobotNumber := ;
// fbRobotMoveAxisRelaWithBase[0].DeltaPositionRobot := ;
// fbRobotMoveAxisRelaWithBase[0].DeltaPositionBase := ;
// fbRobotMoveAxisRelaWithBase[0].BlendFactor := ;
// fbRobotMoveAxisRelaWithBase[0].BlendType := ;
// fbRobotMoveAxisRelaWithBase[0].Speed := ;
// fbRobotMoveAxisRelaWithBase[0].Acceleration := ;
// fbRobotMoveAxisRelaWithBase[0].Deceleration := ;
fbRobotMoveAxisRelaWithBase[0]( MLX := dummy );
// := fbRobotMoveAxisRelaWithBase[0].Sts_EN;
// := fbRobotMoveAxisRelaWithBase[0].Sts_DN;
// := fbRobotMoveAxisRelaWithBase[0].Sts_IP;
// := fbRobotMoveAxisRelaWithBase[0].Sts_AC;
// := fbRobotMoveAxisRelaWithBase[0].Sts_PC;
// := fbRobotMoveAxisRelaWithBase[0].Sts_ER;
// := fbRobotMoveAxisRelaWithBase[0].PercentComplete;