Professional Documents
Culture Documents
2012073108573300001
2012073108573300001
Instruction Handbook
Controller Unit
MOTION PROGRAMMING
System Software Rel. 1.10
CR00757608_en-04/2011.07
The information contained in this manual is the property of COMAU S.p.A.
Reproduction of text and illustrations is not permitted without prior written approval by COMAU S.p.A.
COMAU S.p.A. reserves the right to alter product specifications at any time without notice or obligation.
SUMMARY
PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Symbols used in the manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Modification History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
lb-rc-c5e-motion_enTOC.fm
1
Summary
Reference frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
System reference frames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Manual motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Manual motion in WRIST_JNT mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Manual motion of a single arm system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Manual motion of auxiliary axes, slides and rotating columns . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Manual motion with Controller multi-arm configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Motion instruction in programming status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
lb-rc-c5e-motion_enTOC.fm
2
Summary
lb-rc-c5e-motion_enTOC.fm
3
Summary
Jogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9. CONVEYOR TRACKING
(OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..106
lb-rc-c5e-motion_enTOC.fm
4
Summary
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Example - Using the weaving without Arm motion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
lb-rc-c5e-motion_enTOC.fm
5
Summary
lb-rc-c5e-motion_enTOC.fm
6
Summary
lb-rc-c5e-motion_enTOC.fm
7
Summary
lb-rc-c5e-motion_enTOC.fm
8
Configuring the software option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Example of PDL2 statements for configuring the Axes Pursuit functionality . . . . . . . . . . . . 250
lb-rc-c5e-motion_enTOC.fm
00/0000 9
Preface
PREFACE
– Symbols used in the manual
– Reference documents
– Modification History.
HS-0-0-0-mot_01.fm
04/0711 10
Preface
Reference documents
This document refers to the C5G Control Unit.
The complete set of manuals for the C5G consists of:
HS-0-0-0-mot_01.fm
11 04/0711
Preface
Modification History
– Version 02/0710:
• Chapter TO_SET Program - Tool handling - the calling level of the Payload
identification (optional function) procedure and the format of the TO_SET
Program screen pages, have been modified.
• New Chap.18. - Interference Regions (optional feature) has been added.
– Version 03/0111:
• added par. 15.7.5 Use of CDetect open source library on page 161 in
Chap.15. - Collision Detection (optional feature),
• added Chap.19. - Axes Pursuit (optional feature),
• added description for Weaving with Circular wave in Chap.10. - Motion with
Weaving (optional feature).
– Version 04/0711:
• added par. 7.3 Multi-cooperative motion on page 86 in Chap.7. - Cooperative
Motion (optional feature), to handle the cooperation among two arms and the
same group of auxiliary axes (e.g. a positioner).
• the description of Chap.18. - Interference Regions (optional feature) and the
corresponding examples has been improved.
HS-0-0-0-mot_01.fm
04/0711 12
General Safety Precautions
It deals with a general specification that apply to the whole Robot System. Due to
ist significance, this document is referred to unreservedly in any system
instruction manual.
1.1 Responsibilities
– The system integrator is responsible for ensuring that the Robot System (Robot
and Control System) are installed and handled in accordance with the Safety
Standards in force in the country where the installation takes place. The application
and use of the protection and safety devices necessary, the issuing of declarations
of conformity and any CE markings of the system are the responsibility of the
Integrator.
– COMAU Robotics & Service shall in no way be held liable for any accidents caused
by incorrect or improper use of the Robot System (Robot and Control System), by
tampering with circuits, components or software, or the use of spare parts that are
not included in the spare parts list.
ge-0-0-0_01.FM
00/0510 13
General Safety Precautions
1.2.2 Definitions
Robot System (Robot and Control System)
The Robot System is a functional unit consisting of Robot, Control Unit, Programming
terminal and possible options.
Protected Area
The protected area is the zone confined by the safety barriers and to be used for the
installation and operation of the robot
Authorised Personnel
Authorised personnel defines the group of persons who have been trained and assigned
to carry out the activities listed in the Applicability section.
Assigned Personnel
The persons assigned to direct or supervise the activities of the workers referred to in
the paragraph above.
Programming Mode
Operating mode under the control of the operator, that excludes automatic operation
and allows the following activities: manual handling of robot axes and programming of
work cycles at low speed, programmed cycle testing at low speed and, when allowed,
at the working speed.
ge-0-0-0_01.FM
14 00/0510
General Safety Precautions
Integrator
The integrator is the professional expert responsible for the installation and putting into
service of the Robot and Control System.
Incorrect Use
Incorrect use is when the system is used in a manner other than that specified in the
Technical Documentation.
Range of Action
The robot range of action is the enveloping volume of the area occupied by the robot
and its fixtures during movement in space.
1.2.3 Applicability
These Specifications are to be applied when executing the following activities:
– Installation and Putting into Service;
– Programming Mode;
– Auto / Remote Automatic Mode;
– Robot axes release;
– Maintenance and Repairs;
– Putting Out of Service and Dismantling
ge-0-0-0_01.FM
00/0510 15
General Safety Precautions
– Connection between the Control Unit and the three-phase supply mains at the
works, is to be with a four-pole (3 phases + earth) armoured cable dimensioned
appropriately for the power installed on the Control Unit. See the product
Technical Documentation.
– The power supply cable is to enter the Control Unit through the specific fairlead and
be properly clamped.
– Connect the earth conductor (PE) then connect the power conductors to the main
switch.
ge-0-0-0_01.FM
16 00/0510
General Safety Precautions
– Connect the power supply cable, first connecting the earth conductor to the circuit
breaker on the mains line, after checking with a tester that the circuit breaker
terminals are not powered. Connect the cable armouring to the earth.
– Connect the signals and power cables between the Control Unit and the robot.
– Connect the robot to earth or to the Control Unit or to a nearby earth socket.
– Check that the Control Unit door (or doors) is/are locked with the key.
– A wrong connection of the connectors could cause permanent damage to the
Control Unit components.
– The C5G Control Unit manages internally the main safety interlocks (gates,
enabling pushbuttons, etc.). Connect the C5G Control Unit safety interlocks to the
line safety circuits, taking care to connect them as required by the Safety
standards. The safety of the interlock signals coming from the transfer line
(emrgency stop, gates safey devices etc) i.e. the realisation of correct and safe
circuits, is the responsibility of the Robot and Control System integrator.
In the cell/line emergency stop circuit the contacts must be included of the control
unit emergency stop buttons, which are on X30. The push buttons are not
interlocked in the emergency stop circuit of the Control Unit.
– The safety of the system cannot be guaranteed if these interlocks are wrongly
executed, incomplete or missing.
– The safety circuit executes a controlled stop (IEC 60204-1 , class 1 stop) for the
safety inputs Auto Stop/ General Stop and Emergency Stop. The controlled stop is
only active in Automatic states; in Programming the power is cut out (power
contactors open) immediately. The procedure for the selection of the controlled
stop time (that can be set on SDM board) is contained in the Installation manual .
– When preparing protection barriers, especially light barriers and access doors,
bear in mind that the robot stop times and distances are according to the stop
category (0 or 1) and the weight of the robot.
Check that the controlled stop time is consistent with the type of Robot connected
to the Control Unit. The stop time is selected using selector switches SW1 and
SW2 on the SDM board.
– Check that the environment and working conditions are within the range specified
in the specific product Technical Documentation.
– The calibration operations are to be carried out with great care, as indicated in the
Technical Documentation of the specific product, and are to be concluded
checking the correct position of the machine.
– To load or update the system software (for example after replacing boards), use
only the original software handed over by COMAU Robotics & Service.
Scrupulously follow the system software uploading procedure described in the
Technical Documentation supplied with the specific product. After uploading,
always make some tests moving the robot at slow speed and remaining outside the
protected area.
– Check that the barriers of the protected area are correctly positioned.
ge-0-0-0_01.FM
00/0510 17
General Safety Precautions
Programming Mode
– The robot is only to be programmed by the authorised personnel.
– Before starting to program, the operator must check the Robot System (Robot and
Control System) to make sure that there are no potentially hazardous irregular
conditions, and that there is nobody inside the protected area.
– When possible the programming should be controlled from outside the protected
area.
– Before operating inside the Protected Area, the operator must make sure from
outside that all the necessary protections and safety devices are present and in
working order, and especially that the hand-held programming unit functions
correctly (slow speed, emergency stop, enabling device, etc.).
– During the programming session, only the operator with the hand-held terminal is
allowed inside the Protected Area.
– If the presence of a second operator in the working area is necessary when
checking the program, this person must have an enabling device interlocked with
the safety devices.
– Activation of the motors (Drive On) is always to be controlled from a position
outside the range of the robot, after checking that there is nobody in the area
involved. The Drive On operation is concluded when the relevant machine status
indication is shown.
– When programming, the operator is to keep at a distance from the robot to be able
to avoid any irregular machine movements, and in any case in a position to avoid
the risk of being trapped between the robot and structural parts (columns, barriers,
etc.), or between movable parts of the actual robot.
– When programming, the operator is to avoid remaining in a position where parts of
the robot, pulled by gravity, could execute downward movements, or move
upwards or sideways (when installed on a sloped plane).
– Testing a programmed cycle at working speed with the operator inside the
protected area, in some situations where a close visual check is necessary, is only
to be carried out after a complete test cycle at slow speed has been executed. The
test is to be controlled from a safe distance.
– Special attention is to be paid when programming using the hand-held terminal: in
this situation, although all the hardware and software safety devices are active, the
robot movement depends on the operator.
– During the first running of a new program, the robot may move along a path that is
not the one expected.
– The modification of program steps (such as moving by a step from one point to
another of the flow, wrong recording of a step, modification of the robot position out
of the path that links two steps of the program), could give rise to movements not
envisaged by the operator when testing the program.
– In both cases operate cautiously, always remaining out of the robot’s range of
action and test the cycle at slow speed.
ge-0-0-0_01.FM
18 00/0510
General Safety Precautions
Before using the manual release devices, it is strongly recommended to sling the
robot, or hook to an overhead travelling crane.
– Enabling the brake releasing device may cause the axes falling due to gravity as
well as possible impacts due to an incorrect restoration, after applying the brake
releasing module. The procedure is described in Maintenance Handbook of C5G.
– When the motion is enabled again following the interruption of an unfinished
MOVE, the track recovery typical function may generate unpredictable paths that
may imply the risk of impact. This same condition arises at the next automatic cycle
restarting. Avoid moving the Robot to positions that are far away from the ones
provided for the motion restart; alternatively disable the outstanding MOVE
programmes and/or instructions.
ge-0-0-0_01.FM
00/0510 19
General Safety Precautions
After replacement of the SDM module, check on the new module that the setting
of the stop time on selector switches SW1 and SW2 is consistent with the type of
Robot connected to the Control Unit.
ge-0-0-0_01.FM
20 00/0510
General Safety Precautions
ge-0-0-0_01.FM
00/0510 21
General Safety Precautions
1.2.5 Performance
Before installing the robot system the user must consider the following performances:
– Stop distances (threshold values)
– Mission time (typ. case).
ge-0-0-0_01.FM
22 00/0510
System operating modes and states
2.1 Foreword
This chapter describes the following:
– System operating modes
– System states
– Stand-by function
HS-0-C5E-USO_32.fm
00/0310 23
System operating modes and states
When the status selector switch is set on position T1, the programs can be developed
using editor environment and the spots can be taken from the Teach Pendant moving
the robot manually with the motion keys; the programs can be set up using the debug
tools of the system. In programming mode, the execution of a move instruction requires
that the operator presses the START key and the enable device on the Teach Pendant.
When the status selector switch has been set on T1, the system is under the control of
the operator. When the selector is set on REMOTE, the system is under remote control
(for example from PLC).
Active TOOL, BASE and FRAME cannot be changed when working in REMOTE.
Before any operation can be executed that requires movement, the drives must be
powered:
– if the state selector switch is in T1 position, press in the intermediate position the
Teach Pendant Enabling Device, to power ON the drives; tho switch them OFF and
activate brakes on all axes controlled by the Control Unit, just release the Teach
Pendant Enabling Device,
– if the state selector switch is in AUTO position, press the R5 softkey (Teach
Pendant right menu - it means DRIVE ON when in AUTO state), to power ON the
drives; to switch them OFF and activate brakes on all axes controlled by the
Control Unit, press the R5 softkey again (Teach Pendant right menu - now it means
DRIVE OFF).
Active TOOL, BASE and FRAME cannot be changed when working in AUTO.
– if the state selector switch is in REMOTE position, DRIVEs ON and OFF are
remote controlled.
A detailed description follows of all the possible system states.
HS-0-C5E-USO_32.fm
24 00/0310
System operating modes and states
of the power contactor) may take place with a delay that ranges from a minimum of 1
second to a maximum of 2 seconds.
With the status selector switch positioned on T1, the power cut-out is immediate (EN
60204-1, class 0 stop).
– ALARM status: this status is entered when there is a system alarm. According to
how serious the error is, the system takes different actions, such as suspending the
program execution, deactivation of the drives, etc. A situation may occur where the
alarm cannot be reset, therefore the drives cannot be switched on.
The current system status is displayed on the first status line of the Teach Pendant (or
in the Terminal window of tool WinC5G on PC).
The figure shows a simplified diagram of the actions that determine the system
change-over from one state to another.
HS-0-C5E-USO_32.fm
00/0310 25
System operating modes and states
is considered as pressed. Further pressure on the key causes the system to exit from
HOLD status.
If the HOLD status has been caused by pressing the DRIVE OFF key on the Teach
Pendant (either Enabling Device released or R5 softkey pressed meaning DRIVE OFF),
the DRIVE OFF and HOLD keys must be pressed again to exit from HOLD status, and
then re-power the drives (either intermediate pressure of the Enabling Device or press
R5 softkey meaning DRIVE ON).
HS-0-C5E-USO_32.fm
26 00/0310
System operating modes and states
The Stand-by function is automatically deactivated at the first request to start movement
again (START, RESUME) from the system.
The system Stand-by status is displayed in the status bar of the Teach Pendant. To
display the state of a single arm, read this status on the Status sub-page, the Motion
page on the Teach Pendant.
HS-0-C5E-USO_32.fm
00/0310 27
Turn-Set and Calibration - basic concepts
3.1 Foreword
The purpose of this chapter is to describe the basic concepts and the terminology for the
management of robot axes position information. The description of the operating
procedures is contained in the chapter TURN-SET AND CALIBRATION
- OPERATING PROCEDURES, that specifically regards the robot used.
This chapter contains the basic information on the following topics:
– Terminology used
– Turn-set
– Calibration
3.2 Terminology
– TRANSDUCER: There are two types of position transducers: encoder and
resolver.
– NUMBER OF TRANSDUCER TURNS: during the robot axis movement, the
transducer may make several turns; the number of turns is initialised through the
calibration or the turn-set.
– AXIS VALUE: the value of an axis contains all the information needed to determine
the exact position of an axis in space;
– VALUE RECONSTRUCTION: when the Control Unit is powered on, the system
software, among the various initialisations, reconstructs the value of the robot
axes.
The system software checks this value; in fact, it checks that the difference
between the reconstructed position and the position before shut-down is below a
certain threshold. If the threshold is exceeded, the Control Unit displays the error
59411 - 08 Ax <num_ax> Arm <num_arm> movement after shut-down and
leaves it to the operator to check that the physical position of the robot corresponds
to the new value.
– CALIBRATION POSITION: a pre-set position that has been checked using
specific equipment (dial gauges, supports, calibration fixtures). The calibration
position is a reference position in the robot working space that serves to initialise
the value of each axis.
– CALIBRATION CONSTANTS: the calibration constant is the difference between
the datum read by the transducer and the nominal position of the robot axis that
the transducer should assume in that particular position of the robot axis. In fact,
since the positioning of the transducer as to the robot joint is casual, (because it
depends on how the transducer has been mounted), it is necessary to correct the
actual position of the transducer according to the nominal position required by the
robot axis.
The calibration constant is defined inside a transducer turn and is stored in variable
$CAL_DATA. It is represented in motor turns and is a value between -0.5
HS-0-C5E-USO_35.fm
28 00/0610
Turn-Set and Calibration - basic concepts
3.3 Turn-set
The purpose of the turn-set is to update the number of transducer turns only,
should it occur that the when switched on again, the Control Unit has lost this
value.
The operation consists in bringing the axis involved to the calibration position, using the
locating notches, and giving the required command. No special equipment is needed,
because the only value initialised is the number of turns of the transducer.
The turn-set operation is required when
– there has been axis movement with the control off (for example when the error
59411 - 08 Ax <num_ax> Arm <num_arm> movement after shut-down) is
displayed.
– events take place that cause the loss of the number of turns only, and therefore do
not require the execution of the calibration procedure. On the Teach Pendant
status window or on the PV video the text Ar:TURN is displayed.
According to whether the turn-set is executed with the robot in system calibration
position or in user calibration position, we shall have:
– Turn-set on system calibration position
– Turn-set on user calibration position
– Turn-set for robot axes with multi-turn stroke
HS-0-C5E-USO_35.fm
00/0610 29
Turn-Set and Calibration - basic concepts
complete rotations, positions in a mechanical turn that is different to that of the original
calibration).
In the above indicated condition, when moving the axis to align the notches, a
positioning error message is shown on the terminal.
5409 - 02 Ax <num_asse> Arm <num_arm> joint position not sufficient
accurate
If the above described conditions occur, do not send the TURN SET command (the axis
would be calibrated in a wrong position), but restore the correct position by performing
one of these procedures:
1. Turn the axis and make attempts to find the axis turn position where the original
calibration was executed. Align the notches and run the TURN SET command.
When the correct position has been resumed, the message Command
Completed will appear on the Terminal
otherwise, as an alternative
2. Make the complete axis calibration (see Chapter Turn-set and Calibration -
Operating Procedures in the Maintenance manual of the corresponding robot)
3.4 Calibration
The purpose of the calibration procedure is to establish the position of a robot axis
referring it to an ideal robot. This makes it possible to initialise the values of the robot
axes and to make the position variables used in the robot programs universal.
During the calibration procedure, when the desired axis is in the calibration position, two
values are stored:
– the deviation, inside a transducer turn, between the value of the actual position and
that of the axis nominal position,
– the number of transducer turns.
HS-0-C5E-USO_35.fm
30 00/0610
Turn-Set and Calibration - basic concepts
The notches on the individual axes make it possible to execute future turn-set operations
on a robot that has already been installed.
Remember that executing the calibration operation (on the Teach Pendant,
SETUP Page, Calib subpage, Calib (CAC) command) just having positioned the
robot axes on the locating notches, without using the suitable equipment, is an
operation that does not guarantee the necessary robot positioning precision.
Subsequently, the calibration does not need to be executed again, unless there is
a mechanical failure that involves the replacement of a component of the
kinematic chain, or in the case of impacts that damage the robot structure.
HS-0-C5E-USO_35.fm
00/0610 31
Turn-Set and Calibration - basic concepts
HS-0-C5E-USO_35.fm
32 00/0610
Robot motion in Programming mode
4.1 Introduction
In this chapter, reference will be made to the Teach Pendant as the device to control the
robot motion in programming status (status selector switch in position T1).
For any further information and/or explanations, see the relevant chapter Use of
the Teach Pendant, in the C5G Control Unit Use manual.
HS-0-C5E-USO_33.fm
00/0210 33
Robot motion in Programming mode
The $TOOL variable describes the position of the TCP frame in relation to the flange;
the $BASE variable describes the position of the base frame in relation to the world
frame; finally, the $UFRAME variable describes the position of the workpiece in relation
to the world frame.
The POS conversion indicates the recorded point P where the TCP will position when
executing the program. It must be remembered that all the POSITIONS recorded are
defined in relation to the user reference frame (defined by $UFRAME, with certain
$BASE and $TOOL values).
1. Flange frame
2. Tool frame
3. Recorded position
4. User frame
5. Base frame
6. World frame
Let’s now imagine a pen fitted on the flange of the robot that has to write the word
COMAU on the table. The $BASE conversion defines the point where the robot base is
located, the $TOOL movement indicates the pen and the $UFRAME movement
indicates the position of the table.
HS-0-C5E-USO_33.fm
34 00/0210
Robot motion in Programming mode
Before moving in Cartesian mode (Tool, Uframe, Base) the correct definition
should be checked of the reference systems, especially the declaration of the tool
frame through the $TOOL variable. A wrong description of the tool causes errors
in learning the points and does not keep the TCP position unchanged during
orientation movements. A good method to check the correctness of $TOOL is to
check that the TCP remains fixed while changing the orientation of the tool.
HS-0-C5E-USO_33.fm
00/0210 35
Robot motion in Programming mode
The procedure for arm manual movement of a robotic cell varies slightly according to
the cell controller configuration. The following paragraphs describe the main details for
each typical situation.
HS-0-C5E-USO_33.fm
36 00/0210
Robot motion in Programming mode
For further information, please see C5G Control Unit Use - chp. Motion Page - par.
COOP (optional), AUX JOG section).
If the Teach Pendant is the wireless version (WiTP), the AUX hardkey is also available.
However, if the auxiliary axis moves a slide, a column or a built-in gripper, it can be
moved also in Cartesian modes (BASE, TOOL and UFRAME) using the same keys as
for JOINT mode.
Jogging in cartesian mode, allows to move the integrated axis without moving the TCP
(thus, the robot joints can move and follow the auxiliary axis/axes motion, in order not to
move the TCP from its initial position).
Note that when teaching positions for auxiliary axes, it is recommended to use
XTNDPOS.
HS-0-C5E-USO_33.fm
00/0210 37
Robot motion in Programming mode
constants JOINT, LINEAR and CIRCULAR respectively (see the Chap. Motion Control
for further details). If the type of trajectory is not indicated, the value defined in the
$MOVE_TYPE system variable is valid, that is usually set at JOINT by the system.
The destination points are typically learnt inside a program, but they can also be
assigned directly in the instruction line of EXECUTE. Two ways to assign the destination
point that are most useful for installation and maintenance are given below. A Cartesian
point can be assigned by the built-in POS that allows, as parameters, the three
co-ordinates x, y and z where the TCP is to be taken, three angles for tool orientation
and a configuration string. All the positions of this type are called POSITION and are
always referred to the reference systems; the configuration string can usually be left
empty. The following is a valid position that defines a point at 100 mm from the user
reference in direction z: POS (0,0,100,0,0,0,’’). For further information see the
Chap. Motion Control and the PDL2 Programming Language manual. A destination
point can also define the position to be reached by each arm axis (including auxiliary
axes). To do so, write the values separated by a comma (in the correct order) and
enclose the complete declaration in a brace. A missing value leaves the position of the
corresponding axis unchanged. The following is a joint type position, that requires axis
1 to move 10 degrees from the zero position, leaves axis 2 stationary, takes axis 3 to
-30 degrees and leaves the wrist unchanged: {10, ,-30}.
Some examples follow for valid movement instructions (for further information see the
PDL2 Programming Language Manual).
HS-0-C5E-USO_33.fm
38 00/0210
Robot motion in Programming mode
HS-0-C5E-USO_33.fm
00/0210 39
Motion Control
5. MOTION CONTROL
5.1 Overview
This chapter contains the description of the C5G Robot Control Unit motion
environment, with the exception of manual handling (Teach Pendant jog keys) which is
described in the Chap. Robot motion in Programming mode, and for the optionals that
are dealt with further on in other chapters of this manual.
Information is supplied about the following topics:
– Frames of Reference and coordinates transformation
– Trajectory and Trajectory Recovery
– Position Checking
– Speed Control
– Acceleration and Deceleration
– Motion termination
– Process Resume
– Continuous Motion
– Remote Tool System;
– Integrated Movement;
– Palletizing functionality (optional feature).
Current chapter contains many references to predefined variables and instructions of
PDL2 language. For further information, refer to PDL2 Programming Language
Manual.
pr-0-0-gpr_04.fm
40 00/0210
Motion Control
World Frame The factory plant frame of reference with respect to which all
machines are positioned
Base Frame The frame located on the robot base
User Frame The frame located on the workpiece
Flange Frame The frame located on the robot flange
TCP Frame The frame located on the tool top
The $TOOL variable describes the position of the TCP frame with respect to the flange
frame; the $BASE coordinate transformation describes the position of the base frame
with respect to the world frame; the $UFRAME transformation describes the position of
the workpiece with respect to the world. The POS transformation represents the taught
point P that will be reached by the TCP during the execution of the program. Note that
all the taught POSITIONs are defined with respect to the user frame of reference
(defined by $UFRAME).
To better understand, suppose that the corner of the room is the world frame, and a
robot is located beside a table as shown in the following picture Fig. 5.1 - System
Frames of Reference and Coordinates Transformation.
Suppose further that the robot has a pen mounted on the flange and it has to write
COMAU on the table. $BASE defines where the robot is located, the $TOOL
transformation describes the pen, and the $UFRAME transformation defines the
position of the table with respect to the room.
These system frames will simplify some operations. For example:
pr-0-0-gpr_04.fm
00/0210 41
Motion Control
– if the robot were picked up and placed at the opposite side of the table, it would be
enough to redefine $BASE and restart writing without modifying any point;
– if the pen were replaced with a bigger one, it would be enough to redefine $TOOL
and restart writing without modifying any point;
– if the table were moved inside the room, it would be enough to redefine $UFRAME.
Note that in some applications $BASE and $UFRAME can be left equal to zero: this
means that the world frame and the workpiece frame are located at the base of the robot
and all taught POSITIONs are referred to the base of the robot. On the contrary, the
$TOOL transformation must always be correctly defined to achieve the desired path of
the TCP (Tool Center Point) along the trajectory.
PROGRAM setbase
VAR corner, x, xy : POSITION
BEGIN
$UFRAME := POS (0,0,0,0,0,0,")
$TOOL := ... -- correttamente definito
-- Move the TCP to three points of the part using the jog keys
and store
-- tasti di jog e memorizzare
-- the corner, x and xy POSITIONS pressing the MOD key of the
TP.
-- Then perform the following instruction.
$UFRAME := POS_FRAME(corner, x, xy)
END setbase
pr-0-0-gpr_04.fm
42 00/0210
Motion Control
– Three tool dimensions define the location component of $TOOL. These values,
measured in millimeters, represent the tool center point (TCP) offset with respect
to the flange center;
– Three tool rotations define the orientation component of $TOOL. These values,
measured in degrees, represent three rotation angles called Euler angles.
a. Begin with no tools on the robot. Assign zero values to all six tool parameters of
$TOOL.
b. Identify x, y, and z axes directions of the tool. (Note: For SMART robot, base axes
are parallel to tool axes when the robot is pointing upward and small axes are at
mid-travel).
c. Move the robot to a known position, e.g. the calibration position (Fig. 5.2 shows the
calibration position for SMART robots). Note that for some robot models, the
calibration position could be different than the shown one.
d. Check the direction of the three tool axes by jogging the robot using the TOOL jog
coordinate type.
e. Mount the tool and measure the tool centre offsets (positive or negative) with
respect to the flange centre along all three axes. Measurements should be in
millimetres.
pr-0-0-gpr_04.fm
00/0210 43
Motion Control
Example A
Tool z axis (u) coincides with axis z of the flange.
In this case no rotation assignment is required:
(e1, e2, e3) = (0, 0, 0)
Example B
Tool z axis (u) coincides with axis y of the flange.
pr-0-0-gpr_04.fm
44 00/0210
Motion Control
Example C
Tool z axis (u) is at 90 degrees with respect to the flange z
axis in the direction -y.
Rotation angles are (-90, 90, 180).
Example D
Tool z axis (u) is at 90 degrees with respect to the flange z
axis in the direction x.
Rotation angles are (0,90,180).
Example E
Tool z axis (u) is at 90 degrees with respect to the flange
z axis in the direction -x.
Rotation angles are (180, 90, 180).
pr-0-0-gpr_04.fm
00/0210 45
Motion Control
The TCP is calculated at the tool closing point. Any safety flange logically belongs
to the tool and therefore increases the z offset.
PROGRAM setframe
VAR corner, x, xy : POSITION
BEGIN
$UFRAME := POS(0,0,0,0,0,0,")
$TOOL := ... -- correctly defined
-- Jog the TCP upon three point on the workpiece and teach the
POSITIONs
-- corner, x and xy pressing the MOD key on the TP.
-- Then execute the following statement.
$UFRAME := POS_FRAME(corner, x, xy)
END setframe
5.3 Trajectory
It represents an Arm motion from an initial position to a final position.
The motion trajectory between two taught positions is generated by interpolating various
sets of variables from their initial values at the start position to their final values at the
destination position. The predefined variable $MOVE_TYPE indicates the type of
pr-0-0-gpr_04.fm
46 00/0210
Motion Control
pr-0-0-gpr_04.fm
00/0210 47
Motion Control
pr-0-0-gpr_04.fm
48 00/0210
Motion Control
pr-0-0-gpr_04.fm
00/0210 49
Motion Control
When the CNTRL C key is pressed, to interrupt the execution of a NON movement
instruction of a program open in the EZ or PROGRAM EDIT or MEMORY DEBUG
or IDE environment, the $CRNT_DATA[arm].OT_COARSE flag will still be set to
TRUE even if the instruction that was interrupted is between two FLY movements.
If the user then moves the cursor onto a specific instruction from which he wishes
to continue to run the program, skipping some programmed movements, this
could also damage the robot and/or the start of the work cycle (executed in
Remote or Local mode). Responsibility for any damage resulting from such
actions lies with the user in charge of operating and controlling the cell.
pr-0-0-gpr_04.fm
50 00/0210
Motion Control
For further details related to the $OT_xxx system variables and the ON_TRAJ_SET
built-in routine, please refer to the PDL2 Programming Language Manual.
pr-0-0-gpr_04.fm
00/0210 51
Motion Control
pr-0-0-gpr_04.fm
52 00/0210
Motion Control
pr-0-0-gpr_04.fm
00/0210 53
Motion Control
– $LIN_SPD_LIM determines the linear speed. It is a variable for each Arm, whose
value depends on the Robot and cannot be modified by the User.
It is a REAL field of the system-wide array, $ARM_DATA[], which has one structure
for each arm. The default value for $LIN_SPD_LIM is machine dependent.
(normally: 1.5 m/s).
– $ROT_SPD_LIM determines the rotational speed. It is a variable for each Arm,
whose value depends on the Robot and cannot be modified by the User.
It is a REAL field of the system-wide array, $ARM_DATA[], which has one structure
for each arm. The default value for $ROT_SPD_LIM is machine dependent.
The actual speed of motion of a specific arm is determined by computing the maximum
of the motion times for each possible rotation at $ROT_SPD_LIM and the TCP
translation time at $LIN_SPD_LIM. For example, using RS_WORLD orientation control,
three evaluations are performed:
– the time for the approach vector to go from its initial orientation to final orientation
at $ROT_SPD_LIM;
– the time for the spin about the approach vector to go from its initial orientation to its
final orientation;
– the time for the TCP to translate from its initial location to its final location at
$LIN_SPD_LIM.
The component of motion that takes the longest to get from its initial to final location will
move at the programmed speed limit, reduced by the total override. All of the other
components will move at lower than programmed limits, so that all components start and
stop at the same time.
If one of the rotations requires the most time, $ROT_SPD_LIM is used. If the translation
requires the most time, $LIN_SPD_LIM is used. The component moving at the
programmed speed limit is called the “maximum stressed” component, and it moves at
the “speed of maximum stress” or SMS.
Using this terminology, the Cartesian speed of a specific arm is determined as follows:
pr-0-0-gpr_04.fm
54 00/0210
Motion Control
$ARM_DATA.
– SPD_ROT ($ORNT_TYPE=RS_WORLD) rotates the approach vector at
$ROT_SPD, forcing all other components to move in the same time.
Note that in this case, $ROT_SPD replaces $ROT_SPD_LIM in the rotation speed
calculations. $ROT_SPD is a REAL field of the system-wide array of structures,
$ARM_DATA.
– SPD_SPN ($ORNT_TYPE=RS_WORLD) spins the approach vector at
$ROT_SPD, forcing all other components to move in the same time. (See
SPD_ROT for explanation of $ROT_SPD).
– SPD_AZI ($ORNT_TYPE=EUL_WORLD) rotates the azimuth component at
$ROT_SPD, forcing all other components to move in the same time. (See
SPD_ROT for explanation of $ROT_SPD).
– SPD_ELV ($ORNT_TYPE=EUL_WORLD) rotates the elevation component at
$ROT_SPD, forcing all other components to move in the same time. (See
SPD_ROT for explanation of $ROT_SPD).
– SPD_ROLL ($ORNT_TYPE=EUL_WORLD) spins the approach vector at
$ROT_SPD, forcing all other components to move in the same time. (See
SPD_ROT for explanation of $ROT_SPD).
– SPD_FIRST ($ORNT_TYPE=WRIST_JNT) rotates the first wrist joint at
$ROT_SPD, forcing all other components to move in the same time. (See
SPD_ROT for explanation of $ROT_SPD).
– SPD_SECOND ($ORNT_TYPE=WRIST_JNT) rotates the second wrist joint at
$ROT_SPD, forcing all other components to move in the same time. (See
SPD_ROT for explanation of $ROT_SPD).
– SPD_THIRD ($ORNT_TYPE=WRIST_JNT) rotates the third wrist joint (closest to
the tool) at $ROT_SPD, forcing all other components to move in the same time.
(See SPD_ROT for explanation of $ROT_SPD).
– SPD_AUX1 moves the first auxiliary axis at a constant speed while all other
components of the move will run at a reduced speed. If the joint is rotational, the
desired speed for the auxiliary axis should be specified by the predefined variable
$ROT_SPD. If the joint is linear the speed should be specified by the predefined
variable $LIN_SPD. If more than one auxiliary axis is present only one can move
at a constant speed and any other auxiliary axis will move at a reduced speed in
order to start and end the move at the same time.
If fly moves are executed when $SPD_OPT is set to SPD_AUXn then the auxiliary
axis will always run at a constant speed regardless of the value of $FLY_TYPE. If
$SPD_OPT is assigned a value of SPD_AUXn where n is an invalid auxiliary axis
then an error will be reported.
– SPD_AUX2 has the same effect as SPD_AUX1 except that the second auxiliary
axis is maintained at a constant speed.
– SPD_AUX3 moves the third auxiliary axis at a constant speed while all other
components of the move will run at a reduced speed so that the movement begins
and ends at the same time. All other effects of this option are the same as
SPD_AUX1.
– SPD_SM4C - the cartesian movement is performed using the Cartesian
SmartMove (optional feature).
For further information, see Chap.12. - SmartMove (optional).
In this case, the acceleration, speed and deceleration values aare automatically
calculated and it is impossible to set neither a translational ($LIN_SPD) nor a
pr-0-0-gpr_04.fm
00/0210 55
Motion Control
$LIN_SPD_RT_OVR
It is referred to $LIN_SPD predefined variable related to the motion, and indicates, as a
percentage, the new TCP speed to be used since the current motion.
The default value is 100: this means that the movement is performed at a maximum
speed equals to the $LIN_SPD. The maximum value to set $LIN_SPD_RT_OVR to, is
related to $LIN_SPD value, and is calculated as follows:
which means that it allows to reach the cartesian speed limit for the robot.
The required modification is active since the current motion, and it is applied so as not
to cause sudden changing motion, even when the Run-Time Speed Override variations
are considerably high.
For run-time linear speed variations during synchronized motions, please see
Chap.6. - Synchronous Motion (optional feature) in current Manual.
pr-0-0-gpr_04.fm
56 00/0210
Motion Control
structures.
There is an override value for each axis of each arm. The default values are 100%.
The joint speed of a specific axis is determined as follows:
joint speed[axis] =
$MTR_SPD_LIM[axis] * gear ratio[axis] * $JNT_OVR[axis] *
total speed override[arm]
where “gear ratio” indicates the transmission ratio.
The joint that takes the longest to get from its initial to final position will move at the
above computed speed. All of the other joints will move at lower speeds, so that all joints
start and stop at the same time.
1. speed
2. acceleration
Currently, C5G forces the acceleration profile to be symmetric and the deceleration
profile to be symmetric.
This means that the constant jerk phases during acceleration (T1 and T2) are the same
pr-0-0-gpr_04.fm
00/0210 57
Motion Control
length and the constant jerk phases during deceleration (T3 and T4) are the same
length.
For joint interpolated motions, the total time of acceleration and deceleration is
established by two predefined variables:
– $MTR_ACC_TIME determines the total acceleration time in milliseconds;
– $MTR_DEC_TIME determines the total deceleration time in milliseconds.
These variables are INTEGER array fields of $ARM_DATA, one element for each axis
for each arm. For a joint interpolated motion, the time for the joint that takes the longest
to accelerate/decelerate to its final speed is picked for the time to use for all joints to
accelerate/decelerate. This maintains coordinated acceleration and deceleration.
For Cartesian motions, $LIN_ACC_LIM and $LIN_DEC_LIM are used in a similar way,
to establish the total time for acceleration/deceleration. However the units for these
variables are meters per second per second.
The percentage of acceleration time and deceleration time used in the constant jerk
phases is determined by the predefined $ARM_DATA INTEGER array field, $JERK[],
as follows:
– $JERK[1] defines the percentage of the acceleration time in the constant jerk
phase (T1 + T2);
– $JERK[2] is reserved for future use;
– $JERK[3] is reserved for future use;
– $JERK[4] determines percentage of deceleration time in constant jerk (T3 + T4).
For example, if $JERK[1] is set to 40, then 20% of the time specified in
$MTR_ACC_TIME will be T1, 60% in constant acceleration, and 20% will be T2.
$JERK[] is read-only from a PDL2 program.
pr-0-0-gpr_04.fm
58 00/0210
Motion Control
$GEN_OVR*$ARM_DATA[arm].ARM_OVR*$ARM_DATA[arm].ARM_ACC_OVR*
$PROG_ACC_OVR
pr-0-0-gpr_04.fm
00/0210 59
Motion Control
pr-0-0-gpr_04.fm
60 00/0210
Motion Control
pr-0-0-gpr_04.fm
00/0210 61
Motion Control
a predefined variable array of joint tolerances, $TOL_JNT[]. The short range reset takes
place by means of a move in joints interpolation that is entirely transparent to the user.
That is, when START button is pressed to resume a motion, a short range recovery
motion will be inserted immediately before the original motion is resumed. In many
cases, this reset move is not even perceived by the operator.
If the distance between the current position and the nominal position is major to a certain
limit (short range) the resumption of motion takes place according to the modes defined
by the predefined variable $RCVR_TYPE value set. The possible values of this
predefined variable are shown in the following table:
0 Bring the arm to the interrupted trajectory position, by the joint interpolation.
1 Bring the arm to the movement start position that was interrupted by the joint interpolation.
2 Bring the arm to the interrupted movement destination position using the joint interpolation.
3 Do not reset, generate an error message.
4 If the interrupted movement was Cartesian, restore the interrupted trajectory by a straight-line
movement. Otherwise use joint interpolation .
5 If the interrupted movement was Cartesian, bring the arm back to the start position of the interrupted
movement by a straight-line interpolation. Otherwise use joint interpolation .
6 If the interrupted movement was Cartesian, bring the arm to the interrupted movement destination
position by a straight-line interpolation. Otherwise use joint interpolation .
7-8 reserved
pr-0-0-gpr_04.fm
62 00/0210
Motion Control
Simplest situation.
1. Programmed Fly position, between two movements
2. First movement - fly termination
3. Second movement - fly beginning
4. Second movement - fly termination
5. Stop position
6. Motion direction
7. First movement – fly beginning
pr-0-0-gpr_04.fm
00/0210 63
Motion Control
pr-0-0-gpr_04.fm
64 00/0210
Motion Control
Note that the return movement is possible during linear or circular type movements only.
The system reads the value of the distance to be recovered after each stop. Therefore,
if $RCVR_DIST is adjusted during the return movement, the value will only become
effective after the next stop.
If the return movement is interrupted, the $RCVR_DIST value is read again but the
distance to be recovered is always calculated starting from the point of the original
interruption (Fig. 5.8 - Example in case of $RCVR_DIST modification).
Any actual movement CONDITIONs are re-enabled at the next restart after the return
movement. However, if these have not been stated by means of the clause NODISABLE
they can only be released once.
If WHEN RESUME is enabled for an actual movement, this will be signalled at the end
of the return movement immediately before restarting the interrupted trajectory.
As for normal trajectory restore movements, automatic LOCK can be effected by means of
the variable $CRNT_DATA[num_arm].RCVR_LOCK. If the variable value is set to TRUE,
the system is automatically set to the LOCK state upon completion of the return movement.
There are four system events, one per arm, that signal entrance into the automatic LOCK
state (see “WHEN EVENT 130...133” in PDL2 Programming Language Manual). In
order to restart the movement a RESUME instruction must be effected by means of a
program PDL2 or the EXECUTE command on the Service page of the Teach Pendant
(in PROGR status).
pr-0-0-gpr_04.fm
00/0210 65
Motion Control
1. motion direction
2. trajectory
3. calculated return movement
4. $RCVR_DIST
5. decelerate distance
6. motion stop command
7. actual motion stop position
See Fig. 5.9 - Example of continuous motion in case of linear movement. If another
motion follows the MOVEFLY, the arm will not stop at the first destination.
pr-0-0-gpr_04.fm
66 00/0210
Motion Control
5.10.2.1 FLY_NORM
With $FLY_TYPE set to FLY_NORM, MOVEFLY causes the deceleration of the issued
motion to be overlapped with the acceleration of the next motion.
The predefined variable, $FLY_PER (the only one associated to FLY_NORM), can be
used to reduce the time in fly and to bring the trajectory closer to the intermediate taught
position. FLY_NORM is the default value.
Fly will begin at the start of normal deceleration for the motion plus a time equal to 100%
minus the percentage specified in $FLY_PER.
For example, if the value of $FLY_PER is 100%, the fly begins at the start of
deceleration of the fly motion. If $FLY_PER is 75%, then fly will begin after 25% of the
deceleration is finished (75% will be combined with the next motion).
The motion speed during fly is normally not constant. If two straight line segments are
joined by fly and are collinear then the TCP will move at constant speed through the
intermediate taught position as if there were one long segment. However, as the angle
between the two segments increases, the TCP will slow down near the intermediate
position, then speed up again as it moves into the next segment. The most extreme
example of course would be when the angle is 180 degrees (the TCP reverses
direction). In this case, the TCP will stop completely, but not at the intermediate taught
position.
This type of continuous motion control generally causes the least stress on the arm and
part or tool during direction changes. Therefore, FLY_NORM is the default value for
$FLY_TYPE. If the angle between motion segments is very acute, then lower stress can
pr-0-0-gpr_04.fm
00/0210 67
Motion Control
pr-0-0-gpr_04.fm
68 00/0210
Motion Control
pr-0-0-gpr_04.fm
00/0210 69
Motion Control
When the fly motion type is set to FLY_CART, the trajectory can be controlled by setting:
– $FLY_DIST specifies a distance (in millimiters, default 5 mm) between the the
taught intermediate position and some point on the trajectory. The exact meaning
of the distance is determined by
– $FLY_TRAJ which can be set to
• FLY_AUTO it is the control which picks the closest trajectory to the
intermediate position that achieves the programmed speed without exceeding
the $STRESS_PER value.
Achieving and maintaining programmed speed has higher priority than
nearness to the intermediate position.
• FLY_TOL guarantees the TCP to pass a distance less than $FLY_DIST from
the intermediate point of the trajectories.
If the generated trajectory falls within the distance $FLY_DIST, then the
trajectory will remain unchanged. However, if the trajectory is outside this
limit, then that distance limit will be respected and the speed will be reduced
to maintain the limits specified by $STRESS_PER and $FLY_DIST.
• FLY_PASS attempts to move the TCP at the exact distance from the medium
point.
If the planned distance, specified by $FLY_DIST, is too long with respect to
the length of the trajectories, then the fly trajectory is calculated to cross at the
maximum distance possible. If the distance specified is less than that which
would be produced by FLY_AUTO, the speed will be reduced to respect the
limit set by $STRESS_PER (the distance specified will still be maintained
exactly).
• FLY_FROM forces the fly motion to begin at the distance specified by
$FLY_DIST from the taught intermediate position.
Note that the dynamics of the machine could make it impossible for the programmed
distance to be maintained. This becomes more likely as the value of $STRESS_PER is
decreased.
The above picture (Fig. 5.11 - FLY Movements) shows an example of the use of these
pr-0-0-gpr_04.fm
70 00/0210
Motion Control
system settings. With $FLY_DIST set equal to 20 mm, the following results will be seen.
When the value of $FLY_TRAJ is set to:
– FLY_TOL, then the distance A will be less than or equal to 20 mm;
– FLY_PASS, then the distance A will be 20 mm;
– FLY_FROM, then the distance B will be 20 mm.
PROGRAM mov_cart
CONST
arm_num = 1
cond_num = 1
ROUTINE print_debug
BEGIN
WRITE ($CRNT_DATA[arm_num].FLY_DBUG, NL)
END print_debug
BEGIN
$CRNT_DATA[arm_num].FLY_DBUG := 0
CONDITION[cond_num] NODISABLE :
WHEN AT END DO
print_debug
ENDCONDITION
-- initialisation
ENABLE CONDITION[cond_num]
-- move statements
END mov_cart
pr-0-0-gpr_04.fm
00/0210 71
Motion Control
pr-0-0-gpr_04.fm
72 00/0210
Motion Control
1 - Flange Frame 2 - User Frame 3 - TCP Frame 4 - Fixed Tool 5 - Base Frame
pr-0-0-gpr_04.fm
00/0210 73
Motion Control
pr-0-0-gpr_04.fm
74 00/0210
Motion Control
For the configuration parameters, see the Chap. Use of Positioners managed by
C5G.
5.12.1.1 Jogging
Moving the slide/integrated column manually (jog), the robot acts differently according
to the handing mode set: in joints mode, pressing the key corresponding to the
slide/column, the robot axes do not move; only the auxiliary axis moves. On the other
hand, in Cartesian mode of manual motion (BASE, TOOL, UFRAME) key 7 moves the
slide/column, keeping the TCP stationary, wherever the robot axes compensate the
movement of the auxiliary axis.
pr-0-0-gpr_04.fm
00/0210 75
Motion Control
5.12.1.3 Restrictions
Integrated movement of the slide/column and robot is possible in the following
conditions:
– there are no limitations as regards the robot model; however this can be positioned
in relation to the flange of the slide/column in only eight positions, i.e.: the
Zbase_robot axis always parallel to Zbase_slide/column (in both directions) and the
Xbase_robot axis aligned with the Xbase_slide/column or Ybase_slide/column (four possible
directions);
– the axis corresponding to the slide/column must be the first available auxiliary axis;
– it is possible to integrate a single slide or column for each robot;
– it is not possible to enable or disable integration of the slide/column in real time (the
controller must be restarted).
pr-0-0-gpr_04.fm
76 00/0210
Motion Control
5.13.1 Enabling
a. Move the robot (the functionality must be disabled) to the required position to
enable it,
– from Teach Pendant - select the required Arm, move the focus to the
Palletizer Status in the Motion Page - Status subpage (see Fig. 5.14 - yellow
highlighted field), so that Enable (F1) softkey is displayed in the Bottom Menu
(see Fig. 5.14 - red highlighted key). Press the key.
c. Verify that in the sixth field of the TP status bar, Pallet is now specified (see
Fig. 5.15 - purple highlighted field).
NOTES
– Since the activation moment, it will NOT be possible to jog the robot axes
which are bind to keep the second Euler angle geometry to 180° (which
means to have the flange position parallel to the floor), and axis 4.
– In the trajectory generation, the system will automatically take care of
computing optimized trajectory for palletizing operations.
– It is possible to use the robot as a Palletizer, both in programming mode and
in automatic cycle.
5.13.2 Disabling
To disable the Palletizing Functionality and recover the usual robot functioning again, it
pr-0-0-gpr_04.fm
00/0210 77
Motion Control
– from Teach Pendant - move the focus to the Palletizer Status in the Motion Page
- Status subpage (see Fig. 5.15 - yellow highlighted field), so that Disable (F2)
softkey is displayed in the Bottom Menu (see Fig. 5.15 - red highlighted key). Press
the key.
BEGIN
$JNT_MTURN := FALSE
ARM_PALLETIZING(ON,1)
MOVE JOINT NEAR pnt0002P BY 300
MOVEFLY LINEAR TO pnt0002P ADVANCE
MOVEFLY LINEAR NEAR pnt0003P BY 20 ADVANCE
MOVE LINEAR TO pnt0003P
MOVEFLY LINEAR AWAY 400 ADVANCE
MOVEFLY JOINT TO pnt0004P ADVANCE
MOVEFLY LINEAR TO pnt0005P ADVANCE
MOVEFLY LINEAR NEAR pnt0006P BY 300 ADVANCE
MOVEFLY LINEAR TO pnt0006P ADVANCE
MOVEFLY LINEAR NEAR pnt0007P BY 20 ADVANCE
MOVE LINEAR TO pnt0007P
MOVEFLY LINEAR AWAY 1000
ARM_PALLETIZING(OFF,1)
END test_arm_palletizing
pr-0-0-gpr_04.fm
78 00/0210
Synchronous Motion (optional feature)
This chapter describes the Synchronous Motion optional i.e., the synchronous motion
between a robot and other axes.
In particular, the following subjects are dealt with:
– Synchronization with Auxiliary Axes
– Synchronized Arms
– Motion limitation of the two Arms
– Jogging Synchronized Arms
– Teaching and Modifying Positions (REC/MOD) with Synchronized Arms
– Loss of Synchronization
– Run-time modifying the Linear Speed Override
the MASTER Arm is ARM[1] and the SERVER Arm is ARM[2]; whereas in the next
synchronised MOVE :
pr-0-0-gpr_07.fm
00/0210 79
Synchronous Motion (optional feature)
PROGRAM example
BEGIN
-- the main arm is arm 1, the synchronised arm
-- is arm 2
MOVE ARM[1] TO p1 SYNCMOVE ARM[2] TO p2
MOVE TO p1 SYNCMOVE ARM[2] to p2
-- $PROG_ARM moves on p1
MOVE ARM[1] TO p1 SYNCMOVE TO p2
-- ERROR: $SYNC_ARM is not initialised
$SYNC_ARM := 2 -- $SYNC_ARM is initialised
MOVE ARM[1] TO p1 SYNCMOVE TO p2
-- $SYNC_ARM (arm 2) moves on p2
MOVE TO p1 SYNCMOVE TO p2
-- $PROG_ARM and $SYNC_ARMEND are used, example
The ADVANCE clause is applied to the entire MOVE... SYNCMOVE. To perform a fly it
is necessary to specify the FLY clause on the main move and insert ADVANCE before
SYNCMOVE:
MOVEFLY TO p1 ADVANCE,
SYNCMOVEFLY ARM[2] TO p2,
ENDMOVE
If an ADVANCE is inserted after p2, the translator sees a warning message and
automatically corrects instruction.
It will be the task of the user to specify a speed option that is compatible with the
combined motion, since for both Arms all the limitations are valid that are present on the
pr-0-0-gpr_07.fm
80 00/0210
Synchronous Motion (optional feature)
individual robot: for example a short translation of the MASTER Arm, with
$SPD_OPT:=SPD_LIN, combined with a wide variation of the SERVER Arm orientation,
imposes an over-speed on the SERVER Arm that cannot be controlled with the override
values only.
It can be seen that in the programming of a multi-arm system with two robots that both
move in Cartesian mode with
$SPD_OPT:=SPD_LIN and with
$LIN_SPD equal,
but on paths of different lengths, only the MASTER Arm will observe the speed
restriction, whereas the SERVER Arm will move faster if it has to cover a longer path,
more slowly if the path is shorter.
For further information, please refer to C5G Control Unit Use manual, IDE Page
section.
pr-0-0-gpr_07.fm
00/0210 81
Synchronous Motion (optional feature)
LOCK ARM[1]
LOCK ARM[2]
After having locked both arms at the same time, even if arm 1 is resumed with the
RESUME ARM[1] statement, the synchronized motion does not restart. Only if the other
arm is also resumed, the synchronized move restarts on both the arms (RESUME
ARM[2]).
In single Arm systems, there is only one predefined variable to be used to Run-time
modifying the linear speed: $LIN_SPD_RT_OVR.
Viceversa, in multi-arm systems, there is a $LIN_SPD_RT_OVR for each Arm; in order
to Run-Time modify the linear speed, it is needed to identify which one is to be used
while executing a SYNCMOVE.
It is very important to exactely understand on which Arm such a functionality is currently
active. To do that, operate as follows:
Let’s have the following PDL2 statement
pr-0-0-gpr_07.fm
82 00/0210
Synchronous Motion (optional feature)
In order to understand if the Run-time modification of the linear speed does apply, and
which is the involved Arm, just check the second bit of the following field:
$CRNT_DATA[num_arm].C_ALONG_1D[50]
it is automatically set by the system software, for the Arm on which the Run-time
modification functionality is active. If such a bit is set to TRUE, it means that the
associated Arm acts as master, as regards the Run-time speed modification during the
SYNCMOVE execution, while the other Arm follows the modifications. In such a way,
the motion synchronization is always satisfied.
pr-0-0-gpr_07.fm
00/0210 83
Cooperative Motion (optional feature)
pr-0-0-gpr_08.fm
84 04/0711
Cooperative Motion (optional feature)
To enable and disable cooperative motion, the following built-in procedure is available:
pr-0-0-gpr_08.fm
04/0711 85
Cooperative Motion (optional feature)
simply enabling it and moving the positioner and the working arms. However from a
programming point of view, synchronization is preferred.
Fig. 7.3 - System frames with cooperative Arms shows how the different frames of
reference for the two arms are defined. The positioner (arm 2) moves its TCP (defined
by $ARM_DATA[2].TOOL) with respect to its user frame ($ARM_DATA[2].UFRAME),
while the TCP of the working arm ($ARM_DATA[1].TOOL) moves the TCP with respect
to a frame of reference referred to by the TCP of the positioner (by means of
$ARM_DATA[1].UFRAME).
flag is a boolean parameter which can be set to either ON or OFF, respectively to enable
or disable the multi-cooperative motion;
aux_joint is the number of the auxiliary axis. It can be omitted if flag is set to OFF; on the
contrary, when flag is ON, aux_joint is needed;
positioner_arm, if present, specifies the number of the positioner arm. If not present,
$SYNC_ARM is assumed;
working_arm, if present, represents the number of the working arm. If not specified,
$PROG_ARM is used.
pr-0-0-gpr_08.fm
86 04/0711
Cooperative Motion (optional feature)
1. Working Arm
2. Positioner’s Arm
This optional functionality needs the following software option: ‘Cooperative motion’ -
see chap. Appendix - Software Options in Use of the C5G Control Unit manual.
7.4 Jogging
Cooperative motion provides easy programming for while jogging the positioner arm, the
working one follows the positioner in order to keep constant the torch position (location
and orientation) with respect to the workpiece. This feature simplifies the programming
of complex trajectories, saving time and reducing the number of points that must be
taught.
The cooperation during jog must be enabled with the ARM_COOP (for cooperative
arms), AUX_COOP (for auxiliary axes cooperation) and ARM_COOP (for
multi-cooperation) built-in procedures. These can be executed inside the program by
means of the key or through the Execute command on the Service page (Execute
softkey) on the Teach Pendant.
pr-0-0-gpr_08.fm
04/0711 87
Sensor Tracking (optional feature)
pr-0-0-gpr_10.fm
88 00/0210
Sensor Tracking (optional feature)
that is different to that programmed. Let us suppose that the program consists of a joints
move on a start position, followed by two linear moves linked in fly and a final joints move
to reach a position out of range.
The program could be the following:
PROGRAM sensor
VAR
p1, p2, p3, p4 : POSITION
BEGIN
$SPD_OPT:=LIN_SPD--To check the linear speed
$LIN_SPD:=0.1 --Linear speed in m/s
MOVE JOINT TO p1
MOVEFLY LINEAR TO p2 ADVANCE
MOVE LINEAR TO p3
MOVE JOINT TO p4
END sensor
If the sensor is enabled along the Cartesian path from p1 to p3, the effect could be as
shown in Fig. 8.1 - Programmed trajectory and sensors control where the dashed line is
the programmed trajectory and the continuous line is the trajectory actually travelled by
the TCP under the control of the sensor; the arrow between the two trajectories is the
deviations vector. It can be seen in the example that the tracking terminates when the
nominal position reaches point p3; on this point, the Control Unit re-acquires the actual
position and resets the deviations accumulated along the path, then the next joints move
will terminate exactly on the programmed point p4 as required. The following
paragraphs illustrate all the characteristics of the sensor tracking environment with
explanations on how to use the system and Built-In variables to program applications
that use sensors.
1. Starting point
2. Arrival point
3. Programmed trajectory
4. Trajectory controlled by sensor
pr-0-0-gpr_10.fm
00/0210 89
Sensor Tracking (optional feature)
Tracking; ; it also indicates the limits, the default value and whether the WITH clause
can be used with the variables. Since all the variables are $ARM_DATA fields, they are
not reset when the program where they have been modified is deactivated.
Furthermore, by executing Config.Function (F1) - Save the configuration file,
SETUP Page on the TP, they are saved in 'file.C5G' with their current value Tab. 8.2
- Built-In for Sensor Tracking illustrates the built-ins for sensors management.
pr-0-0-gpr_10.fm
90 00/0210
Sensor Tracking (optional feature)
The $SENSOR_TYPE values for this type of sensor are between 1 and 4. Values 1 and
2 are reserved to the first board and values 3 and 4 to the second one (see Tab. 8.3).
In the case of integrated sensors, the communication of the sensor information takes
place at software level and therefore the values are not known directly at PDL2 level. To
read them there is the following Built-In SENSOR_GET_DATA:
pr-0-0-gpr_10.fm
00/0210 91
Sensor Tracking (optional feature)
the characteristics of the actual sensor, that is to say, according to its position and the
type of physical value measured. To cover all the possibilities, the following cases can
be determined: TOOL, USER, WORLD and WEAVE reference. To select these
different cases the $SENSOR_TYPE system variable is used .
1. Flange
2. Tool
3. Sensor
4. Sensor frame
5. TCP frame
pr-0-0-gpr_10.fm
92 00/0210
Sensor Tracking (optional feature)
Also in this case it may be necessary to assign a specific reference system to the
sensor, calculated according to the USER system. This can be obtained with the same
$SFRAME variable that, in these modes, represents a conversion in relation to the
USER reference (it follows $UFRAME in the kinematic chain, see Fig. 8.3 - User frame
conversion).
1. World frame
$SFRAME also serves to select the centre of rotation for the tool geometry corrections.
If $SFRAME is not zero, the centre of rotation is defined by the $SFRAME itself,
whereas if all the components are null, the centre of rotation coincides with the TCP.
pr-0-0-gpr_10.fm
00/0210 93
Sensor Tracking (optional feature)
a vector of 6 REAL type elements that contain the conversion factors. Each sensor data
component is multiplied by a corresponding conversion factor before being applied to
the trajectory.
– for example a proximity sensor supplies a current or a voltage that can be
converted in millimetres by multiplying by a specific mm/A or mm/V factor ;
– the force sensors are a separate category, since they do not measure a position or
a physical value directly connected to them, but give an indication that there is the
"need to correct the trajectory" in a certain direction. For these sensors the factor
by which the signal is multiplied assumes the significance of a gain since with an
equal signal a correction is calculated in millimetres without being able to know the
exact size of the correction required.
If it is wished to exclude the effect of this conversion, it is sufficient to set the
$SENSOR_CNVRSN components to value 1 (default value). $SENSOR_CNVRSN can
also disable the application of one or more components of the correction: this is obtained
by setting the corresponding element of the vector to zero ($SENSOR_CNVRSN[n]:=0).
1. Programmed trajectory
2. Trajectory controlled by sensor
3. Correction required = +3 mm
pr-0-0-gpr_10.fm
94 00/0210
Sensor Tracking (optional feature)
4. Required = +1 mm
5. Required = -2 mm
6. Final deviation = 0 mm
7. Required = 0 mm
1. Programmed trajectory
2. Trajectory controlled by sensor
3. Correction required = +3 mm
4. Required = +1 mm
5. Required = -2 mm
6. Final deviation = 0 mm
7. Required = 0 mm
For integrated sensors the choice between the two modes (absolute or relative)
depends on the type of sensor, and it is managed by system software. For external
sensors there is a possibility to choose by means of the $SENSOR_TYPE system
variable: the values from 5 to 9 enable the relative mode functioning, whereas from 9 to
12 enable absolute mode (Tab. 8.3 - Correction_Speed = Factor*Reference_Speed).
– in most industrial applications the sensors measure the RELATIVE deviations
since they are able to determine the optimal trajectory position in relation to their
own position. Also in the case of force sensors the most frequent use is to consider
the data measured in relative mode. This means that until the sensor output differs
from zero the trajectory is continually modified adding new deviations to the old
ones, whereas when the output is null, the accumulated corrections are kept and
the robot trajectory remains parallel to the nominal one (Fig. 8.4 - Absolute
deviations);
– the correction in ABSOLUTE mode is useful to obtain a yielding effect on the TCP
by means of force sensors. In practice a deviation is applied to the robot trajectory
that is proportional to the force sensor output. This causes the entire robot to
behave like a spring in all directions since as the measured force intensity
increases, the robot deviation from the programmed trajectory increases, when
there is no stress the robot returns to follow the programmed path (Fig. 8.5
- Relative deviation).
pr-0-0-gpr_10.fm
00/0210 95
Sensor Tracking (optional feature)
– define a time period (TIME PERIOD) during which the entire deviation will be
assimilated.
The first criterion guarantees the execution of the correction in the least time possible
and is useful in all cases where the time that lapses between two sensor readings is very
short (high frequency) or is not known.
However, in some applications this method determines a correction in "spurts" since ,
for small deviations the corrections are applied with a fast, brief movement of the robot.
In these cases the second criterion is more effective because it makes it possible to
distribute the entire deviation over a pre-set time.
To choose between these two modes the $SENSOR_TIME variable is used. If
$SENSOR_TIME is zero, the speed criterion is used. A value that is not zero selects the
second mode and indicates the time (in milliseconds) during which the correction is to
be applied.
For external sensors the new data will be read by the sensor only after this time has
expired, starting from the last corrections. Fig. 8.6 - Effects of $SENSOR_TIME (with
relative corrections) illustrates the effect of the two different criteria.
1. Programmed trajectory
2. Trajectory controlled by sensor
In both the correction distribution modes, the speed can be assigned through the
$SENSOR_GAIN system variable. It is a vector with 6 INTEGER elements that have a
percentage significance (variability from 0 to 100 with default 50). It allows the program
to ratio the correction speed with the programmed movement execution speed.
The first three elements regard the translations in the X, Y and Z directions and in the
case of $SPD_OPT=SPD_LIN, they represent a measurement of the angle between
the programmed trajectory and that which results from the correction. The value 50%
corresponds to the slope of 45 degrees (correction speed equal to the advance speed,
$LIN_SPD), whereas the values 0% and 100% represent the extreme cases of no
pr-0-0-gpr_10.fm
96 00/0210
Sensor Tracking (optional feature)
The $SENSOR_GAIN variable is also taken into consideration when the criterion for the
distribution of the deviations is time ($SENSOR_TIME is not zero). In this case the
$SENSOR_GAIN components will be used to define the maximum correction speed
(Fig. 8.7 - Effects of $SENSOR_GAIN). To avoid all types of limitation the
corresponding $SENSOR_GAIN value can be set at 100%.
pr-0-0-gpr_10.fm
00/0210 97
Sensor Tracking (optional feature)
The use of this variable will depend on the measuring accuracy of the sensor used, and
the frequency with which these measures are supplied. If the sensor gives a precise
indication of the deviation that is to be assimilated (in millimetres) but with a low
frequency, the value of $SENSOR_GAIN is directly linked to the correction speed. If
instead the sensor is able to give only a generic indication on the direction in which the
correction is required, the $SENSOR_GAIN variable can be used as a gain, i.e. as a
parameter to be set-up on the basis of the fluctuations that are observed during the
application.
pr-0-0-gpr_10.fm
98 00/0210
Sensor Tracking (optional feature)
b. the start of the enslaving always depends on the pressing of the START key, until
that moment the user is certain that the machine cannot move;
c. movement under the control of the sensor can be stopped by pressing the HOLD
key and can only start again when the START key is pressed;
b. since the SENSOR_TRK can only be run within HOLDABLE programs, it cannot
be run neither using the Execute (F1) command - Service Page (Exec softkey) on
the TP, nor by the SYS_CALL of the EXECUTE command;
e. the SENSOR_TRK mode is automatically disabled when the program that enabled
it is deactivated.
The enabling and disabling of the tracking in this mode has certain effects on the holding
or resetting of overall deviations (see par. 8.9 Accumulative overall deviations
management on page 101).
pr-0-0-gpr_10.fm
00/0210 99
Sensor Tracking (optional feature)
1. Programmed trajectory
2. Trajectory controlled by sensor
3. Trajectory after a sensor failure
4. Optimal trajectory
5. HOLD caused by an error message
Not only the translation deviations (first three components) are redefined, but also those
of geometry variations, therefore, if it is wished to resume the move with the same
geometry as when the stoppage took place, this must not be changed during the jog
session.
The $RCVR_TYPE=8 mode is useful in such cases and permits the move to be
resumed returning exactly on the programmed trajectory resetting the deviations
accumulated by the sensor; in this mode the C5G plans a trajectory that recovers the
pr-0-0-gpr_10.fm
100 00/0210
Sensor Tracking (optional feature)
current position to correspond to the programmed trajectory and resume the interrupted
move.
After recovery, the deviations will be reset. Fig. 8.9 - Effect of $RCVR_TYPE = 8 shows
how this mode functions.
The functioning of $RCVR modes from 0 6 are not submitted to variations in the case of
enabled sensor tracking. Therefore modes 0 and 4 bring the TCP exactly on the
interrupted position keeping the deviations accumulated up to that moment, whereas
modes 1, 2, 5 and 6 bring the robot on the programmed initial and final positions,
resetting the deviations.
pr-0-0-gpr_10.fm
00/0210 101
Sensor Tracking (optional feature)
difference between the two programs consists in the fact that the fly has been removed
(and also the ADVANCE) on the intermediate p2.
The result in practice is that the linear move to p3 will be executed no longer starting
from the programmed point p2 but from point p2'; in p2 the deviations are reset.
If tracking is enabled with the SENSOR_TRK(TRUE) option, the action changes since
this option makes it possible to leave the robot enslaved to the sensor, without a
programmed move and during the interruption. Looking again at the example in the case
of SENSOR_TRK(TRUE), a behaviour that is just the same as in Fig. 8.1 - Programmed
trajectory and sensors control can be noted notwithstanding that the fly and the
ADVANCE have been removed; in other words, no interruption takes place on p2. The
resetting will take place the moment the enslaving condition is interrupted with the
SENSOR_TRK(FALSE) or $SENSOR_ENBL:=FALSE instruction.
This indicates that the Built-In SENSOR_TRK(TRUE) can be used to avoid the resetting
of deviations on points where the robot stops (where there is no fly).
pr-0-0-gpr_10.fm
102 00/0210
Sensor Tracking (optional feature)
1. Programmed trajectory
2. Trajectory controlled by sensor
3. OFFSET RESET without interrupt
pr-0-0-gpr_10.fm
00/0210 103
Sensor Tracking (optional feature)
PROGRAM sensor
VAR
p1, p2, p3, p4:POSITION
corr_y, corr_z:REAL
corr, ofst:ARRAY[6] OF REAL
ROUTINE send_corr
BEGIN
get_corr(corr_y, corr_z)
corr[2]:=corr_y; corr[3]:=corr_z
SENSOR_SET_DATA(corr)
SENSOR_GET_OFST(ofst)
WRITE (‘X:‘, ofst[1], ‘ Y; ‘, ofst[2], ‘ Z: ‘, ofst[3], NL)
$TIMER[1] := 0
ENABLE CONDITTRUE[1]
END send_corr
BEGIN
pr-0-0-gpr_10.fm
104 00/0210
Sensor Tracking (optional feature)
CONDITION[1] :
WHEN $TIMER[1] > 500 DO
send_corr --Corrections sent every 500 ms
ENDCONDITION
corr[1]:=0; corr[2]:=0; corr[3]:= 0
corr[4]:=0; corr[5]:=0; corr[6]:= 0
-- Program in movement
MOVE JOINT TO p1
$SENSOR_ENBL := FALSE
DISABLE CONDITION[1]
MOVE JOINT TO p4
END sensor
pr-0-0-gpr_10.fm
00/0210 105
Conveyor Tracking (optional feature)
9. CONVEYOR TRACKING
(OPTIONAL FEATURE)
For any information about this functionality, please contact Comau.
pr-0-0-gpr_11.fm
106 00/0210
Motion with Weaving (optional feature)
pr-0-0-gpr_09.fm
03/0111 107
Motion with Weaving (optional feature)
moves with weaving are not linked with a continuous motion (fly). This principle is
applied not only to singular motions, but also in case of path segments (PATH).
pr-0-0-gpr_09.fm
108 03/0111
Motion with Weaving (optional feature)
pr-0-0-gpr_09.fm
03/0111 109
Motion with Weaving (optional feature)
Note that the following formula is used for transverse speed calculation
Left amplitude
Transverse speed = ----------------------------
ts
Meaning of the terms ts[n] (ramp up or down times), according to the weaving
modality:
– Modality 0 - ts times are all equal and are generated to reach a transverse
speed $weave_tbl[n].wv_trv_spd;
– Modality 1 - the ts times are all equal and are generated to create the weaving
period according to the programmed wave length;
– Modality 2 - The ts[n] times are generated to reach the respective transverse
speeds $weave_tbl[n].wv_trv_spd_phase[n].
pr-0-0-gpr_09.fm
110 03/0111
Motion with Weaving (optional feature)
The amplitude, dwell, smoothness, and speed fields will take affect immediately after the
change (even during a weave motion). The direction and amplification factor will take
affect only on the first move with weaving.
When the left and right dwells are set to 0, a triangular or sawtooth wave shape results.
The sharp peaks of the sawtooth shape can be rounded to produce a sinusoid-like
shape by setting the smoothing field to TRUE. Fig. 10.3 shows the different shapes that
can be achieved using the $WEAVE_TBL settings.
1 - Not smoothed sawtooth, 2 - Smoothed sawtooth 3 - Trapezoidal (left and right dwell)
4 - Chamfering variation during motion, with central dwell time 5 - Different left and right amplitudes
6 - Circular
The weave wave frequency, according to the modality used, is calculated in one of these
ways:
– modality 0
– modality 2
where:
dwell sum = left dwell + right dwell + 2 * center dwell (ms)
The maximum frequency is dependent on the mechanical design of the arm, but the
weave shape will match the theoretical up to about 5 Hz (cartesian weaving) or 8 Hz
(joint weaving) on arms intended for arc welding.
pr-0-0-gpr_09.fm
03/0111 111
Motion with Weaving (optional feature)
The weave parameters - B (see Fig. 10.2) are valid for any wave form.
La frequenza nel caso di forma d'onda circolare descritta dalla velocità trasversale è:
1 - Torch plane 2 - Path 3 - Weaving plane angle 4 - Approach vector (along Z Tool)
5 - Weaving plane 6 - Zero plane 7 - Weaving plane angle 8 - Zero plane
9 - Weaving plane 10- Approach vector (along Z Tool)
pr-0-0-gpr_09.fm
112 03/0111
Motion with Weaving (optional feature)
The weave plane is established by rotating from the zero plane about the trajectory
tangent by the rotation angle specified in $WEAVE_TBL[n].WV_PLANE. A positive
angle is clockwise, looking at the trajectory direction. Fig. 10.5 shows such a procedure.
Weaving can be executed between two trajectories connected in fly; in this case, the
direction of weaving on the second trajectory is recalculated maintaining the angle of
inclination in relation to the plane of the two trajectories. Weaving will change from one
direction to another without interruption. This capability promotes very simple
programming of complex paths. The angle must be assigned only at the start of the first
movement with weaving and the control will automatically calculate the direction of
subsequent movements, Note that, on the second trajectory, the angle between the
plane of the torch and the direction of weaving will no longer be equal to the angle
indicated in $WEAVE_TBL[n].WV_PLANE; the control will refer to this angle only for the
first movement with weaving.
The trajectory weaving connected in fly can be improved in some cases by using the
FLY_CART mode. The weaving direction continuously evolves during fly, without being
interrupted when passing from one motion segment to another. (par. 5.10.2.2
FLY_CART (Controller Aided Resolved Trajectory) on page 68) section for futher
details.
For a circular motion, the weave plane is continuously evaluated relative to the path, so
that the weave direction is always perpendicular to the path. If the weave plane is not
parallel to the plane of the circle, the weave plane will be on the frustum of a cone as
shown in Fig. 10.7 - Circular Weaving.
pr-0-0-gpr_09.fm
03/0111 113
Motion with Weaving (optional feature)
pr-0-0-gpr_09.fm
114 03/0111
Motion with Weaving (optional feature)
pr-0-0-gpr_09.fm
03/0111 115
Motion with Weaving (optional feature)
pr-0-0-gpr_09.fm
116 03/0111
Motion with Weaving (optional feature)
10.6.1 Mode
The weaving without Arm motion mode is activated by means of
$CRNT_DATA[num_arm].WEAVE_TYPE_NOMOT predefined variable which has got
the same functionalities as described in par. 10.1 Weaving Mode on page 107: the only
difference is that such a mode is performed without a motion embedded to the weaving.
10.6.2 Activation
For this functionality too, the activation is performed by means of defining the weave
table; it is anyway needed to use the predefined variable
$CRNT_DATA[2].WEAVE_NUM_NOMOT
which specifies that the weaving functionality will be performed without Arm motion.
The weave tables are exactely the same as for the weaving with Arm motion. In such a
way, if in a PDL2 program the user needs to perform both weaving with and without Arm
motion, the same information can be used.
10.6.3 Parameters
The used parameters belong to the same group described in the previous I parametri
utilizzati appartengono allo stesso insieme introdotto nel par. 10.3 Weaving Parameters
on page 108.
Anyway, there are some features which make a no-sense for this functionality: e.g.
mode 1 cannot be selected which involves a wave shape related to the wavelength,
because the Arm does not move.
pr-0-0-gpr_09.fm
03/0111 117
Motion with Weaving (optional feature)
$WEAVE_TBL[1].WV_LEFT_AMP := 5
$WEAVE_TBL[1].WV_RIGHT_AMP := 5
$WEAVE_TBL[1].WV_LEFT_DWL := 0
$WEAVE_TBL[1].WV_CNTR_DWL := 0
$WEAVE_TBL[1].WV_RIGHT_DWL := 0
$WEAVE_TBL[1].WV_SMOOTH := TRUE
$WEAVE_TBL[1].WV_TRV_SPD := 0.035
$WEAVE_TBL[1].WV_PLANE := 0
$WEAVE_TBL[1].WV_AMP_PER := 100
$CRNT_DATA[2].WEAVE_NUM_NOMOT := 0
$CRNT_DATA[2].WEAVE_MODALITY_NOMOT := 0
$CRNT_DATA[2].WEAVE_TYPE_NOMOT := 0
c. speeds definition
$SPD_OPT := SPD_LIN
$LIN_SPD := 0.050000001
MOVE LINEAR TO p1
$CRNT_DATA[2].WEAVE_NUM_NOMOT := 1
DELAY 3000
$CRNT_DATA[2].WEAVE_NUM_NOMOT := 0
pr-0-0-gpr_09.fm
118 03/0111
Path Governor (optional)
11.1 Introduction
The Path Governor is a software option to obtain very accurate Cartesian, circular
and/or linear moves, reducing the path error.
It can be applied to any type of machine since it is based on the ACTUAL behaviour of
the robot. It can be executed for all the MOVE instructions, or if preferred only for some
of them.
The Path Governor is enabled ONLY in Local Automatic status (status selector
switch on AUTO).
Having enabled the Path Governor, the user has to set the following predefined
variables :
– $LIN_SPD - maximum speed value to execute the path
– 3 predefined variables that indicate the precision:
• $PGOV_ACCURACY - maximum Cartesian error (in mm) allowed during the
execution of the required Cartesian path (with a tolerance of approx. ±0.5mm)
• $PGOV_ORNT_PER - indicates the geometry error percentage to be taken
into consideration in the execution of the path. This value can be first set at
0%, then later, if the geometry error is still high, it can be increased
• $PGOV_MAX_SPD_REDUCTION - the accepted Cartesian speed reduction
percentage to obtain the required path precision (limits: 0..95).
These predefined variables can be set once for all at the beginning of the motion
hs-0-0-mot_05.fm
00/0210 119
Path Governor (optional)
program, or also from outside, or they can have different values for each Cartesian
MOVE.
The $PGOV_MAX_SPD_REDUCTION predefined variable is the variable that can have
enormous influence on whether or not the required precision is obtained. In fact, setting
a zero valve will not give any improvement in the path execution in relation to the same
move with the Path Governor disabled.
Furthermore, if the allowed speed reduction is not found adequate for the precision
required in $PGOV_ACCURACY, a Cartesian speed value will be seen that is referred
to a value equal to:
and, as a consequence, the error in the path could be greater than that required.
It is to be noted that, with the Path Governor enabled, the target speed profile will not be
trapezoidal, except in cases of saturation, but will have a speed trend that very similar
to the example shown in Fig. 11.1, where the result obtained during a Cartesian MOVE
is compared with the Path Governor Enabled and Disabled.
As can be seen in Fig. 11.1, with the Path Governor, the maximum speed value set is
not necessarily reached, but there is a speed modulation during the motion according to
the Cartesian error that is taking place.
hs-0-0-mot_05.fm
120 00/0210
Path Governor (optional)
hs-0-0-mot_05.fm
00/0210 121
SmartMove (optional)
This function has to be used when robot MINIMUM CYCLE TIME is the priority.
If instead the priority is to obtain robot MAXIMUM ACCURACY, it is necessary to
use the Path Governor (optional)
– Description
– Jerk Limitation
– Cartesian Motions
12.1 Description
It is an algorithm that can be enabled as a software option to optimise the execution
time of joint AND/OR CARTESIAN motionS. When SmartMove functionality is active,
all joint motions are automatically executed using such an algorithm. As far as executing
Cartesian motions, please refer to par. 12.3 Cartesian Motions on page 123.
By means of the robot dynamic model on all 6 axes, through which the inertia, frictions,
centrifugal and coriolis torques can be determined according to the robot posture and
the load conveyed, the robot motion is planned in the joints space fully exploiting the
torque and speed characteristics made available by the actuators that handle the joints,
so as to have at least one axis with maximum torque.
To optimise the results of the algorithm and avoid excessive torque requirements on
axes in motion, it is fundamental to declare the load data correctly, possibly using the
Payload identification (optional function) procedure.
The tolerance between the current predicted by the dynamic model and the actual
current of each individual axis can be configured through the system variables
$ARM_DATA[num_arm].SM4_SAT_SCALE[num_axis].
Fig. 12.1 shows a comparison between two speed profiles, without and with the
SmartMove algorithm.
hs-0-0-mot_06.fm
122 00/0210
SmartMove (optional)
Spd - Speed
Tr - Time reduction
$SPD_OPT := SPD_SM4C
SmartMove algorithm will automatically calculate the maximum TCP acceleration and
speed values, depending on the specified payload, on the operating zone and on the
axes configuration.
hs-0-0-mot_06.fm
00/0210 123
Flow Modulate Algorithm
This service, used in applications such as Cosmetic Sealing and Glueing, modulates
the flow of the material to be delivered during the part machining, according to the speed
of the TCP (Tool Center Point).
The delivery device, according to the voltage set, delivers a certain material .
The material dispensing machine defines the maximum voltage value it can handle.
The voltage to be delivered is passed from the C5G each time by a predefined either
$FMO or $AOUT variable. Maximum allowed value is 65535.
If, for example, the maximum voltage value that can be delivered is 10 Volt and the
either $FMO or $AOUT predefined variable is set at 65535 (maximum $FMO / $AOUT
value), this means that the machine will apply the maximum voltage (10 Volt ) for the
material delivery.
Certain parameters have to be set to define the modulation functioning.
These parameters are kept in the predefined variable $FLOW_TBL (2 elements array);
the values are set by the motion parameters, with the following fields:
– $FW_ARM (integer): arm to which this algorithm is applied.
– $FW_AXIS (integer): axis to which this algorithm is applied ; only to be specified
when $FW_VAR is set at 2.
– $FW_CNVRSN (real): conversion factor to be applied to calculate the flow to be
delivered.
– This conversion value can be modified during the algorithm operation.
– $FW_VAR (integer): INTEGER. Type of variable to be operated on. If set at 1 the
flow modulation algorithm is applied to $ARM_VEL /cosmetic sealing); if set at 2
the flow modulation algorithm is applied to $RAD_VEL (glueing).
– $FW_SPD_LIM (2 real array ): indicates the minimum and maximum speed limits
over which the flow modulation algorithm will apply the nearest limit.
– $FW_FLOW_LIM (2 integer array ): indicates the minimum and maximum flow
limits over which the modulation algorithm will apply the nearest limit .
– $FW_ENBL (boolean): algorithm state indicator - enabled or disabled.
– $FW_START (boolean): indicates the time interval (in milliseconds) between the
speed sample acquisition (immediately following the call to FLOW_MOD_ON) and
the data writing on the analog port indicated in the call to FLOW_MOD_ON.
The formula that determines the conversion factor calculation is based on the maximum
speed that is intended to be used for the robot and the maximum applicable voltage in
bits. These values are defined during the initial configuration when setting the
$FLOW_TBL fields.
pr-0-0-gpr_12.fm
124 02/0610
Flow Modulate Algorithm
Example:
The voltage value is read by the machine that delivers the material on an integer port,
usually either a $FMO or $AOUT port, defined during the algorithm enabling; to enable
the algorithm, the FLOW_MOD_ON built-in routine is used , with the call:
FLOW_MOD_ON (<analog_port>, <flow_table_index>)
where:
– <port> is to be INTEGER type. For example: either $FMO or $AOUT .
– <flow_table_index> where the type of INTEGER is the $FLOW_TBL index .
Possible values: 1 or 2.
Obviously there is also a built-in routine for disabling, its call is:
– FLOW_MOD_OFF (<flow_table_index>)
– <flow_table_index> INTEGER. The $FLOW_TBL index. Possible values: 1 or 2.
The program that calls the FLOW_MOD_ON on a certain index must be the same as
that which calls FLOW_MOD_OFF on that index.
When the program is deactivated the table is automatically released (implicit
FLOW_MOD_OFF ).
1. Delivery flow
2. Conversion factor
y Voltage (V) to be delivered by the dispensing machine (written in the analog port passed to
FLOW_MOD_ON)
x TCP speed ($ARM_VEL or $RAD_VEL)
pr-0-0-gpr_12.fm
02/0610 125
Presuppositions for SMART Robot programming
14.1 Introduction
Current chapter summarizes further information related to the use of COMAU robots.
They are classified as being with spherical wrist or with non-spherical wrist.
COMAU robots which are involved in current chapter are shown in the following
Tab. 14.1 - Involved Robot models:
pr-0-0-gpr_05.fm
126 03/0111
Presuppositions for SMART Robot programming
14.2 Glossary
TCP - Tool Center Point. It is the point at the end of the tool and it is geometrically
described by the $TOOL system variable or by the Tool tables in DATA environment. It
can be local or remote. For SMART NJ4(L) robot the TCP position, with reference to the
robot axes, causes some limitations to the robot working area.
WCP - Wrist Center Point. For spherical wrist robots, WCP is the intersection point
between joint 5 and joint 6; for SMART NJ4 robots (non-spherical wrist) there isn’t a true
WCP: such a word means the intersection point between joint 4 and joint 5.
1. Wrist offset
RRS - Robot Realistic Simulation. It is a protocol that defines some rules to implement
a software sequence that allows a robotics CAD simulator (i.e. Robcad) to move the
robot using the same algorithms than the original Controllers. Such a software sequence
is called RCS module. It is provided by Comau and integrated into the simulators.
Nominal position - This term refers to machines with the Kinematics compensation
algorithm. The nominal position is the destination where the robot must move its TCP.
It usually comes from a CAD simulation where the model of the robot is theoretical,
without mechanical strains due to payload, calibration errors, etc.
Internal representation of the robot position - This term refers to machines with the
Kinematics compensation algorithm. The internal representation of the robot position is
the one coming out from the encoders/resolvers. It is also the position where the robot
is really moved to compensate the differences between the real machine and the
theoretical robot model.
Cartesian position or POSITION - It is a variable that describes the target position for
a MOVE statement by referring to a Cartesian frame of reference. In C5G each
POSITION has three components for the location (X, Y, Z), three angles for the
orientation and a configuration string.
Joint position or JOINTPOS - It is a variable that describes the target position for a
MOVE statement by reporting the value of each robot axis.
pr-0-0-gpr_05.fm
03/0111 127
Presuppositions for SMART Robot programming
pr-0-0-gpr_05.fm
128 03/0111
Presuppositions for SMART Robot programming
enable this modality only with moves that have to go through the singularity because
the default evolution modality, RS_WORLD, generally achieves the best behavior from
the application point of view. The RS_WORLD modality allows either maintaining
constant orientation, if necessary, or changing it by keeping the tool on a plane.
Nevertheless the RS_WORLD evolution doesn't allow the robot always to move through
the singularity zone. In this cases the WRIST_JNT modality performs the best behavior.
The effect is that the speed is maintained at a high value while the orientation of the tool
slightly looses the plane.
The evolution can also be very big if the starting and ending point are very far from the
singularity zone. This can happen because the WRIST_JNT evolution implements an
algorithm that maintains the TCP exactly on the Cartesian path while the wrist axes are
moved from the initial to the final position in joint evolution.
The effect of WRIST_JNT modality is generally good from the application point of view.
In some particular cases it would be necessary to follow additional programming rules
explained later in this document (see par. 14.7 Programming rules for non-spherical
wrist robots (SMART NJ4) on page 139).
The only limitation referring to the WRIST_JNT is that it is not allowed to continuously
move (MOVEFLY TO ...) between two movements with different evolution type. So if a
move has the standard RS_WORLD evolution and the next is WRIST_JNT, either the
fly must be removed or the evolution type of the first one must be set to WRIST_JNT too.
The curved lines are the flange trajectories, while the TCP moves along the right path
2 - Exact singularity position 3 - Behaviour of the WRIST_JOINT modality.
Getting closer to the singularity, speed is maintained high while orientation slightly changes
pr-0-0-gpr_05.fm
03/0111 129
Presuppositions for SMART Robot programming
The following picture shows an example of the maximum angular error that is applied
to the orientation while entering different circular zones around the singularity point.
These data has been computed with a tool exactly aligned with axis 6. Many vertical
trajectories have been executed around the calibration position of the SMART NJ4
model, properly programming the points and moving in WRIST_JNT evolution method
through the singularity zone.
pr-0-0-gpr_05.fm
130 03/0111
Presuppositions for SMART Robot programming
pr-0-0-gpr_05.fm
03/0111 131
Presuppositions for SMART Robot programming
1a - 1b: difference between the two flange positions, due to the orientation approximation
2a - 2b: orientation approximation
pr-0-0-gpr_05.fm
132 03/0111
Presuppositions for SMART Robot programming
move or vice-versa.
[ -6; +6 ]
Forbidden ranges [ -174; -186 ]
[ +174; +186 ]
[ -7; +7 ]
Safe ranges [ -173; -187 ]
[ +173; +187 ]
pr-0-0-gpr_05.fm
03/0111 133
Presuppositions for SMART Robot programming
Error messages
– 36996 (0x9084) "Wrist axis at undefined position" before starting the move.
– 62479 (0xf40f) "Wrist axis at undefined position" while moving into the forbidden
zone.
– 40014 (0x9c4e) "Wrist axis at undefined position" while teaching/modifying a point.
– RCS MODULE - Status returned: -59 "The specified position is singular".
These areas can be reached in a joint way; the limitations only refer to Cartesian
movements
pr-0-0-gpr_05.fm
134 03/0111
Presuppositions for SMART Robot programming
Error messages
– 36994 (0x9082) "Pos out of range" before starting the move.
– 62477 (0xf40d) "Cartesian position out of range" while moving into the forbidden
zone.
– 40012 (0x9c4c) "Pos out of range" while teaching/modifying a point.
– RCS MODULE - Status returned: -52 "Cartesian position is out of work
range".
pr-0-0-gpr_05.fm
03/0111 135
Presuppositions for SMART Robot programming
pr-0-0-gpr_05.fm
136 03/0111
Presuppositions for SMART Robot programming
Error messages
– 36995 (0x9083) "Axis 1 at undefined position" before starting the move.
– 62478 (0xf40e) "Axis 1 at undefined position" while moving into the forbidden zone.
– 40013 (0x9c4d) "Axis 1 at undefined position" while teaching/modifying a point.
– RCS MODULE - Status returned: -52 "Cartesian position is out of work
range".
1. TCP inside the forbidden zone 2. remote TCP inside the forbidden zone
pr-0-0-gpr_05.fm
03/0111 137
Presuppositions for SMART Robot programming
Error messages
– 36994 (0x9082) "Pos out of range" before starting the move.
– 62477 (0xf40d) "Cartesian position out of range" while moving into the forbidden
zone.
– 40012 (0x9c4c) "Pos out of range" while teaching/modifying a point.
– RCS MODULE - Status returned: -52 "Cartesian position is out of work
range".
Error messages
– 36995 (0x9083) "Axis 1 at undefined position" before starting the move.
– 62478 (0xf40e) "Axis 1 at undefined position" while moving into the forbidden zone.
– 40013 (0x9c4d) "Axis 1 at undefined position" while teaching/modifying a point.
– RCS MODULE - Status returned: -52 "Cartesian position is out of work
range".
pr-0-0-gpr_05.fm
138 03/0111
Presuppositions for SMART Robot programming
par. 14.6.1 Inverse conversion of SMART NJ4 (non-spherical wrist) model on page 131
don’t exist for spherical wrist robots. There is only some limitation about the singularity
of axis 5 and when the TCP is close to axis 1 for spherical wrist shelf mounted machines.
Detailed information are given about Axis 5 singularity.
SMART NJ4 robot has been designed for integration of cabling and ease of
off-line programming. For this reason it has a fixed wrist configuration to give the
needed space and distances to include pre-twisted cables and hoses through the
wrist. Following this concept, such a robot model is completely without any
external cable on the forearm, avoiding the unknown behavior of the cables with
conventional robots while moving close to the wrist singularity.
The disadvantage is that SMART NJ4 robot has a larger singularity zone around axis 5
with respect to spherical wrist robots (see par. 14.6.1.4 Axis 5 singularity on page 133).
The following programming rules explain how it is possible to perform application
processes staying away from the singularity zone or moving through it with the
WRIST_JNT feature of the C5G Robot Controller.
pr-0-0-gpr_05.fm
03/0111 139
Presuppositions for SMART Robot programming
In these cases it is always possible to modify the points (typically POSITIONS) only
adding a small rotation around the approach direction. With the real robot this can be
done by jogging in the TOL modality (jogging with reference to the tool frame) and
pressing jog button +6/-6 (rotation around Z axis that is typically the approach vector); if
the position comes from a CAD system or it is directly written in the program, just modify
the third Eulerian angle e3 (POS(x, y, z, e1, e2, e3, ’’)). On the real robot, a small
rotation of 5° up to 10° allows the wrist to go away from the singularity zone.
The rotation takes more effect if the tool approach vector is not parallel to axis 6
of the robot. If they are parallel, something can still be done, provided that the TCP
is not aligned along axis 6.
The following picture shows three different cases with a spot welding gun.
Fig. 14.2 - BEST situation (90° between axis 6 and gun approach
vector)
pr-0-0-gpr_05.fm
140 03/0111
Presuppositions for SMART Robot programming
Note that rotating around the approach vector is not the only way to stay away from the
singularity zone. Any rotation works and never changes the TCP position in x, y, z.
When the application does not strictly force the orientation of the tool, a small change
could considerably improve the wrist position and the robot performances.
pr-0-0-gpr_05.fm
03/0111 141
Presuppositions for SMART Robot programming
– the pallet is placed at the same level of the robot calibration position;
– the pallet is placed exactly in front of the robot.
To eliminate any singularity problems, the programmer has to remove al least one of the
listed above conditions. For example, putting the pallet in a lower position or mounting
the robot in a higher place the robot will be able to reach all the positions on the rack
without any problems (see next picture).
pr-0-0-gpr_05.fm
142 03/0111
Presuppositions for SMART Robot programming
Similarly it is possible to solve any singularity problem by laterally moving the rack. In
this case it is not necessary to change the height.
In any case the best solution can be found by means of an off-line simulation. In this way
it is possible to calculate the minimum displacement of the rack, either sideways, or up,
or down .
It is important to remember that SMART NJ4 models gives big advantages during
simulation because there aren’t any external cable on the forearm. This allows solving
any reachability problem during the work-cell design phase. At this time it will be
possible to choose the best location for the elements, the best gripper shape and robot
paths.
pr-0-0-gpr_05.fm
03/0111 143
Presuppositions for SMART Robot programming
14.7.1.3 Modifying tool inserting a small angle between robot flange and tool
flange
The gripper design is very important to improve the robot capabilities. This is true for all
the robot models. In addition to this, for SMART NJ4 robots the gripper shape can solve
any problem with singularity.
A small angle between the robot flange and the gripper is recommended in order to
considerably improve the reachability of singular positions.
pr-0-0-gpr_05.fm
144 03/0111
Presuppositions for SMART Robot programming
As shown in the above pictures, such a solution allows the robot to follow a linear
trajectory exactly in front of it from up to down. It also allows to reach all the available
working area always maintaining the frontal position and the same orientation.
The same applies to spot-welding guns. If the work-cell layout is already defined, a small
angle can considerably improve the behavior of the robot. This method can also solve
the worst situations where the approach vector of the gun is exactly aligned with axis 6
(see par. 14.7.1.1 Changing the orientation of the points along the path on page 140).
Of course, the use of an off-line simulation simplifies the chose of the angle and allows
an optimization of all the details of the application.
pr-0-0-gpr_05.fm
03/0111 145
Presuppositions for SMART Robot programming
14.7.2 Conclusions
Many methods and hints have been given to increase the capabilities of SMART NJ4
robots inside the singularity zone. It has been demonstrated that in the most cases it is
pr-0-0-gpr_05.fm
146 03/0111
Presuppositions for SMART Robot programming
possible to stay out of this zone, getting the best performances from the robot anyway.
When it is absolutely necessary to go through the singularity, WRIST_JNT modality
allows the robot to move at a very high speed with an angular error that can be accepted
in the most processes. In any case the simulation tools can be effectively used to obtain
the best results from the system.
pr-0-0-gpr_05.fm
03/0111 147
Collision Detection (optional feature)
15.1 Introduction
The Collision Detection algorithm (optional feature) allows the system to stop the robot
arm motion, as soon as any noise force on joints takes effect.
Such a capability can be enabled and disabled by the user, by means of a predefined
variable, using either a Program statement or a system Command
The Collision Detection functionality has NOT been designed in order to protect
the personnel, but to limit any damage to the robot mechanical parts and
therefore to its equipments!
Compliance
The axes compliance has been used in order to be able to absorb part of the collision
energy (or part of the over-traction in case of stuck tips) and to minimize any possible
damage, this compliance can be activated by the user. Carefully assess its use in the
application.
pr-0-0-gpr_06.fm
148 03/0111
Collision Detection (optional feature)
The robot DOES NOT STOP, but continues the programmed motion: it is the
responsibility of the user to appropriately deal with the event that has occurred,
cancelling the current motion, that would continue towards the obstruction, and
programming the new trajectory.
In the par. 15.7.4 Managing "collision detected" event on page 160, there is an
example program.
BIT_SET($ARM_DATA[num_arm].A_ALONG_1D[12], 10)
The bit modification is allowed both at run-time and by means of the configuration file,
and it is possible to save it into the configuration file .C5G.
Compliance
After a collision alarm, the robot stop may be made compliant. The compliance
occurence after collision is statedby setting to 1 bit number 11 of
$ARM_DATA[num_arm].A_ALONG_1D[12] predefined variable, and it is up to the user
to enable it by inserting in his program the following statement:
BIT_SET($ARM_DATA[num_arm].A_ALONG_1D[12], 11).
Such a flag can be disabled by means of the following statement:
BIT_CLEAR($ARM_DATA[num_arm].A_ALONG_1D[12], 11).
pr-0-0-gpr_06.fm
03/0111 149
Collision Detection (optional feature)
To avoid that this bit is unintentionally saved in .C5G and enables the compliance
service linked to the Collision Detection unexpectedly after a restart, the bit itself will be
automatically reset by the system during the start-up.
15.4.1 $COLL_TYPE
In order to define the Collision Detection sensitivity type, it is available $COLL_TYPE
predefined variable. The allowed values for such a predefined variable are as follows:
– COLL_LOW
– COLL_MEDIUM
– COLL_HIGH
– COLL_MANUAL
initialized by COMAU, and
– COLL_USER1
– COLL_USER2
– ...
– ...
– COLL_USER10
that can be handled by the user to customise COMAU data.
During a Program execution, while some particular arm movements are performed, it is
possible that an occurring collision should be detected using more or less sensitivity.
The collision sensitivity can be modified both for a MOVE sequence and for just one
MOVE statement.
Modal assignment (for the whole MOVE sequence):
$CRNT_DATA[num_arm].COLL_ENBL := TRUE
$COLL_TYPE:= COLL_MEDIUM
MOVE TO PNT0001J
MOVE TO PNT0002J
In the shown above example, the collision sensitivity takes effect for both the MOVE
statements.
Nodal assignment (for just one MOVE statement):
$CRNT_DATA[num_arm].COLL_ENBL := TRUE
$COLL_TYPE := COLL_LOW
MOVE TO PNT0001J
MOVE TO PNT0002J WITH $COLL_TYPE := COLL_HIGH
In the shown above example, the first MOVE statement is executed using a LOW
collision sensitivity, while the second one is performed using a HIGH collision sensitivity.
pr-0-0-gpr_06.fm
150 03/0111
Collision Detection (optional feature)
A set of values corresponds to each value of $COLL_TYPE for the axes sensitivity,
$ARM_SENSITIVITY and a set of values (if any) for the compliance of
$COLL_SOFT_PER (just in the case in which the compliance modality after collision
has been enabled). Basic values (HIGH, MEDIUM, LOW, MANUAL) are set by COMAU.
COLL_USER1 and COLL_USER2 values can be used under the care and the
responsibility of the user.
pr-0-0-gpr_06.fm
03/0111 151
Collision Detection (optional feature)
6% on the wrist axes (value determined experimentally). The privileged user can
change this margin.
For example,
ARM_COLL_THRS(1, COLL_USER2, 60, FALSE)
Acquires the data starting from the instant the built-in is executed and for the next 60
seconds: the end being indicated with the message
It is to be noted that the recalculation requires the same time as for the
acquisition, before the new thresholds can be actuated. During this time, the
active thresholds (i.e. the current ones) could cause false collisions or poor
sensitivity.
Opportune measures, such as to use the standard safety thresholds during the
transition stage (from the start of the built-in execution to the receiving of the
message) should allow the acquisition phase to be overcome .
15.5 Reliability
In order to make the Collision Detection algorithm to operate in a safe and reliable way,
it is ABSOLUTELY REQUIRED that the user properly identifies the payload.
The Collision Detection performance strictly depends on a proper declaration of the
currently used payload: if the estimated payload is wrong, the Collision Detection could
be misevaluated (i.e. false collision during a Program execution); furthermore, while in
the compliance phase, with consequent deceleration and stop, the robot arm could have
unpredictable behaviours due to either an underestimated or an overestimated payload.
For these reasons, before activating the Collision Detection function, the user is
to check that the load used has been defined precisely.
pr-0-0-gpr_06.fm
152 03/0111
Collision Detection (optional feature)
15.6.1 Introduction
The following remarks are provided to help the user in setting up the Collision Detection
functionality.
The essential condition for the Collision Detection functionality to work properly is that
the dynamic model of the currents does exist for the related arm/robot. Only if the robot
is provided with such a dynamic model, it is possible to activate the functionality (if the
optional feature is present/purchased).
The dynamic model is able to calculate in advance the currents that will be used to move
the robot in a specific motion, using robot position, payload and inertia data. Today all
robots (except auxiliary axes) are provided with dynamic model.
In order to obtain the best performances from the dynamic model, it is NECESSARY to
have properly configured the following payload variables:
– $TOOL_MASS
– $TOOL_CNTR
– $TOOL_INERTIA
It is the operator’s care either to insert the nominal data or to use (if present/purchased)
the Payload Identification Program (optional feature), to modify the above listed values
while the application program is running, so the current payload values are always
defined for the Controller.
The Collision Detection functionality operates using the currents calculated in advance
by the dynamic model and the actual currents of each axis motor during the movement.
Such a functionality warns the user that a collision occurred. The Collision Detection
functionality works using the currents which are calculated in advance by the dynamic
model and the currents actually used in each motor (axes) movements. The functionality
warns the user about the occurring collision on one or more axes, if the difference
between the two above mentionned currents is significantly big.
VERY IMPORTANT! Remeber that the Collision Detection functionality has been
designed to limit any damage to the robot and therefore to its equipment, in case
of collision. So, since it is a functionality that immediately acts to limit the
collision effect, it is expectable it also limits damages to the equipment of the cell
where the robot works in. But it is important to understand that the Collision
Detection functionality has not been designed to protect the operator in case of
bad/wrong use of the robot.
When a collision error occurs, the robot is immediately put in DRIVE OFF state and the
following error message is issued:
62513 – 10 SAX COLLISION DETECTED
in order to reset the alarm state, the alarms latch command is to be used:
– ULLA command, or
– Alarm Page, Latched sub-page, Ack softkey, in case of use of Teach Pendant (for
further information see C5G Control Unit Use, chapter Use of the Teach
Pendant).
pr-0-0-gpr_06.fm
03/0111 153
Collision Detection (optional feature)
Identifying the thresholds with the robot COLD limits, to a certain extent, the
sensitivity of the algorithm. The rules for use that are given below can help
understand these aspects and advise the user how to also make the function very
sensitive.
Note that the thresholds definition does NOT take place inside this program, but
in the work program !
$CRNT_DATA[num_arm].COLL_ENABLE:=TRUE
To deactivate it:
$CRNT_DATA[numero_arm].COLL_ENABLE:=FALSE
pr-0-0-gpr_06.fm
154 03/0111
Collision Detection (optional feature)
d. Definition of Nodal/ModalSensitivity
The system is provided with some predefined thresholds, for a general payload,
like the robot payload:
– COLL_LOW
– COLL_MEDIUM
– COLL_HIGH
While in programming state, the system automatically uses a 4th threshold:
– COLL_MANUAL
Two more thresholds exists which can be configured by the user:
– COLL_USER1
– COLL_USER2
– ...
– COLL_USER10
The sensitivity type can be defined in the program by means of two different
strategies:
• modal definition
...
$COLL_TYPE := COLL_xxxx
MOVE ...
...
this means that the chosen sensitivity threshold (COLL_xxxx) will be used
• nodal definition for all MOVE statements
MOVE ... WITH $COLL_TYPE:= COLL_xxxx (A)(see step b.)
...
MOVE ... WITH $COLL_TYPE:= COLL_yyyy (B)(see step b.)
this means that the chosen sensitivity threshold, (COLL_xxxx), will be used
for (A) type MOVEs; the other one, (COLL_yyyy), will be used for (B) type
MOVEs instead.
e. False collisions
If the user has chosen the thresholds (COLL_LOW, COLL_MEDIUM,
COLL_HIGH, COLL_MANUAL, COLL_USER) without analyzing the type of
collision he would like to prevent, and some wrong thresholds have been set for the
movements included in the program, some False Collisions will occur; this means
, during the robot motion, the system will detect a collision which never happened.
The reason is that a threshold too sensitive for the movement has been used (for
example: too high sensitivity in a movement with high accelerations/decelerations).
(100% - 90%) * 60 A = 6 A
g. Use strategy
First of all the user must understand what he really does need:
– REQUIREMENT No.1: immediate use of the Collision Detection
functionality
The modal strategy is the one that allows the user to activate the Collision
Detection functionality and to set, for example, just one threshold for all
motion types (i.e. the user tries using COLL_MEDIUM, then, if any false
collisions occured, switching to COLL_LOW). Obviously, the disadvantage of
such a strategy is that the Collision Detection sensitivity has not been tuned
pr-0-0-gpr_06.fm
03/0111 155
Collision Detection (optional feature)
by the user to have high performances. The advantage is that setting the
sensitivity is very fast.
Once the user program has run with Cold Robot (which means not working
for hours), if no false collisions are detected, the chosen threshold is good to
assure the Collision Detection activation without any false collisions.
Otherwise, it is needed to use a COLL_USERx threshold: they have the same
starting values as COLL_LOW, reduced by 3% for each axis.
– REQUIREMENT No. 2: customized use
The nodal strategy has been designed for advanced users who need to reach
a high level protection against collisions, stuck tips, pick/drop movements,
etc.
In such a situation, the user, after having logically grouped the program
movements, as suggested in step b., has to perform some more tests in order
to identify, for each movement, which is the threshold that guarantees the
highest level of protection.
Here follows some operating rules for any single motion.
• Consider a single movement and identify its motion type:
• Movement with high accelerations/decelerations (many centimeters) -->
(A) type movement (see step b.)
• Movement at maximum speed
• Short movement (few centimeters) --> (B) type movement (see step b.)
• Movement at reduced speed
• For (A) type movements, it is recommended to start with a COLL_MEDIUM
threshold \ for (B) type movements, start with COLL_HIGH
• Execute some motion cycles with Cold robot at 100% (max speed of program
execution). If no false collisions occur, the chosen threshold is the right one.
• Otherwise, if some false collisions occur, set the threshold to COLL_LOW (for
(A) type movements) or COLL_MEDIUM (for (B) type movements).
• If some false collisions still occur, initialize COLL_USER1 threshold to
COLL_LOW values:
$ARM_SENSITIVITY[COLL_USER1,ax:= $ARM_SENSITIVITY[COLL_LOW,ax]
• Decrease by 3% the value for each axis on which the false collision occured
($ARM_SENSITIVITY[COLL_USER1,ax]) and try again until no false
collisions are detected.
• In the thresholds definition, it is recommended to try to keep uniformity in the
values of the main axes 1-2-3 and the wrist axes 4-5-6
• The thresholds resulting from the described above tests, are to be used for
any movement which is similar to the analyzed one.
• As an alternative the ARM_COLL_THRS(Arm, Coll_type, Time, Margin)
built-in can be used to identify the collision thresholds runtime.
h. Programming tips
If the user would like to operate with the Nodal strategy, in order to obtain the
maximum results from the Collision Detection functionality, it is needed to follow
the listed below suggestions:
– avoid technological positions (i.e. Spot Welding positions) by means of an (A)
type movent, which means with big accelerations/decelerations. Insert a
small ‘approach’ movement.
– deactivate the Collision Detection functionality during the technological
operation (i.e. closing the gun). This is to avoid that umpredictable
movements of the equipments could generate torques on robot axes that
could be seen as a collision.
pr-0-0-gpr_06.fm
156 03/0111
Collision Detection (optional feature)
PROGRAM collision
VAR pnt0001j, pnt0002j, pnt0003j, pnt0004j : JOINTPOS FOR ARM[1]
BEGIN
CONDITION[1] :
WHEN AT START DO
$COLL_TYPE := COLL_HIGH
$CRNT_DATA[1].COLL_ENBL := TRUE
ENDCONDITION
CONDITION[2] :
WHEN AT END DO
$CRNT_DATA[1].COLL_ENBL := FALSE
ENDCONDITION
MOVE TO $CAL_SYS
CYCLE
MOVE TO pnt0001j
MOVE TO pnt0002j
pr-0-0-gpr_06.fm
03/0111 157
Collision Detection (optional feature)
PROGRAM collision2
VAR pnt0001j, pnt0002j, pnt0003j, pnt0004j : JOINTPOS FOR ARM[1]
BEGIN
CONDITION[1] NODISABLE :
WHEN EVENT 99 DO
$CRNT_DATA[1].COLL_ENBL := TRUE
ENDCONDITION
ENABLE CONDITION[1]
MOVE TO $CAL_SYS
$COLL_TYPE := COLL_LOW
$CRNT_DATA[1].COLL_ENBL := TRUE
CYCLE
MOVE TO pnt0001j
MOVE TO pnt0002j
pr-0-0-gpr_06.fm
158 03/0111
Collision Detection (optional feature)
--
-- Recalculates the collision sensitivity thresholds every delta_t minutes
--and at each GEN_OVR variation.
--
PROGRAM thresholds NOHOLD
VAR dummy : BOOLEAN
coll : INTEGER
delta_t : INTEGER
ROUTINE ru_thrs
BEGIN
-- Calculates the collision thresholds for ARM 1, 'coll' sensitivity type and
-- acquires data for 120 seconds.
ARM_COLL_THRS(1, coll, 120)
END ru_thrs
BEGIN
-- Variable to keep the program active
dummy := FALSE
-- Type of sensitivity for which the thresholds recalculation is asked
coll := COLL_USER3
--
-- Defines a delta time to recalculate the thresholds
--
delta_t := 60000 * 10 -- each 10 mins
CONDITION[1] NODISABLE :
--
-- Recalculates the thresholds if GEN_OVR changes
--
WHEN EVENT 85 DO
$TIMER[1] := 0
ru_thrs
ENDCONDITION
CONDITION[2]:
--
-- Recalculates the thresholds at the timeout.
--
WHEN $TIMER[1] > delta_t DO
$TIMER[1] := 0
ENABLE CONDITION[2]
ru_thrs
ENDCONDITION
ENABLE CONDITION[1]
ENABLE CONDITION[2]
pr-0-0-gpr_06.fm
03/0111 159
Collision Detection (optional feature)
PROGRAM colltouch
VAR pnt0006p, pnt0007p, pnt0008p: POSITION
pnt0001p, pnt0002p, pnt0003p, pnt0004p, pnt0005p: POSITION
BEGIN
CONDITION[1]:
WHEN EVENT 94 DO
UNLOCK -- reset for
RESUME -- next restart
.
.
.
ENDCONDITION
CONDITION[2]NODISABLE:
WHEN EVENT 197 DO
LOCK -- locks the machine
CANCEL CURRENT -- cancels the current motion
.
.
.
ENDCONDITION
.
.
.
ENABLE CONDITION[1]
ENABLE CONDITION[2]
$COLL_TYPE:=COLL_USER1
$COLL_EFFECT:=2
$CRNT_DATA[1].COLL_ENBL:=TRUE
CYCLE
MOVE TO ...
.
.
.
END colltouch
pr-0-0-gpr_06.fm
160 03/0111
Collision Detection (optional feature)
In the program, the whole movement can be split into several sections, for a maximum
of 100 sections. By means of such routines it is possible to acquire the Collision
thresholds for each section, in an automatic way.
Identifying homogeneous motion sections (between CD_START and CD_END) makes
the calculated thresholds much more fine for their usage.
The Collision Detection functionality is activated by starting with cold thresholds and, at
each cycle, thresholds are calculated depending on the actual movement.
A third routine is also available:
– CD_READ - displays (on LUN_TP and LUN_CRT)
• the Collision current status (enabled/disabled),
• current collision type ($COLL_TYPE)
• the sensitivity thresholds for every single axis.
An example follows of the described above routines application.
PROGRAM mov
-- EXPORTED ROUTINES
ROUTINE CD_Start(ai_Coll : INTEGER) EXPORTED FROM CDetect
ROUTINE CD_End EXPORTED FROM CDetect
ROUTINE CD_Read EXPORTED FROM CDetect
BEGIN
MOVE TO $CAL_SYS
CYCLE
CD_START(1)
MOVE TO pnt0001j
MOVE TO pnt0002j
CD_END
CD_START(2)
MOVE LINEAR TO pnt0003j
MOVE TO pnt0004j
CD_END
END mov
pr-0-0-gpr_06.fm
03/0111 161
Use of Positioners managed by C5G
16.1 Introduction
This chapter is addressed to the installers and maintenance engineers of the automated
cell, to supply them with the use procedures and the information needed for the
Controller software configuration so to obtain the correct management of the positioner
equipped with robot external axes.
In particular the need is underlined to carry out the positioner configuration customising
when this is not a standard product.
In any case, even with a standard positioner, the radius of the part overall
dimensions always has to be defined.
The positioners are divided into families, and a paragraph is dedicated to each of them.
The procedures and conventions contained in the following paragraphs are very
important to ensure the consistency of the installation and above all the correct
functioning of the system when, for example, the cooperative motion is used, i.e. the
enslavement of a robot in the position of the part to be processed mounted on the
positioner.
It is the responsibility of the positioner designer to check and guarantee that the
unit operates in conformity with the relevant standards. In particular it must be
verified that in the following situations:
– normal use (Automatic/Programming),
– emergency stop,
– safety braking,
– Hold,
– Drive off,
– impact on any mechanical pads
the unit behaves in a manner that complies with current safety standards.
16.2 Summary
The following subjects:
– USE of the Teach Pendant (use of the external axes configuration software)
and
– USE of the TO_SET program (calculation of positioner base position),
are dealt with respectively:
– in the Use of the C5G Control Unit Use Manual, in the paragraph Setup Page,
and
– in this manual, Chap. TO_SET Program - Tool handling
hs-0-0-mot_04.fm
162 00/0210
Use of Positioners managed by C5G
For special conventions and specifications of each positioner, see the relevant
paragraph for that particular model or family.
The directions of the positioner axis rotations cannot be chosen at will: they have
to strictly follow the convention in which the axes have a positive anticlockwise
direction (in relation to the rotation axis)..
In other words they have to follow the right-hand rule referring to the direction indicated
in Fig. 16.1 in correspondence to the axes: pointing the thumb of the right hand in the
direction of the dashed line arrow (that represents each axis), the fingers are to close in
the positive direction of the rotating axis. For this description, the orbital positioner has
been chosen because it is particularly representative.
hs-0-0-mot_04.fm
00/0210 163
Use of Positioners managed by C5G
– The origin of the flange reference Oflange is to coincide with the mean point of
segment P1-P3;
– P2 is to be chosen so that the segment between Oflange and P2 is perpendicular to
P1-P3.
1 - axis 1 2 - axis 2
where:
250 = maximum speed allowed as per standard [mm/s]
955 = numeric conversion factor
Rt = motor transmission ratio [Mt/axt]
Vm = motor maximum speed [Rpm]
r = part overall dimension radius [mm]
hs-0-0-mot_04.fm
164 00/0210
Use of Positioners managed by C5G
Note the convention that concerns points P1, P2, P3 described in the Chap. TO_SET
Program - Tool handling for the $BASE (or $AUX_BASE) calculation of the positioners.
Note also how the axis has an anticlockwise direction of rotation to comply with the
right-hand rule convention (see Axis rotation directions).
If, operating with the Teach Pendant, the controlled axis moves in the opposite
direction to this rule, the transmission ratio sign must be changed using the
Teach Pendant
16.5.2 Calibration
The lathe positioner does not require special rules for the calibration position.
hs-0-0-mot_04.fm
00/0210 165
Use of Positioners managed by C5G
To configure these positioners, see the C5G Control Unit Use Manual, Setup Page,
paragraph AUX_AXES.
For these types of positioners no value has to be inserted regarding the length of the
axes.
On the other hand, when programming, it is necessary to calculate the speed to be
attributed to the positioner axis, according to the dimension of the part that is mounted
on the bearing plate, so that the maximum tangential speed does not exceed 250 mm/s
(see standards in force). Therefore it is necessary first of all to measure the maximum
radius r of the part to be machined, as indicated in Fig. 16.3.
Next, the configuration software, on the Teach Pendant, calculates the manual mode
speed value.
A table summarising the mechanical data to be entered is shown below, assuming that
the positioner is axis 7.
For very long lathes, it is possible to mount the robot on an SCP slide or CRP
column integrated axis; in this case the integrated axis will be axis 7, whereas the
lathe will become axis 8
hs-0-0-mot_04.fm
166 00/0210
Use of Positioners managed by C5G
16.6.1.2 Calibration
The calibration conventions are the following:
– the first axis is to calibrate so that the Zflange axis is aligned to Zbase.
– the second axis is to calibrate with all the flange reference axes parallel to the
corresponding axes of the base reference; in particular Yflange is to be parallel to
Ybase and have the same direction.
Also the convention should be borne in mind that concerns points P1, P2, P3 described
in the Chap. TO_SET Program - Tool handling to calculate $BASE (or $AUX_BASE) of
the positioners (see Fig. 16.4).
hs-0-0-mot_04.fm
00/0210 167
Use of Positioners managed by C5G
To configure these positioners, see the C5G Control Unit Use Manual, Setup Page,
paragraph AUX_AXES.
The parameters required for the correct kinematic description of the positioner (length
of axes) are indicated in Fig. 16.5. This shows a generic positioner indicating the
dimensions that distinguish it and the PDL2 variables that contain the parameters. Note
that the model requires that axes 1 and 2 intersect (there must be no offset).
It is also necessary to calculate the speed to be attributed to the two positioner axes
being programmed, according to the dimension of the part that is mounted on the
bearing plate, so that the maximum tangential speed does not exceed the set value of
250 mm/s. Therefore it is necessary to first measure the maximum radii r1 and r2 of the
part to be machined, as indicated in Fig. 16.5.
$AX_LEN[ax_logic1] = L1 $AX_OFST[ax_logic2] = L2
For example, for positioner formed by auxiliary axes 7 and 8: ax_logic1 = 7 e ax_logic2 = 8
hs-0-0-mot_04.fm
168 00/0210
Use of Positioners managed by C5G
If the part has overall dimensions that are less than the diameter of the bearing
plate, r2 is to be equal to the radius of the bearing plate. This is to always consider
the worst case of part maximum overall dimensions or of the mechanical
structure of the positioner in motion.
Next, the configuration software, on the Teach Pendant, calculates the manual mode
speed value.
Two tables follow, summarising the useful mechanical data, assuming that the
positioner is handled with auxiliary axes 7 and 8 respectively.
hs-0-0-mot_04.fm
00/0210 169
Use of Positioners managed by C5G
– the Zflange axis is perpendicular to the flange surface with outward direction.
16.6.2.1.1 Calibration
The conventions for the calibration are as follows:
– The first axis is to be calibrated so that the Zflange axis is aligned to Zbase;
– The second axis is to calibrate with all the flange reference axes parallel to the
corresponding base reference; in particular Yflange is to be parallel to Ybase and
have the same direction.
Also the convention is to be borne in mind that concerns points P1, P2, P3 described in
Chap. TO_SET Program - Tool handling to calculate the $BASE (or $AUX_BASE) of the
positioners (see Fig. 16.6).
1 - axis 1 2 - axis 2 Xb, Yb, Zb, Ob= Xbase , Ybase, Zbase, Obase
Xf, Yf, Zf, Of = Xflange, Yflange, Zflange, Oflange
To configure these positioners, see the C5G Control Unit Use Manual, Setup Page,
paragraph AUX_AXES.
The parameters required for the correct kinematic description of the positioner (length
of axes) are indicated in Fig. 16.7. They show a generic positioner with the dimensions
that distinguish it and the PDL2 variables that contain the parameters. As can be seen,
hs-0-0-mot_04.fm
170 00/0210
Use of Positioners managed by C5G
a length of the arm that carries axis 2 is not available, but only the two heights; this is
possible because the positioner base reference system is centred on rotation axis 2 (see
Fig. 16.7). ). Note also that the value for L2 is to be negative to indicate that the flange
(axis 2) is lowered in relation to axis 1.
It is also necessary to calculate the speed to be attributed to the two positioner axes
being programmed, according to the size of the part mounted on the bearing plate, so
that the maximum tangential speed does not exceed the set speed of 250 mm/s. To this
purpose it is necessary first of all to measure the maximum r1 and r2 radii of the part to
be machined, as indicated in Fig. 16.7.
For example, for a positioner formed by auxiliary axes 7 and 8: ax_logic1 = 7 e ax_logic2 = 8
If the part has overall dimensions that are less than the diameter of the bearing
plate, r2 is to be equal to the radius of the bearing plate; in the same way for r1 a
minimum value is to be used equal to r1m to take into consideration the
mechanical structure of axis 7. This is to always consider the worst case of part
maximum overall dimensions or of the mechanical structure of the positioner in
motion
Next, the configuration software, on the Teach Pendant, calculates the manual mode
speed value.
Two tables follow that summarise the useful mechanical data, assuming that the
positioner is handled with auxiliary axes 7 and 8 respectively.
hs-0-0-mot_04.fm
00/0210 171
Use of Positioners managed by C5G
1 - axis 1 2 - axis 2
Xb, Yb, Zb, Ob= Xbase, Ybase , Zbase, Obase Xf, Yf, Zf, Of = Xflange, Yflange, Zflange, O flange
hs-0-0-mot_04.fm
172 00/0210
Use of Positioners managed by C5G
16.7.2 Calibration
The conventions for the calibration are as follows:
– the first axis is to be calibrated so that the Zflange axis is parallel to Zbase;
– the second axis is to calibrate with all the flange reference axes parallel to the
corresponding ones of the base reference; in particular Yflange is to be parallel to
Ybase and have the same direction.
Also the convention is to be borne in mind that concerns points P1, P2, P3 described in
the Chap. TO_SET Program - Tool handling to calculate the $BASE (or $AUX_BASE)
of the positioners (see Fig. 16.8).
To configure these positioners, see the C5G Control Unit Use Manual, Setup Page,
paragraph AUX_AXES.
The parameters required for the correct kinematic description of the positioner (length
of axes and angles) are shown in the Fig. 16.9. It illustrates a generic positioner
indicating the dimensions that distinguish it and the PDL2 variables that contain the
parameters.
It is also necessary to calculate the speed to be attributed to the two positioner axes
being programmed, according to the dimension of the part that is mounted on the
bearing plate, so that the maximum tangential speed does not exceed 250 mm/s.
Therefore it is necessary first of all to measure the maximum radii r1 and r2 of the part
to be machined, as indicated in the following Fig. 16.9.
1 - part to be machined
$AX_LEN[ax_logic1] = L 1 $AX_LEN[ax_logic2] = L3
$AX_OFST[ax_logic1] = alpha, with alpha that is not 90° $AX_OFST[ax_logic2] = L2
For example, for a positioner formed by auxiliary axes 7 and 8: ax_logic1 = 7 e ax_logic2 = 8
hs-0-0-mot_04.fm
00/0210 173
Use of Positioners managed by C5G
If the part has overall dimensions that are less than the diameter of the bearing
plate, r2 is to be equal to the radius of the bearing plate r2m; in the same way for
r1 a minimum value is to be used equal to r1m to take into consideration the
mechanical structure of axis 7. This is to always consider the worst case of part
maximum overall dimensions or of the mechanical structure of the positioner in
motion..
Next, the configuration software, on the Teach Pendant, calculates the manual mode
speed value.
Two tables follow, summarising the useful mechanical data, assuming that the
positioner is handled with auxiliary axes 7 and 8 respectively.
Note that the absolute value of the alpha angle is to be inserted even if the
measurement unit of the axis offset is in millimetres.
hs-0-0-mot_04.fm
174 00/0210
Use of Positioners managed by C5G
– The Cartesian positions (POSITION) are defined in the cell space regardless of the
linear slide axis position and therefore moving only the slide will change the
Cartesian position;
– Manually moving the slide (jog) in a Cartesian reference (for example jog BASE),
the TCP position remains unchanged due to the displacement of the robot axes
that offset the displacement.
On the Teach Pendant the linear axis can be moved in Cartesian mode, using the
7+ and 7- keys and it is not possible to enable or disable the slide integration in
real time (a Controller restart is needed).
hs-0-0-mot_04.fm
00/0210 175
Use of Positioners managed by C5G
16.8.1.2 Calibration
The slide calibration position is fixed close to the negative limit of the stroke and marked
with a zero notch.
Since this is an integrated axis it is not treated as a positioner for the part to be machined
and therefore it is not necessary to pick up points P1, P2 and P3 described in the
Chap. TO_SET Program - Tool handling.
To configure these positioners, see the C5G Control Unit Use Manual, Setup Page,
paragraph AUX_AXES.
The parameters needed for the correct kinematic description of the integrated slide are
indicated in Fig. 16.11.
Next, the configuration software, on the Teach Pendant, calculates the manual mode
speed value.
A table follows summarising the useful mechanical data, bearing in mind that it is
mandatory that the integrated slide is handled with auxiliary axis 7.
Besides the L and H geometrical data indicated above, for the complete kinematic
description of the integrated slide also the assembly angle is to be defined:
– 180° rotation ==> Xrobot_base in opposite direction to Xslide_base;
hs-0-0-mot_04.fm
176 00/0210
Use of Positioners managed by C5G
On the Teach Pendant the rotating axis can be moved in Cartesian mode, using
the 7+ and 7- keys and it is not possible to enable or disenable the column
integration in real time.
hs-0-0-mot_04.fm
00/0210 177
Use of Positioners managed by C5G
the lever (robot standing). Therefore the robot base has to be always perpendicular to
the column rotating axis.
Vice-versa 4 robot base orientation positions are allowed (at 90° intervals) in relation to
the column base, and also the positive rotation direction can be selected at will.
1 - column rotation 2 - column base reference 3 - robot base Xb, Yb, Zb = Xbase , Ybase, Zbase
16.8.2.2 Calibration
The column calibration position is determined half way along the useful stroke and
marked by a zero notch. As this is an integrated axis it is not treated as a positioner of
the part to be machined and therefore it is not necessary to find points P1, P2 and P3
described in the Chap. TO_SET Program - Tool handling.
1 - column right-hand rotation R = column radius H = column height X b, Yb, Zb = Xbase , Ybase, Zbase
The axis is right-hand: if it is not, change the sign of the transmission ratio.
A table follows, summarising the useful mechanical data, taking into account that it is
mandatory that the integrated column is handled with auxiliary axis 7.
hs-0-0-mot_04.fm
178 00/0210
Use of Positioners managed by C5G
Besides the R and H geometrical data indicated above, for the complete kinematic
description of the integrated column, the following Boolean data also has to be defined :
– an UpDown bit that indicates whether the robot is placed facing upward (TRUE) or
if it is overturned (FALSE) (as in Fig. 16.14);
– two Boolean values that indicate how the robot base is oriented in relation to the
column base (this convention has been kept identical to that required for the
integrated slide, to have compatibility); in particular the convention is as follows
(see Fig. 16.15):
• 180° rotation - Xrobot_base in opposite direction to Xcolumn_base ;
• 0° rotation - Xrobot_base in the direction of Xcolumn_base ;
• 270°rotation - Xrobot_base in opposite direction to Ycolumn_base ;
• 90°rotation - Xrobot_base in the direction of Ycolumn_base ;
hs-0-0-mot_04.fm
00/0210 179
Use of Positioners managed by C5G
From the Teach Pendant, the linear axes can be moved in cartesian mode, using
AUX A - AUX B keys (by selecting the desired axes two-by-two).
It is also allowed to move the portal by means of the JPAD keys, where each
couple of keys allows to move one of the portal axes.
For further information related to AUX A - AUX B and JPAD keys, please refer to
C5G Control Unit Use manual - par. Black Keys - Chap. Use of the Teach Pendant
16.8.3.2 Calibration
The calibration position of the Portal, is usually defined close to the negative stroke of
each auxiliary axis, marked with a zero notch.
hs-0-0-mot_04.fm
180 00/0210
Use of Positioners managed by C5G
To configure the 3 linear axes Portal, please also refer to the C5G Control Unit Use
manual, par. AUX_AXES .
A table follows, summarising the useful mechanical data, taking into account that it is
mandatory that the first axis of the Portal is number 7 and the next ones are in
sequence.
Besides the geometrical data indicated above, for the complete kinematic description of
the 3 linear axes Portal, also the assembly angle of the robot base on the portal flange
is to be defined.
hs-0-0-mot_04.fm
00/0210 181
Use of Positioners managed by C5G
From the Teach Pendant, the linear axes can be moved in cartesian mode, using
AUX A - AUX B keys (by selecting the desired axes two-by-two).
For further information related to AUX A - AUX B and JPAD keys, please refer to
C5G Control Unit Use manual - par. Black Keys - Chap. Use of the Teach Pendant
hs-0-0-mot_04.fm
182 00/0210
Use of Positioners managed by C5G
16.8.4.2 Calibration
The calibration position of the Portal, is usually defined close to the negative stroke of
each auxiliary axis, marked with a zero notch.
To configure the 2 linear axes Portal, please also refer to the C5G Control Unit Use
manual, par. AUX_AXES .
The parameters needed for the 2 linear axes Portal kinematic description are indicated
in Fig. 16.19.
Then, the configuration software available on the Teach Pendant calculates the manual
mode speed value.
A table follows, summarising the useful mechanical data, taking into account that it is
mandatory that the first axis of the Portal is number 7 and the next one is in sequence.
Besides the geometrical data indicated above, for the complete kinematic description of
the 2 linear axes Portal, also the assembly angle of the robot base on the Portal flange
is to be defined.
hs-0-0-mot_04.fm
00/0210 183
Use of Positioners managed by C5G
Integrated motion means that the TCP position calculation takes into account both the
column position and the position of the rail the column is bearing on, besides the robot
configuration; this implies that the trans-rotational column is integrated in the direct
kinematic of the axes system.
This configuration causes the following effects:
– the cartesian positions (POSITION) are defined inside the cell area, independently
of the position of both the column axis and the rail axis, so even if the column axis
only is moved, the cartesian position is anyway modified;
– jogging (JOG) the column axis in a cartesian reference system (e.g. BASE
referenced JOG), the TCP position is not modified, due to the robot axes
movements which compensate the column motion.
From the Teach Pendant, the rotational axis and the translational one of the rail,
can be moved in cartesian mode, using AUX A - AUX B keys.
For further information related to AUX A - AUX B and JPAD keys, please refer to
C5G Control Unit Use manual - par.Black Keys - Chap. Use of the Teach Pendant
hs-0-0-mot_04.fm
184 00/0210
Use of Positioners managed by C5G
16.8.5.2 Calibration
The Column calibration position is defined at mid-stroke, marked with a zero notch; the
Rail calibration position is usually defined close to the negative stroke of the auxiliary
axis, marked with its zero notch.
To configure the Trans-rotational Column, please also refer to the C5G Control Unit
Use manual, par. AUX_AXES .
A table follows, summarising the useful mechanical data, taking into account that it is
mandatory that the first axis of the Integrated trans-rotational Column is number 7 and
it is the linear axis of the Rail (the translating axis).
hs-0-0-mot_04.fm
00/0210 185
Use of Positioners managed by C5G
Besides the geometrical data indicated above (H2 to describe the Column height and R
to describe its Radius), for the complete kinematic description of theTrans-rotational
Column, also the following parameters have to be defined:
– an UpDown bit that indicates whether the robot is placed facing upward (TRUE) or
if it is overturned (FALSE);
– a Robot Mounting Angle value that indicates how the Robot base is oriented in
relation to the Column base; in particular the convention is as follows:
• 180° rotation - Xrobot_base in opposite direction to Xcolumn_base ;
• 0° rotation - Xrobot_base in the direction of Xcolumn_base ;
• 270°rotation - Xrobot_base in opposite direction to Ycolumn_base ;
• 90°rotation - Xrobot_base in the direction of Ycolumn_base .
hs-0-0-mot_04.fm
186 00/0210
TO_SET Program - Tool handling
17.1 Introduction
TO_SET is an environment to calculate the positioner $TOOL, $UFRAME, $AUX_BASE
values, in a guided and automatic manner. It is also used to activate and execute the
Payload identification (optional function) procedure.
The most important characteristics are the following:
– It is completely organized in menus, and drives the operator to perform the required
steps; it also displays error messages or simple "warnings"
– All the messages are in the chosen language: when called up, TO_SET assumes
the language that is currently set in the C5G Control Unit.
– It uses the Teach Pendant with dedicated screen pages only.
This chapter contains detailed information about the following subjects:
– TO_SET Activation
– First screen page of TO_SET
– TOOL automatic calculation
– UFRAME automatic calculation
– BASE automatic calculation for POSITIONERS (optional)
– Payload identification (optional function)
HS-0-C5E-USO_44.fm
02/0610 187
TO_SET Program - Tool handling
17.2 Activation
TO_SET is supplied on CD in the system configuration TOOL directory and requires
these files:
– TO_INST.COD (for the TO_SET installation)
– TO_SET.ZIP (contains all the files needed by TO_SET)
To use it, just select the SETUP Page on the Teach Pendant (see C5G Control Unit
Use manual, Chap. Use of the Teach Pendant ) and choose ToolFrame environment
(see Fig. 17.1).
If it should be necessary to reinstall TO_SET, there are two ways it can be done:
– From Teach Pendant
– From WinC5G on Personal Computer
HS-0-C5E-USO_44.fm
188 02/0610
TO_SET Program - Tool handling
HS-0-C5E-USO_44.fm
02/0610 189
TO_SET Program - Tool handling
Using F1..F6 function keys, one of the displayed items can be selected:
TOOL (F1): TOOL automatic calculation
UFRAME (F2): UFRAME automatic calculation
POSITIONER (F3): Base automatic calculation for POSITIONERS
PAYLOAD IDENTIFICATION (F4): Payload characteristics Identification
Exit TO_SET (F6): end of TO_SET program
Note that whenever the User saves the calculated value, it is saved in the
corresponding Data Page table.
HS-0-C5E-USO_44.fm
190 02/0610
TO_SET Program - Tool handling
For any further information about the calibrated tool, see the Robot Technical
Specifications Manual.
HS-0-C5E-USO_44.fm
02/0610 191
TO_SET Program - Tool handling
with the measuring tool. For this purpose a MASTER CUBE has been designed with a
mobile tip that when fixed in zero position can be used as the REFERENCE POINT.
The cube (or any other point taken as reference) MUST BE IN A FIXED AND STABLE
POSITION, easily accessible by the robot and positioned on the FLOOR (if the robot is
on the floor), on the WALL (if the robot is on the wall), on the CEILING (if the robot is
suspended from the ceiling).
HS-0-C5E-USO_44.fm
192 02/0610
TO_SET Program - Tool handling
– Z_tool (calculation of <A>: Euler 1; <E> Euler 2). See Fig. 17.12 - Screen page
1.8.
To associate the new Z_tool to the new TCP , it is necessary to position the new
TCP (rotating the TOOL of axes 4 and 5) until the directions of the tool that is to
assume the new Z_tool coincide with the direction and sense of Z_rifer.
Example :
Supposing that the tool is a welding torch, to obtain the new Z_tool coming out
from the torch, the torch has to be brought in perpendicular to the reference
system (the same direction as Z_rifer), so that Z_rifer is assumed as Z_tool
coming out from the torch.
– X_tool and Y_tool (calculation <R>: Euler 3). See Fig. 17.13 - Screen page 1.9.
To associate the new X_tool and Y_tool to the new TCP of the tool, position the
new TCP (rotating in TOOL of axis 6) until the directions of the tool that is to
assume the new X_tool and Y_tool coincide with the direction and sense of
X_rifer and Y_rifer respectively.
Example:
Supposing that the tool is a welding torch, to obtain the new X_tool orientated
according to the "torch plane" identified between the torch and the mounting
bracket, this plane has to be oriented until it coincides with X_rifer direction, so
that X_rifer is assumed as X_tool, associated to the "torch plane". The same is
valid when referring to the Y_tool.
17.4.3 Procedure
To access the procedure, press key F1 in Fig. 17.2.
If the TOOL command is sent (pressing key F1) a second screen is shown that asks
the user to select either local tool or remote tool :
Accepted commands:
HS-0-C5E-USO_44.fm
02/0610 193
TO_SET Program - Tool handling
At this point the table that contains all the tools that already exist is scanned to check
which of these conditions applies:
– The entered tool number corresponds to an empty position in the table, therefore
the tool calculation proceeds with one of the available methods
(Fig. 17.6)
– The entered tool already exists in the table , therefore the measurement and the
method previously used for the calculation are displayed
(Fig. 17.7).
As can be seen, in the same file there may be tools calculated with the standard method
(without acquired positions) and tools calculated with the new procedure that also
associates the acquired positions to the tool measurement , it will therefore be the task
of the user to ascertain that the file tt_tool1.var in UD: is the correct one, containing
the tool to be checked.
Accepted commands:
HS-0-C5E-USO_44.fm
194 02/0610
TO_SET Program - Tool handling
Accepted commands:
The following description gives details of each possible procedure for the Local Tool :
– Tool calculation with standard method - Complete procedure
– Tool Calculation with "4 points method" - Complete procedure
– Tool verification with standard method - Partial procedure
– If it is the very first time that an automatic calculation of the tool is executed;
– If the reference point or the robot has been moved;
– If the robot has been recalibrated.
The complete procedure can be used to store in UD: the scan result position and the
declared tool master values in TO_SET.VAR .
This procedure only has to be executed once. All the subsequent calculations of a tool
mounted on the robot flange will only require the Partial procedure
(F2 from screen page 1.2 of Fig. 17.6).
HS-0-C5E-USO_44.fm
02/0610 195
TO_SET Program - Tool handling
Draws the operator’s attention to the Tool Master measurements. It displays them and
allows modification, if necessary.
Accepted commands:
Asks to take the TCP in the Tool Master on the reference, with the relevant
measurements correctly defined (Fig. 17.8).The robot may be in any position: the
operator can position the TCP on the reference as preferred, according to
requirements.
At this moment it is advisable to move in TOOL of axes 4, 5, 6 to check the dimensions
of the tool master and the robot calibration.
Accepted commands:
HS-0-C5E-USO_44.fm
196 02/0610
TO_SET Program - Tool handling
With the partial procedure the measurements of the tool mounted on the robot flange
can be calculated . It is only possible to calculate the relocations (X,Y,Z); or continue in
the calculation of the rotations (<A>: Euler 1; <E>: Euler 2) and lastly it is possible to
calculate the rotation around the new Z- tool (<R>: Euler 3).
Asks to bring the TCP of the tool to be measured on the reference point.
The robot may be in any position: the operator can position the TCP on the reference
as preferred, according to requirements.
Accepted commands:
HS-0-C5E-USO_44.fm
02/0610 197
TO_SET Program - Tool handling
Displays the $TOOL calculated values (XYZ relocations and AER orientations).
It is then possible to move axes 4,5,6 in TOOL to check that the new TCP does not
move on the reference (movements of approx. 3 millimetres are accepted).
If this is not so, check:
– robot calibration,
– tool master dimensions declared in the Complete procedure,
– position of the reference point (not changed as to the Complete procedure ).
After checking, repeat the procedure (Complete or Partial).
Accepted commands:
HS-0-C5E-USO_44.fm
198 02/0610
TO_SET Program - Tool handling
The operator has to position the Z_TOOL (positive sense ) of the tool parallel to a drive
shaft of the robot BASE . To choose the required direction just press one of the function
keys (F2..F4) and then F1 to accept the measurement.
If the tool axes are parallel to the flange reference frame ($TOOL(0)), it is best to bring
the robot to calibration position; the advantage of this operation is that it brings all three
tool axes parallel to those of the BASE with no further movements of the robot. To
complete the orientation calculation the operator only has to use the appropriate
function keys to select to which BASE drive shafts the Z_TOOL and then the X_TOOL
are parallel.
Check that the new orientation is that actually wished for, and if necessary repeat the
procedure (F3 from screen page 1.9 in Fig. 17.13).
Accepted commands:
Displays the $TOOL calculated values (XYZ relocations and AER orientations).
Accepted commands:
HS-0-C5E-USO_44.fm
02/0610 199
TO_SET Program - Tool handling
The operator has to direct the X_TOOL (positive sense) of the tool parallel to one of the
drive shafts of the robot BASE (the axis selected in the previous step is no longer
available). To choose the desired direction just press one of the function keys (F2..F5)
and then F1.
Check that the new orientation is that actually required, and if necessary repeat the
procedure (F3 from screen page 1.11 in Fig. 17.15).
Accepted commands:
Displays the $TOOL calculated values (XYZ relocations and AER orientations).
Accepted commands:
HS-0-C5E-USO_44.fm
200 02/0610
TO_SET Program - Tool handling
After every Save operation, if there are already Euler angles in the table, the following
screen page is displayed:
This displays the $TOOL calculated values (XYZ relocations and AER orientations) and
warns that there are already Euler angles in the table. It is asked if they are to be kept
(F1) or to be overwritten with the new values (F2). This makes it possible to keep the
Euler angles if it is only required to recalculate the tool relocations.
Fig. 17.17 displays the TOOL MASTER values (XYZ relocations) and allows their
modification.
Accepted commands:
The screen page in Fig. 17.18 - Screen page 1.14 displays whether a Partial procedure
has been requested without ever having executed a Complete procedure. This means
HS-0-C5E-USO_44.fm
02/0610 201
TO_SET Program - Tool handling
Accepted commands:
The screen page in Fig. 17.19 displays whether the SAVE procedure for the calculated
values has been omitted.
Accepted commands:
HS-0-C5E-USO_44.fm
202 02/0610
TO_SET Program - Tool handling
1. acquisition point 3
2. acquisition point 2
3. acquisition point 1
4. reference
b. Teach point 1
c. Move the TCP back to the reference point with a sufficiently different orientation
as to the previous point
d. Teach point 2
g. Move the TCP back to the reference point with a sufficiently different orientation
as to the previous points
HS-0-C5E-USO_44.fm
02/0610 203
TO_SET Program - Tool handling
The user moves the TCP to the reference point and confirms the acquisition by pressing
F1 key onthe Teach Pendant .
It is possible to interrupt the tool calculation at any time and to return to the main menu
by pressing F6 key.
For the acquisition of the next points the screen page is the same as the previous one.
As soon as a first tool measurement is ready, a screen page is shown to inform the user
that as from this moment it is possible to move in TOOL reference.
Continuing, the following situations may take place:
– If the calculation algorithm returns an imprecise tool measurement the following
screen page is shown (Fig. 17.22):
Accepted commands:
HS-0-C5E-USO_44.fm
204 02/0610
TO_SET Program - Tool handling
If F1 is pressed , the calculated TCP coordinates are displayed and from this point
onwards the user proceeds according to the modes described in Fig. 17.11.
– If the user has acquired 8 points and the algorithm has not been able to calculate
the tool, even with an imprecise measurement, this means that the acquired
points are imprecise or are dependently linear
(see Fig. 17.24).
The more diversified the orientation of the acquired points, the better the results!
Accepted commands:
HS-0-C5E-USO_44.fm
02/0610 205
TO_SET Program - Tool handling
This option is used to repeat a tool measurement that has already been executed and
saved in file tt_tool1.var. If the method used previously was the standard method, the
partial procedure of this method is followed (Fig. 17.10), whereas if the 4 points method
was used, a procedure is followed that is very similar to that already described for a
new calculation of the tool, with the additional possibility to move the reference on the
remote TCP with MOVE commands to the position stored together with the tool
measurement. In this way the measurement repeatability is improved since the tool
verification is executed acquiring the points with the same orientation (with a very slight
approximation) as those of the previous acquisition.
When the START key is pressed (with control in Drive On) the reference moves toward
the first stored position associated to that tool; the Start can be released at any time to
manually adjust the reference approach to the TCP to be measured in Jog , and to
resume the movement toward the position by pressing the START key again.
Accepted commands:
Be sure that the movement is executed at the speed indicated on the Teach
Pendant!
After the Move has terminated (either naturally or forced by the user) pass to the next
acquisition following the same procedure as described for the first point. If instead it is
chosen to return to the first menu, press F6.
Once the algorithm is able to calculate a tool, a screen page is displayed informing the
user that as from that moment it is possible to move in TOOL reference.
HS-0-C5E-USO_44.fm
206 02/0610
TO_SET Program - Tool handling
the main menu of the tool calculation. In this environment the coordinates system of
a fixed tool (remote tool) can be defined using the robot as measuring system.
Detailed information is given for the following subjects:
– Tools needed
– General characteristics
If F1 is pressed, the Remote Tool remains enabled, if F2 is pressed the start situation
is resumed.
HS-0-C5E-USO_44.fm
02/0610 207
TO_SET Program - Tool handling
17.5.3 Procedure
If the UFRAME command is entered (pressing F1) access is obtained to a second
screen page (Fig. 17.27) that asks the User to select either LOCAL FRAME or
REMOTE FRAME:
HS-0-C5E-USO_44.fm
208 02/0610
TO_SET Program - Tool handling
This screen page (Fig. 17.28 - Screen page 3.1) shows the operator the values of the
currently declared $TOOL variable.
The values are referred to the tool mounted on the flange and that will be used for the
FRAME calculation. The values are displayed and they can be modified if necessary.
Accepted commands:
HS-0-C5E-USO_44.fm
02/0610 209
TO_SET Program - Tool handling
Asks the operator to take the tool TCP on the ORIGIN point.
The robot may be in any position: the operator can position the TCP on the ORIGIN
point as preferred, according to requirements.
Accepted commands:
HS-0-C5E-USO_44.fm
210 02/0610
TO_SET Program - Tool handling
Asks the operator to take the tool TCP on the Xypos point .
The robot may be in any position: the operator can move the TCP to Xpos point as
preferred, according to requirements.
Accepted commands:
The program displays the $UFRAME calculated values (XYZ relocations and AER
orientations).
At this time it is possible to move in Uframe mode (selected by Motion Page, COORD
menu - see C5G Control Unit Use) to check that the new origin is that desired. If it is
not so, check:
At this time it is possible to move in USR mode (selected by key [TYP] of TP) to check
that the new origin is that desired. If it is not so, check:
– Robot calibration;
– $TOOL values (referred to the tool mounted on the flange);
– the 3 reference points (check that the sequence required by TO_SET has been
followed)
HS-0-C5E-USO_44.fm
02/0610 211
TO_SET Program - Tool handling
Accepted commands:
The program displays the $UFRAME calculated values (XYZ relocations and AER
orientations).
The program allows to save the calculated values in the TU_FRAME table.
Accepted commands:
to omit the SAVE request. In this case the screen page will be
<esc>:
displayed in (Fig. 17.35)
Displays the $TOOL values currently declared (XYZ relocations and AER orientations)
and allows their modification.
HS-0-C5E-USO_44.fm
212 02/0610
TO_SET Program - Tool handling
Accepted commands:
Displayed if the SAVE procedure for the calculated values has been omitted .
Accepted commands:
HS-0-C5E-USO_44.fm
02/0610 213
TO_SET Program - Tool handling
17.5.4.1.1 Tool with known dimensions mounted onto the Robot Flange
A tool must be mounted onto the robot flange that has known dimensions declared in
the $TOOL system variable.
It is advised to use the TOOL MASTER or CALIBRATED TOOL that was used for the
TOOL automatic calculation. As an alternative an identified tip on the work tool can be
used that has a distance from the robot flange centre that is known and precise.
HS-0-C5E-USO_44.fm
214 02/0610
TO_SET Program - Tool handling
17.5.4.3 Procedure
Shows the operator the values of the currently declared $TOOL variable. The values are
referred to the tool mounted on the flange and that will be used for the FRAME
calculation. The values are displayed and they can be modified if necessary.
Accepted commands:
HS-0-C5E-USO_44.fm
02/0610 215
TO_SET Program - Tool handling
F1: to be pressed when the robot is on point; continues procedure (Fig. 17.39)
F6: returns to main menu (Fig. 17.2)
Asks the operator to move the tool TCP to Xpos point. The robot may be in any position:
the operator can move the TCP to Xpos point as preferred, according to requirements.
Accepted commands:
Asks the operator to move the tool TCP to XYpos point . The robot may be in any
position: the operator can move the TCP to XYpos point as preferred, according to
requirements.
Accepted commands:
HS-0-C5E-USO_44.fm
216 02/0610
TO_SET Program - Tool handling
Displays the $UFRAME calculated values (XYZ displacements and AER orientations).
At this time it is possible to move in UFRAME mode (selected by COORD key of the
Teach Pendant) to check that the new origin is the desired one. If not, check:
muovere in modalità UFRAME (selezione tramite tasto COORD del Terminale di
Programmazione)
– robot calibration;
– $TOOL values (referred to the tool mounted on the flange);
– the 3 reference points (check that the sequence required by TO_SET )
Accepted commands:
Displays the $UFRAME calculated values (XYZ displacements and AER orientations).
To save the calculated values in the TU_FRAME table.
HS-0-C5E-USO_44.fm
02/0610 217
TO_SET Program - Tool handling
Accepted commands:
to omit the SAVE request. In this case the screen page will be
<esc>:
displayed in Fig. 17.44
Displays the $TOOL values currently declared (XYZ displacements and AER
orientations) and allows the modification.
Accepted commands:
Displayed if the SAVE procedure for the calculated values has been omitted.
Accepted commands:
HS-0-C5E-USO_44.fm
218 02/0610
TO_SET Program - Tool handling
Before returning to the main menu (Fig. 17.2) it is asked if the remote tool is to be kept
enabled (Fig. 17.46).
Press F1 to keep the remote tool enabled; press F2 to restore the start situation (the tool
is the one shown in Fig. 17.37).
HS-0-C5E-USO_44.fm
02/0610 219
TO_SET Program - Tool handling
HS-0-C5E-USO_44.fm
220 02/0610
TO_SET Program - Tool handling
Draws the operator’s attention to the values of the currently declared $TOOL variable.
The values must refer to the tool mounted on the flange and will be used for the
calculation of $BASE or $AUX_BASE. When these values are displayed, they can be
modified if necessary.
Accepted commands:
Draws the operator’s attention to the values of the calibrated tool used as reference on
points P1, P2, P3. The values are displayed and can be modified if necessary.
Accepted commands:
HS-0-C5E-USO_44.fm
02/0610 221
TO_SET Program - Tool handling
<esc>: omits the insertion (returns to the screen page of Fig. 17.49)
HS-0-C5E-USO_44.fm
222 02/0610
TO_SET Program - Tool handling
The [narm] (to which the selected positioner is associated) assumed by TO_SET
is the one displayed on the TP in the field [Ar:] at the moment in which the
positioner number is inserted
Accepted commands:
<esc>: omits the insertion (returns to the screen page of Fig. 17.49)
HS-0-C5E-USO_44.fm
02/0610 223
TO_SET Program - Tool handling
F1: to press when the robot is on the point; cont. (Fig. 17.54)
F6: returns to main menu (Fig. 17.2)
F1: to press when the robot is on the point; cont.(Fig. 17.55 or Fig. 17.61)
F6: returns to main menu (Fig. 17.2)
HS-0-C5E-USO_44.fm
224 02/0610
TO_SET Program - Tool handling
Displays the calculated $BASE or $AUX_BASE values (XYZ displacements and AER
orientations).
At this moment the positioner axes can be moved in JOINT selecting the ARM number
(if the positioner is an ARM), to check that the cooperating move between robot and
positioner is correct.
If not, check the following:
– the robot calibration;
– the $TOOL values (they are to refer to the tool mounted on the flange);
– if there are several positioners, check that the number of the positioner is that
actually used for the calculation (Fig. 17.50 or Fig. 17.52).
– the 3 reference points (check that the sequence required by TO_SET has been
respected).
Accepted commands:
HS-0-C5E-USO_44.fm
02/0610 225
TO_SET Program - Tool handling
Displayed if the SAVE request has been performed. The calculated values assigned to
the opportune system variables have been successfully saved in the .C5G system file.
Accepted commands:
Displays the currently declared $TOOL values (XYZ displacements and AER
orientations) and allows their modification.
Accepted commands:
Displays the values of the reference calibrated tool (XYZ displacements) and allows
their modification.
Accepted commands:
HS-0-C5E-USO_44.fm
226 02/0610
TO_SET Program - Tool handling
Displayed if an ARM type positioner has been entered that is not acknowledged by the
system (see Fig. 17.50).
Accepted commands:
Displayed if an AUX type positioner has been entered that is not acknowledged by the
system (see Fig. 17.52).
Accepted commands:
HS-0-C5E-USO_44.fm
02/0610 227
TO_SET Program - Tool handling
Displayed when a SAVE operation (from Fig. 17.55) has been requested but the C5G
is not in PROG + DRIVES OFF. This condition is necessary since the SAVE operation
requires the system command Config. (F1), Save the configuration file, SETUP
Page.
Accepted commands:
HS-0-C5E-USO_44.fm
228 02/0610
TO_SET Program - Tool handling
Press F4 key in the screen page in Fig. 17.2, to access this procedure.
The new generation robots (NJ and NJ4) are fitted with a complete dynamic model
on all six axes.
Because of the model's sensitivity to the declared payload parameters, it is necessary
that the user checks in every situation the correct definition of the used payload.
An imprecision in the declaration of the payload characteristics has a negative influence
on the robot performance.
Warning: for safety reasons it is very important that the machine is not used
before having defined the payload values.
The omission or a big error in the payload declaration could create potentially
hazardous situations for the users and for the fixtures
During the Payload Identification procedure also the outfitting weight (e.g.:
cable) is identified.
If it is wished to execute the procedure with outfittings present (for example
cables) that exert significant traction (for example on the wrist structure), it is
advised to remove them where possible, or in any case ensure that their presence
does not influence the results of the procedure.
For the identification, Comau does not ask for movements WITHOUT load, but
only WITH load.
The Payload identification procedure, running the execution from two separate
movement programs that involve the wrist axis, and, in part, axis 3 of the robot,
recalculates the values of the following system variables :
HS-0-C5E-USO_44.fm
02/0610 229
TO_SET Program - Tool handling
– $TOOL_MASS (kg)
– $TOOL_CENTER (x, y and z)
– $TOOL_INERTIA[1..6] (it is only necessary to supply items from I1 to I6, in
kg/sq.m, since the Inertia matrix is symmetrical). The useful reference system to
define the Inertia matrix is that of the tool ($TOOL_CENTER), with origin in COG
(Centre Of Gravity).
Once this has been determined, the parameters will be immediately active and
automatically stored in the specific table created by TO_SET (TT_TOOL1.var), to be
called up when executing the movement cycles, each time the same payload is used.
17.7.2 Procedure
The motion programs for the Payload identification are supplied by Comau in PDL2
language and differ depending on the robot model, on the basis of the robot kinematic
features. Their use is strongly recommended, unless there are physical impediments in
the robot working area.
Before installation, check that the overall dimensions caused by the presence of
any fixtures installed in the robot operating area, allows the complete execution
of the programs available for the Payload identification, supplied by Comau.
If there is not space enough, it is advised to run this procedure BEFORE the final
positioning of the robot in the cell or line; if, in spite of the limited space, it is
decided to run the procedure, the user can change the Payload identification
programs, reducing the axis strokes and/or changing the position of some of
them (for example axis 1 and 2): in any case, the variations are to be made in
compliance with the fundamental requirements needed for the modification of the
Payload identification programs (see par. 17.7.2.1 Requirements to modify
Payload identification programs on page 230).
HS-0-C5E-USO_44.fm
230 02/0610
TO_SET Program - Tool handling
Press F4 key from the screen page in Fig. 17.2, to access this procedure.
a. If TO_SET program is to be installed again, follow par. 17.2 Activation on page 188
description.
if remote, the calculated data will be saved to TU_FRAME.VAR table; if local, they
will be saved to TT_TOOL.VAR table
d. the modal selector switch must be set to T1 (if necessary, reposition it)
HS-0-C5E-USO_44.fm
02/0610 231
TO_SET Program - Tool handling
g. if the calibration position has been reached, choose MOVE EXECUTED (F1) to
directly go to step h.
If it is not possible to reach the calibration position, the start position has to be
changed: choose CHANGE START POS (F2). The following screen page is
displayed:
HS-0-C5E-USO_44.fm
232 02/0610
TO_SET Program - Tool handling
g.1 Use the jog keys to move the robot to the new start position (remember to
ALWAYS keep axis 3 parallel to the base!). Choose MOVE EXECUTED (F1): if
the system does not accept the new start position, repeat this step. When the Move
is finally executed correctly, continue with the next step.
i. if the choice is POSITION MODIFY (F2), to change the start point or reduce the
stroke of one or more axes, the following screen page is displayed:
HS-0-C5E-USO_44.fm
02/0610 233
TO_SET Program - Tool handling
i.1 to change the start position select CHANGE INITIAL POS (F1); in this case
execute the same operations as indicated in step g.1.
If instead it is wished to reduce the stroke of one or more axes, select REDUCING
MOVEMENTS (F2).
The system displays the involved axes and the corresponding selection keys:
i.2 Choose the axis for the stroke reduction, or select CONTINUE (F5) to return to
step h., without making any further modifications
i.3 Each time that either F1 or F2 key is pressed (for positive and negative direction
respectively), the stroke of the selected axis will be reduced by a pre-defined
quantity. If the initial values are to be resumed, choose RESET INITIAL VALUES
(F3). When finished, choose CONTINUE (F5) to return to step i.2
HS-0-C5E-USO_44.fm
234 02/0610
TO_SET Program - Tool handling
j.3 switch on the drives pressing DRIVE ON and press START key
j.4 the automatic warm-up program is then executed. Wait until finished
HS-0-C5E-USO_44.fm
02/0610 235
TO_SET Program - Tool handling
HS-0-C5E-USO_44.fm
236 02/0610
TO_SET Program - Tool handling
While running, the cycle number of the current program is displayed, on the
number of total cycles to be run.
o. the execution of the first movement program starts (slow). Wait until finished
HS-0-C5E-USO_44.fm
02/0610 237
TO_SET Program - Tool handling
q. if the overall dimensions, the payload and the tool structure allow the execution of
the second program at normal speed, select YES (F1), otherwise select NO (F2).
If NO (F2) is chosen, the second Identification program will be run at a slower
speed
HS-0-C5E-USO_44.fm
238 02/0610
TO_SET Program - Tool handling
u. the execution of the second motion program starts (at normal speed). Wait until
completion
The system processes the data collected during the execution of the two motion
programs. When processing has been completed, a screen page is shown
containing the calculated values (weight, centre of weight and inertia). Choose
SAVE (F1) to save them in the suitable DATA environment table and file:
HS-0-C5E-USO_44.fm
02/0610 239
Interference Regions (optional feature)
18.1 Introduction
Interference Regions are interference/interchange volumes shared between Robot and
Robot, and between Robot and structures.
Their handling allows to interact among machines, optimizing the use of the cell inside
space, in order to guarantee the collision prevention, upon defining the geometry of the
Robot working zone inside volumes.
In the Interference Regions handling system, a library has been created of basic
geometrical shapes allowing to support most functional cases, to control both cartesian
and joint working areas.
Both for cartesian and joint case, it is allowed to define 16 geometrical regions to be
used both to monitor and block the Robot to enter them.
– Regions types
– Regions Shape and definition
– IR_LIB library to support Interference Regions creation
– Examples.
pr-0-0-gpr_13.fm
240 04/0711
Interference Regions (optional feature)
Region; this functionality implies that when the TCP is close to the Interference Region,
the Robot velocity is reduced, proportionally to its distance from the Region.
This kind of modality and functionality is useful whenever it is needed to define some
Regions which the Robot should NEVER enter and also should NEVER work in close
proximity at maximum speed. The Robot, in fact, slows down its motion proportionally
to the distance from the Forbidden Region surface.
The Joint Monitored Regions functioning principle is the electronic cams one, where it
is allowed to define some stroke intervals for an axis, upon which a logical port is set to
ON/OFF values.
For example, it is possible to define a Joint Monitored Region to monitor axes 1, 4 and
6 so that, as soon as the monitored joints values are inside the defined intervals, the
system sets to ON/OFF values a previously defined by the User logical port.
pr-0-0-gpr_13.fm
04/0711 241
Interference Regions (optional feature)
– Cylinder
– Box
– Plane.
Such Regions position and dimension definition is auto-taught, by means of the IR_DEF
setup tool. As an alternative, it is also possible to create PDL2 programs calling suitable
routines and built-in routines. For further details see par. 18.4 IR_LIB library to support
Interference Regions creation on page 244.
In the auto-teach procedure the TCP is moved to some basic points of the above listed
shapes, following a guided sequence on the Teach Pendant.
For each shape a procedure is available which starts defining a reference frame and
continues defining some geometric values (radius, height, width, depth, ...), or
auto-teaches some more points.
18.3.1.1 Sphere
By means of teaching point P1 (center of the sphere), the frame is defined (no matter
the orientation) to correspond to the center of the sphere. The radius is assigned by the
User at the end of the guided procedure or by means of a PDL2 program. In such a way
the frame corresponding to P1 and the geometric value sphere radius are stored.
R - radius
18.3.1.2 Cylinder
By means of sequentially teaching points P1 and P2, the frame and the cylinder height
are defined. The radius is assigned by the User at the end of the guided teaching
procedure.
In details:
– P1 defines the frame origin.
– P2 defines cylinder height and orientation.
pr-0-0-gpr_13.fm
242 04/0711
Interference Regions (optional feature)
H - height R - radius
18.3.1.3 Box
By means of sequentially teaching P1, P2, P3 points, frame and two dimensions (width
and depth), are defined, whereas by means of teaching P4 point height is defined. In
such a way, the calculated frame (by means of POS_FRAME(P1, P2, P3)) and the three
geometric values, width (P2-P1), depth (P3-P1) and height (P4-P1), are stored.
In details:
– P1 definies the frame origin.
– P2 defines width axis.
– P3 defines base plane and depth.
– P4 defines height.
18.3.1.4 Plane
By means of sequentially teaching P1, P2, P3 points, the frame is defined. In such a way
the calculated frame (by means of POS_FRAME(P1, P2, P3)) is stored. The defined
Region is shown in Fig. 18.4.
pr-0-0-gpr_13.fm
04/0711 243
Interference Regions (optional feature)
pr-0-0-gpr_13.fm
244 04/0711
Interference Regions (optional feature)
IMPORT ‘IR_DEF’
These functions can be used to allow the User to intuitively create both cartesian and
joint Regions, following the above described instructions.
Example 1
An example follows to define a cylindrical cartesian region from within a program:
Example 2
In the following example a PDL2 program section is shown which creates a Joint
Monitored Region for axis 6 only.
pr-0-0-gpr_13.fm
04/0711 245
Interference Regions (optional feature)
...............
...............
The above listed code inform the System that Interference Region number 4 is active as
a Joint Monitored Region and axis 6 is monitored in range [-60, 60]. This means that as
soon as axis 6 enters the declared range, bit 3 of $FMO[1] is immedidately set to ON,
as declared by IR_SET($FMO[1],3,4, ON) built-in routine.
18.5 Examples
– Sample program for Cartesian Interference Regions
– Sample program for a Joint Interference Region.
pr-0-0-gpr_13.fm
246 04/0711
Interference Regions (optional feature)
BEGIN
ToolFrame(3, 0) -- tool 3, frame 0
END ir_cart
pr-0-0-gpr_13.fm
04/0711 247
Interference Regions (optional feature)
BEGIN
--
-- Defining Joint Interference Region number 2
--
IR_SET($FMO[1], 1, 2, IR_PRESENCE) -- Associating bit 1 of $FMO[1] to region 2
-- which then becomes a monitored region
-- Defining axis 3 (arm 1) limitations
aj_neg_joint[3] := -75
ai_arm := 1
ai_mask := 0b00000100 -- axis 3 binary mask
IR_CreateJoint(aj_neg_joint,aj_pos_joint,ai_arm,ai_mask,2)
CYCLE
MOVE TO pnt0001J
MOVEFLY TO pnt0002J ADVANCE
MOVEFLY JOINT TO jnt0018J ADVANCE
MOVE LINEAR TO jnt0019J
MOVE LINEAR TO jnt0020J
MOVEFLY JOINT TO jnt0021J ADVANCE
MOVE LINEAR TO jnt0022J
MOVE LINEAR TO jnt0023J
END ir_jnt
pr-0-0-gpr_13.fm
248 04/0711
Axes Pursuit (optional feature)
19.1 Introduction
The Axes pursuit functionality makes it possible moving, both in Automatic and
Programming mode, one or more axes belonging to one Arm (called the MASTER)
allowing one or more axes of a different Arm (called the SLAVE) to pursue the MASTER
Arm axes.
– Axes Pursuit
– Error handling when Axes Pursuit functionality is active
– Configuring the software option.
As soon as the functionality is activated, the MASTER Arm axis pursuit made by
the SLAVE Arm axis, starts from the current position of the SLAVE Arm axis. So,
the relative delta between pursuer/pursued axis remains unchanged, but it can
change if the functionality is disabled and the two axes move independently.
pr-0-0-gpr_14.fm
03/0111 249
Axes Pursuit (optional feature)
The System which is configured to have Axes Pursuit option, handles a special clalss of
errors related to such a functionality.
First of all, if the option is activated, the system does not allow moving the SLAVE Arm
independently from the MASTER Arm.
This imply that, if $AX_PURSUIT_ENBL is set to TRUE, and an attempt to manual or by
a user program move the robot SLAVE Arm is performed, the system will return the error
message:
"Movement not allowed whith axes pursuit option activated".
During the option configuration, the system checks the correctness of the inserted data,
also according to its pre-existing configuration.
If, for example, a not expected value is set for the MASTER Arm axis in
$AX_PURSUIT_LINKED variable (e.g. a not existing MASTER axis), this situation
would cause the system to issue an error message at the startup:
"The axis of MASTER Arm does not exist".
In the case in which, at the system startup, a wrong configuration error is issued for the
Axes Pursuit option, the functionality is automatically disabled and it will not be possible
to use it until the system is properly configured.
pr-0-0-gpr_14.fm
250 03/0111
Axes Pursuit (optional feature)
ARMs System:
– the first Arm is configured as the MASTER
– the second Arm is, obviously, configured as the SLAVE
– axis 1 belonging to the SLAVE pursues axis 7 belonging to the MASTER
– axis 2 belonging to the SLAVE pursues axis 8 belonging to the MASTER.
$AX_PURSUIT_ENBL := TRUE
$AX_PURSUIT_ARM_MASTER := 1
$ARM_DATA[2].AX_PURSUIT_LINKED[1] := 7
$ARM_DATA[2].AX_PURSUIT_LINKED[2] := 8
pr-0-0-gpr_14.fm
03/0111 251
COMAU Robotics services
Repair: repairs.robotics@comau.com
Training: training.robotics@comau.com
Spare parts: spares.robotics@comau.com
Technical service: service.robotics@comau.com