controller unit - fs.gongkong.comfs.gongkong.com/files/technicaldata/201207/... · comau robotics...

Comau RoboticsInstruction Handbook

Controller Unit

MOTION PROGRAMMING System Software Rel. 1.10

Robot movements in programming mode, motion control, optional features (synchronous motion, cooperative motion, sensor tracking, weaving, path governor, smartmove, kinematic compensation, collision detection), moving through singularities, positioners and portals, TO_SET program, Interference Regions.

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.

Copyright © 2003 by COMAU - Date of publication 07/2011

Summary

SUMMARY

PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Symbols used in the manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Modification History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1. GENERAL SAFETY PRECAUTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...13

Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Safety Precautions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2. SYSTEM OPERATING MODES AND STATES . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...23

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

System operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

System states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24HOLD status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25AUTO status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26PROGR status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26ALARM status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Stand-by function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3. TURN-SET AND CALIBRATION - BASIC CONCEPTS . . . . . . . . . . . . . . . . . . . . . . ...28

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Turn-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Turn-set on system calibration position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Turn-set on user calibration position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Turn-set for robot axes with multi-turn stroke. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30System calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31User calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4. ROBOT MOTION IN PROGRAMMING MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...33

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1lb-rc-c5e-motion_enTOC.fm

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

5. MOTION CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..40

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Frames of Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40System Frame of Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Base System of Reference definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Flange Tooling definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

TCP Offset definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Calculating the Rotation Angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

FIRST METHOD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44SECOND METHOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

User System of Reference definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

Trajectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Joint Interpolation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Linear Interpolation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Circular Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Orientation Evolution during Linear or Circular movements. . . . . . . . . . . . . . . . . . . . . . . . . . 47Attitude Flags During Linear and Circular Movements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Turn Flag and minimum path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Position Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49On Trajectory Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49On Position (ON POS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Example of On Pos and On Trajectory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Speed Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Cartesian Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Cartesian Speed Control Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Run-Time modifying the Linear Speed Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

Joint Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Manual Motion Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Acceleration and Deceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Acceleration/Deceleration Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Joint Interpolation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Cartesian Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Manual Motions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Motion termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60COARSE and FINE Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60


Summary

JNT_COARSE and JNT_FINE Termination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61NOSETTLE Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Trajectory Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Recovery Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Pending Motion Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62Recovery Range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62Execution Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

Process Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Automatic Process Resume. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Continuous Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Trajectory Shape During Continuous Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Continuous Motion Modes (FLY) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

FLY_NORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67FLY_CART (Controller Aided Resolved Trajectory) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68

Dynamic Machine Stress Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68Constant Speed Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69Control of Trajectory During FLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69Debug of Fly Motions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71Variables used with FLY Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72

Remote Tool System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Integrated Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Integrated Axis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Jogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75Reference Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76

Palletizing functionality (optional feature) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Enabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Disabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Example of a Palletizing Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6. SYNCHRONOUS MOTION (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . ...79

Synchronization with Auxiliary Axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Synchronized Arms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Motion limitation of the two Arms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Jogging Synchronized Arms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Teaching and Modifying Positions (REC/MOD) with Synchronized Arms . . . . . . . . . . . . . . . . . 81

Loss of Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Run-time modifying the Linear Speed Override. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7. COOPERATIVE MOTION (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . ...84

Cooperative Motion with Auxiliary Axes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Cooperative Arms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Multi-cooperative motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86


Summary

Jogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

8. SENSOR TRACKING (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..88

Principle of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Configuration on several arms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Sensor interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Integrated Sensors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90External sensors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Sensor reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Sensor integral with the tool (TOOL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Sensor integral with the user reference system (USER) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Sensor integral with the world reference system (WORLD). . . . . . . . . . . . . . . . . . . . . . . . . . 93Sensor integral with the weaving reference system (WEAVE). . . . . . . . . . . . . . . . . . . . . . . . 93

Type of information acquired by the sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Correction actuation criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Relative and absolute deviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Actuation of deviation in time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Overall deviations control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Sensor tracking enable mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Sensor malfunctioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Robot stop in the case of sensor malfunctioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Redefinition of overall deviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Accumulative overall deviations management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Interrupted sensor tracking session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Suspended sensor tracking session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Resetting in spread condition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Limitations in parameter changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Programming example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

9. CONVEYOR TRACKING (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..106

10. MOTION WITH WEAVING (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . ..107

Weaving Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Weaving Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Weaving Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Wave Shape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Weave Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Weave Amplification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Stopping Motions with Weaving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Programming Weaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Weaving without Arm motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117


Summary

Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Example - Using the weaving without Arm motion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

11. PATH GOVERNOR (OPTIONAL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...119

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Enable Path Governor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Disable Path Governor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

12. SMARTMOVE (OPTIONAL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...122

Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Jerk Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Cartesian Motions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

13. FLOW MODULATE ALGORITHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...124

14. PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING . . . . . . . . . . . . . . . ...126

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Offset algorithm with Dynamic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Kinematic offset algorithm (optional feature) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Moving through axis 5 singularities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Using WRIST_JNT modality to go through singularities . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Using WRIST_JNT modality to go through singularities. . . . . . . . . . . . . . . . . . . . . . . . . . .130Manual motion (jog keys) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Robots without compensation (effect of the inverse kinematics) . . . . . . . . . . . . . . . . . . . . . . . 131Inverse conversion of SMART NJ4 (non-spherical wrist) model . . . . . . . . . . . . . . . . . . . . . 131

Approximation in the orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132Move to a taught POSITION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132Fly between MOVE LINEAR/CIRCULAR and MOVE JOINT . . . . . . . . . . . . . . . . . . . . . . .132Axis 5 singularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133Cartesian position out of range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134TCP in the back of the robot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135TCP behind axis 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137WCP close to axis 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138

Inverse conversion of SMART NJ models (spherical wrist only) . . . . . . . . . . . . . . . . . . . . . 138Axis 5 singularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139

Programming rules for non-spherical wrist robots (SMART NJ4) . . . . . . . . . . . . . . . . . . . . . . 139How to stay away from a singularity zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Changing the orientation of the points along the path . . . . . . . . . . . . . . . . . . . . . . . . . . . .140


Summary

Properly designing the work-cell layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141Modifying tool inserting a small angle between robot flange and tool flange . . . . . . . . . . .144

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

15. COLLISION DETECTION (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..148

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Basic concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Activation/deactivation of Collision Detection function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Collision Detection sensitivity type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150$COLL_TYPE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150$ARM_SENSITIVITY (sensitivity threshold of the axes) . . . . . . . . . . . . . . . . . . . . . . . . . . . 151$COLL_SOFT_PER (axes compliance thresholds) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Notes about the collision detection use procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Use of the Collision Detection Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Sample Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Enabling the Collision Detection functionality for a single MOVE statement . . . . . . . . . . . . 157Enabling Collision Detection again from within a Program. . . . . . . . . . . . . . . . . . . . . . . . . . 158Automatic calculation of the sensitivity thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Managing "collision detected" event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Use of CDetect open source library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

16. USE OF POSITIONERS MANAGED BY C5G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..162

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

General Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Axis rotation directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Convention for the mechanical positioning of points P1, P2 and P3 . . . . . . . . . . . . . . . . . . 163

Programming override value calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Positioners with 1 rotating axis type MP, PTDO, PTDV, TR3000/6000. . . . . . . . . . . . . . . . . . 165Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

PTORB - Positioner with 2 perpendicular axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Positioner with two tilting-rotating axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168

Positioner with two axes in "L" arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169

Calibration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170


Summary

Positioners with 2 non perpendicular axes, type PTORB-alfa . . . . . . . . . . . . . . . . . . . . . . . . . 172Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Integrated robot positioning axes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Integrated slide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176

Integrated rotating column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178

Three linear axes portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181

Two linear axes Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183

Integrated trans-rotational Column. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185

17. TO_SET PROGRAM - TOOL HANDLING. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...187

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188From Teach Pendant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188From WinC5G on Personal Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

First screen page of TO_SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

TOOL automatic calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Needed Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Calibrated tool (Tool Master) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191Reference point (or master cube). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191

General characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Tool orientation calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192How to identify the "dummy reference system" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192

Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Tool calculation with standard method - Complete procedure . . . . . . . . . . . . . . . . . . . . . . . 195Tool verification with standard method - Partial procedure . . . . . . . . . . . . . . . . . . . . . . . . . 197Tool Calculation with "4 points method" - Complete procedure . . . . . . . . . . . . . . . . . . . . 202

Local Tool verification with "4 points method" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205REMOTE TOOL Automatic Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Tools needed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207Tool with known dimensions mounted on Robot Flange . . . . . . . . . . . . . . . . . . . . . . . .207

General characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207

UFRAME automatic calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207


Summary

Needed Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Tool with known dimensions mounted on Robot Flange . . . . . . . . . . . . . . . . . . . . . . . . . .2083 Reference Points (ORIGIN, Xpos and XYpos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208

General characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208REMOTE UFRAME automatic calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Needed Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214Tool with known dimensions mounted onto the Robot Flange . . . . . . . . . . . . . . . . . . . .2143 reference points (ORIGIN, Xpos and XYpos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214

General characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215

BASE automatic calculation for POSITIONERS (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Tools required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Tool of known dimensions mounted on the robot flange . . . . . . . . . . . . . . . . . . . . . . . . . .2203 reference points (P1, P2, P3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220

General characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Payload identification (optional function) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Requirements to modify Payload identification programs . . . . . . . . . . . . . . . . . . . . . . . . .230Activation and execution of the Payload identification procedure . . . . . . . . . . . . . . . . . . .231Software to validate the payload (SMART Payload) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239

18. INTERFERENCE REGIONS (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . ..240

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Regions types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240Cartesian Forbidden Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240Cartesian Monitored Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Joint Forbidden Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Joint Monitored Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Regions Shape and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Cartesian Regions shape and definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242Cylinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243

Joint Regions shape and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

IR_LIB library to support Interference Regions creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Sample program for Cartesian Interference Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Sample program for a Joint Interference Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

19. AXES PURSUIT (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..249

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Axes Pursuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Error handling when Axes Pursuit functionality is active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250


Configuring the software option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Example of PDL2 statements for configuring the Axes Pursuit functionality . . . . . . . . . . . . 250


00/0000

Preface

PREFACE

– Symbols used in the manual

– Reference documents

– Modification History.

Symbols used in the manual

The symbols for WARNING, CAUTION and NOTES are indicated below together with their significance.

This symbol indicates operating procedures, technical information and precautions that if ignored and/or are not performed correctly could cause injuries.

This symbol indicates operating procedures, technical information and precautions that if ignored and/or are not performed correctly could cause damage to the equipment.

This symbol indicates operating procedures, technical information and precautions that it are important to highlight.

10HS-0-0-0-mot_01.fm

04/0711

Preface

Reference documents

This document refers to the C5G Control Unit.

The complete set of manuals for the C5G consists of:

These manuals are to be integrated with the following documents:

Comau C5G Control Unit – Technical Specifications– Transport and installation– C5G Control Unit Use.

Comau Robot – Technical Specifications– Transport and installation– Maintenance

Programming – PDL2 Programming Language – VP2 - Visual PDL2– Motion programming

Applications – According to the required type of application.

11HS-0-0-0-mot_01.fm

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_SETProgram 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.

12HS-0-0-0-mot_01.fm

04/0711

General Safety Precautions

1. GENERAL SAFETY PRECAUTIONS

This specification deals with the following topics:

– Responsibilities

– Safety Precautions.

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.

– The application of these Safety Precautions is the responsibility of the persons assigned to direct / supervise the activities indicated in the Applicability sectionally are to make sure that the Authorised Personnel is aware of and scrupulously follow the precautions contained in this document as well as the Safety Standards in addition to the Safety Standards in force in the country in which it is installed.

– The non-observance of the Safety Standards could cause injuries to the operators and damage the Robot System (Robot and Control System).

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.

The installation shall be made by qualified installation Personnel and should conform to all national and local codes.

13ge-0-0-0_01.FM

00/0510


1.2 Safety Precautions

1.2.1 Purpose

These safety precautions are aimed to define the behaviour and rules to be observed when performing the activities listed in the Applicability section.

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 AreaThe protected area is the zone confined by the safety barriers and to be used for the installation and operation of the robot

Authorised PersonnelAuthorised 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.

Installation and Putting into ServiceThe installation is intended as the mechanical, electrical and software integration of the Robot and Control System in any environment that requires controlled movement of robot axes, in compliance with the safety requirements of the country where the system is installed.

Programming ModeOperating 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.

Auto / Remote Automatic ModeOperating mode in which the robot autonomously executes the programmed cycle at the work speed, with the operators outside the protected area, with the safety barriers closed and the safety circuit activated, with local (located outside the protected area) or remote start/stop.

Maintenance and RepairsMaintenance and repairs are activities that involve periodical checking and / or replacement (mechanical, electrical, software) of Robot and Control System parts or components, and trouble shooting, that terminates when the Robot and Control System has been reset to its original project functional condition.

14ge-0-0-0_01.FM

00/0510


Putting Out of Service and DismantlingPutting out of service defines the activities involved in the mechanical and electrical removal of the Robot and Control System from a production unit or from an environment in which it was under study.Dismantling consists of the demolition and dismantling of the components that make up the Robot and Control System.

IntegratorThe integrator is the professional expert responsible for the installation and putting into service of the Robot and Control System.

Incorrect UseIncorrect 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

15ge-0-0-0_01.FM

00/0510


1.2.4 Operating Modes

Installation and Putting into Service

– Putting into service is only possible when the Robot and Control System has been correctly and completely installed.

– The system installation and putting into service is exclusively the task of the authorised personnel.

– The system installation and putting into service is only permitted inside a protected area of an adequate size to house the robot and the fixtures it is outfitted with, without passing beyond the safety barriers. It is also necessary to check that under normal robot movement conditions there is no collision with parts inside the protected area (structural columns, power supply lines, etc.) or with the barriers. If necessary, limit the robot working areas with mechanical hard stop (see optional assemblies).

– Any fixed robot control protections are to be located outside the protected area and in a point where there is a full view of the robot movements.

– The robot installation area is to be as free as possible from materials that could impede or limit visibility.

– During installation the robot and the Control Unit are to be handled as described in the product Technical Documentation; if lifting is necessary, check that the eye-bolts are fixed securely and use only adequate slings and equipment.

– Secure the robot to the support, with all the bolts and pins foreseen, tightened to the torque indicated in the product Technical Documentation.

– If present, remove the fastening brackets from the axes and check that the fixing of the robot fixture is secured correctly.

– Check that the robot guards are correctly secured and that there are no moving or loose parts. Check that the Control Unit components are intact.

– If applicable, connect the robot pneumatic system to the air distribution line paying attention to set the system to the specified pressure value: a wrong setting of the pressure system influences correct robot movement.

– Install filters on the pneumatic system to collect any condensation.

– Install the Control Unit outside the protected area: the Control Unit is not to be used to form part of the fencing.

– Check that the voltage value of the mains is consistent with that indicated on the plate of the Control Unit.

– Before electrically connecting the Control Unit, check that the circuit breaker on the mains is locked in open position.

– 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.

16ge-0-0-0_01.FM

00/0510


– 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.

– 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 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.

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.

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.

17ge-0-0-0_01.FM

00/0510


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.

18ge-0-0-0_01.FM

00/0510


Auto / Remote Automatic Mode

– The activation of the automatic operation (AUTO and REMOTE states) is only to be executed with the Robot System (Robot and Control System) integrated inside an area with safety barriers properly interlocked, as specified by Safety Standards currently in force in the Country where the installation takes place.

– Before starting the automatic mode the operator is to check the Robot and Control System and the protected area to make sure there are no potentially hazardous irregular conditions.

– The operator can only activate automatic operation after having checked:• that the Robot and Control System is not in maintenance or being repaired;• the safety barriers are correctly positioned;• that there is nobody inside the protected area;• that the Control Unit doors are closed and locked;• that the safety devices (emergency stop, safety barrier devices) are

functioning;

– Special attention is to be paid when selecting the automatic-remote mode, where the line PLC can perform automatic operations to switch on motors and start the program.

Robot axes release

– In the absence of motive power, the robot axes movement is possible by means of optional release devices and suitable lifting devices. Such devices only enable the brake deactivation of each axis. In this case, all the system safety devices (including the emergency stop and the enable button) are cut out; also the robot axes can move upwards or downwards because of the force generated by the balancing system, or the force of gravity.

– 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.

Maintenance and Repairs

– When assembled in COMAU Robotics & Service, the robot is supplied with lubricant that does not contain substances harmful to health, however, in some cases, repeated and prolonged exposure to the product could cause skin irritation, or if swallowed, indisposition. First Aid. Contact with the eyes or the skin: wash the contaminated zones with abundant water; if the irritation persists, consult a doctor. If swallowed, do not provoke vomiting or take anything by mouth, see a doctor as soon as possible.

Before using the manual release devices, it is strongly recommended to sling the robot, or hook to an overhead travelling crane.

19ge-0-0-0_01.FM

00/0510


– Maintenance, trouble-shooting and repairs are only to be carried out by authorised personnel.

– When carrying out maintenance and repairs, the specific warning sign is to be placed on the control panel of the Control Unit, stating that maintenance is in progress and it is only to be removed after the operation has been completely finished - even if it should be temporarily suspended.

– Maintenance operations and replacement of components or the Control Unit are to be carried out with the main switch in open position and locked with a padlock.

– Even if the Control Unit is not powered (main switch open), there may be interconnected voltages coming from connections to peripheral units or external power sources (e.g. 24 Vdc inputs/outputs). Cut out external sources when operating on parts of the system that are involved.

– Removal of panels, protection shields, grids, etc. is only allowed with the main switch open and padlocked.

– Faulty components are to be replaced with others having the same code, or equivalent components defined by COMAU Robotics & Service.

– Trouble-shooting and maintenance activities are to be executed, when possible, outside the protected area.

– Trouble-shooting executed on the control is to be carried out, when possible without power supply.

– Should it be necessary, during trouble-shooting, to intervene with the Control Unit powered, all the precautions specified by Safety Standards are to be observed when operating with hazardous voltages present.

– Trouble-shooting on the robot is to be carried out with the power supply cut out (Drive off).

– At the end of the maintenance and trouble-shooting operations, all deactivated safety devices are to be reset (panels, protection shields, interlocks, etc.).

– Maintenance, repairs and trouble-shooting operations are to be concluded checking the correct operation of the Robot System (Robot and Control System)and all the safety devices, executed from outside the protected area.

– When loading the software (for example after replacing electronic boards) the original software handed over by COMAU Robotics & Service is to be used. Scrupulously follow the system software loading procedure described in the specific product Technical Documentation; after loading always run a test cycle to make sure, remaining outside the protected area

– Disassembly of robot components (motors, balancing cylinders, etc.) may cause uncontrolled movements of the axes in any direction: before starting a disassembly procedure, consult the warning plates applied to the robot and the Technical Documentation supplied.

– It is strictly forbidden to remove the protective covering of the robot springs.

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.

20ge-0-0-0_01.FM

00/0510


Putting Out of Service and Dismantling

– Putting out of service and dismantling the Robot and Control System is only to be carried out by Authorised Personnel.

– Bring the robot to transport position and fit the axis clamping brackets (where applicable) consulting the plate applied on the robot and the robot Technical Documentation.

– Before stating to put out of service, the mains voltage to the Control Unit must be cut out (switch off the circuit breaker on the mains distribution line and lock it in open position).

– After using the specific instrument to check there is no voltage on the terminals, disconnect the power supply cable from the circuit breaker on the distribution line, first disconnecting the power conductors, then the earth. Disconnect the power supply cable from the Control Unit and remove it.

– First disconnect the connection cables between the robot and the Control Unit, then the earth cable.

– If present, disconnect the robot pneumatic system from the air distribution line.

– Check that the robot is properly balanced and if necessary sling it correctly, then remove the robot securing bolts from the support.

– Remove the robot and the Control Unit from the work area, applying the rules indicated in the products Technical Documentation; if lifting is necessary, check the correct fastening of the eye-bolts and use appropriate slings and equipment only.

– Before starting dismantling operations (disassembly, demolition and disposal) of the Robot and Control System components, contact COMAU Robotics & Service, or one of its branches, who will indicate, according to the type of robot and Control Unit, the operating methods in accordance with safety principles and safeguarding the environment.

– The waste disposal operations are to be carried out complying with the legislation of the country where the Robot and Control System is installed.

21ge-0-0-0_01.FM

00/0510


1.2.5 Performance

Before installing the robot system the user must consider the following performances:

– Stop distances (threshold values)

– Mission time (typ. case).

Stop distances (threshold values)

– As for the stop distance threshold values for each robot type, please turn to the COMAU Robotics & Service Dept.

– Example: Considering the robot in automatic mode, in conditions of maximum extension, maximum load and maximum speed, when the stop pushbutton is pressed (red mushroom head pushbutton on WiTP) an NJ 370-2.7 Robot will stop completely in approx. 85° of motion, equivalent to approx. 3000 mm displacement measured on the TCP flange. Under these conditions indicated, the stoppage time of the NJ 370-2.7 Robot is 1.5 seconds.

– Considering the robot in programming mode (T1), when the stop pushbutton is pressed (red mushroom head pushbutton on WiTP) an NJ 370-2.7 Robot will stop completely in approx. 0.5 seconds.

Mission time (typ. case)

– We remind the user that the safety system efficiency cover time is equal to 20 years (mission time of safety-related parts of control systems (SRP/CS), according to norm EN ISO 13849-1).

22ge-0-0-0_01.FM

00/0510

System operating modes and states

2. SYSTEM OPERATING MODES AND STATES

2.1 ForewordThis chapter describes the following:

– System operating modes

– System states

– Stand-by function

2.2 System operating modesThe C5G Robot Control Unit can operate in three different modes that can be selected through the modal selector switch on the Teach Pendant:

– programming (T1),

– local automatic (AUTO) and

– remote automatic (REMOTE).

Local automatic mode (AUTO) is used to execute production programs; as they contain instructions for the robot movement, to be able to start it is necessary to press the START key on the Teach Pendant. The status selector switch must be set on AUTO.Active TOOL, BASE and FRAME cannot be changed when working in AUTO.

The Automatic remote mode (REMOTE) is the same as Automatic local mode (AUTO), but the commands (for example the start) are sent from a remote device (for example a PLC).The state selector switch must be set to the REMOTE position. Active TOOL, BASE and FRAME cannot be changed when working in REMOTE.

The Programming mode (T1) is used to create and verify programs The robot moves, for safety reasons, are run at a lower speed than in automatic mode (maximum robot speed allowed in programming is 250 mm/s on the flange centre).

23HS-0-C5E-USO_32.fm

00/0310


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.

2.3 System statesMainly, the system status depends on:

– the status selector switch

– the DRIVE ON, DRIVE OFF and HOLD keys on the Teach Pendant

– system alarm

Transition from one state of the system to another is also influenced by the enable device on the Teach Pendant.

The Control Unit may be in one of these conditions:

– HOLD status: the robot is gradually decelerated until the stopping point is reached; movement is suspended and also the execution of the movement program (holdable). When there are all the necessary conditions to exit from the HOLDstatus, the system returns to the previous state (programming or automatic), but to continue to execute the movement program it is necessary to press START.

– AUTO status: this is usually used to execute production programs that control the robot movements (status selector switch positioned on AUTO or REMOTE or T2).Active TOOL, BASE and FRAME cannot be changed when working in AUTO or REMOTE.

– PROGR status: the robot can be moved manually using the jog keys or executing program instructions (from editor environment or by EXECUTE). In the latter case, in order that the movement be executed, the START key and the enabling button have to be kept pressed.

If the controlled stop function class 1 (EN 60204-1) is active, the power cut-out (opening


00/0310


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.

Fig. 2.1 - Simplified diagram of the system states

1. Status selector switch on T1 + HOLD released 2. HOLD or DRIVES OFF or selector switch change3. HOLD or DRIVES OFF or selector switch change4. Status selector switch on AUTO or REMOTE + HOLD released

Note: To perform transient 4 also the enabling device key has to be pressed

2.3.1 HOLD status

The safety rules to be complied to when operating with the Control Unit have been studied so that the system enters the HOLD status every time a change is made in the operating mode, passing for instance from LOCAL to PROGR mode.

To exit from the HOLD status to enable a certain operating mode, there must be all the required safety conditions. A typical example is when the operator brings the status selector switch to PROGR to work near the robot, holding the Teach Pendant to carry out learning operations for the points.

In PROGR, exiting from HOLD can be obtained by pressing START, this is controlled by the system and therefore is active when an instruction or a movement program is executed. When the START key is released again the system returns to HOLD status.

When entering the HOLD status, the corresponding HOLD key on the Teach Pendant


00/0310


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).

2.3.2 AUTO status

To have the system in AUTO status, the status selector switch on the Robot Control Cabinet must be set on AUTO or REMOTE. Active TOOL, BASE and FRAME cannot be changed when working in AUTO or REMOTE.

In AUTO status, to start programs ready for execution, press the START key on the Teach Pendant or activate the START input from remote device.

Conditions that change the system status from AUTO to HOLD are:

– status selector switch changed to another position;

– DRIVE OFF or HOLD pressed;

– system alarm.

To return to AUTO, bring the selector switch back to the required position, and press again the previous buttons (DRIVE OFF and/or HOLD). To continue the movement program execution, press START after making sure that the drives are powered (DRIVE

2.3.3 PROGR status

PROGR status is active when:

– the status selector switch is set to T1.

In this state the robot can be moved manually, using the jog keys on the Teach Pendant. It is also possible to run programs from IDE environment (see IDE Page in C5G Control Unit Use manual) to check that they are correct and if necessary make changes. Movements are at slow speed.

2.3.4 ALARM status

The system enters ALARM status when an alarm is generated. An error message is displayed on the second status line of the system screen and the associated LED, next to the ALARM key on the Teach Pendant, lights up.

There are different conditions that can generate an alarm and the action to be taken to exit from ALARM status and bring the system back to the previous state vary according to how serious the error is.

2.4 Stand-by functionThe purpose of the Stand-by function is to cut down the current consumption when the robot is stationary.

The function is automatically activated when the Control Unit is in local automatic or remote automatic mode and after the robot has remained stationary for a time defined by variable $TUNE [27];this function activates the motor brakes to keep the static position of the robot. The value of variable $TUNE [27], set by COMAU, is 120 seconds; if this variable is set to 0 the function is deactivated.


00/0310


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 Motionpage on the Teach Pendant.

The safety precautions are to be scrupulously observed regarding this operating condition of the Controller.


00/0310

Turn-Set and Calibration - basic concepts

3. TURN-SET AND CALIBRATION - BASIC CONCEPTS

3.1 ForewordThe 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


00/0610


(excluded) and +0.5 (included). The calibration constant described in variable $CAL_DATA can be read on the Teach Pendant, SETUP Page, Calib. subpage.

– CALIBRATION ASCII FILE: the calibration file UD:\SYS\<$SYS_ID>_CAL<num_arm>.PDL (where $SYS_ID indicates the system identification, for example NJ4_001) is an ASCII file with syntax of a PDL2 file, where the calibration constants ($CAL_DATA[n]) and other typical data of the robot are stored.

– NVRAM: the memory used to save the characteristic information of the robot associated to the Control Unit, the calibration constants and the length of the levers. It is on the CPU board of the Controller.

3.3 Turn-setThe 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

3.3.1 Turn-set on system calibration position

Enables the initialising of the number of transducer turns of the individual robot axes, in the system calibration position (calibration position pre-defined by COMAU Robotics).

For further information see System calibration ($CAL_SYS).

3.3.2 Turn-set on user calibration position

Enables the initialising of the number of transducer turns of the individual robot axes, in the user calibration position (“out of range” position defined by the user).

For further information see User calibration ($CAL_USER).

3.3.3 Turn-set for robot axes with multi-turn stroke

With robot axes that are able to execute the multi-turn stroke, it may happen that when carrying out the TURN SET procedure, the mechanical calibration notches are misaligned (this condition can occur when the robot axis, having made one or more


00/0610


complete rotations, positions in a mechanical turn that is different to that of the original calibration).

Fig. 3.1 - Axis Positioning Error in TURN SET

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 CalibrationThe 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.


00/0610


The notches on the individual axes make it possible to execute future turn-set operations on a robot that has already been installed.

The recovery of the calibration (executed by COMAU), if necessary, is to be executed when first putting the robot into operation.

The basic concepts are described below for:

– System calibration

– User calibration

3.4.1 System calibration

To initialise the robot axis values in the system calibration position (calibration position predefined by COMAU Robotics - $CAL_SYS).

3.4.2 User calibration

User calibration defines a new calibration position that is different to that of the system.

This type of calibration (commonly called out-of-range calibration) can be used when the system position is difficult to reach once the robot is inserted in the final application, and therefore it becomes necessary to define a different calibration position, called user calibration position ($CAL_USER).

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.

To determine the correct calibration position, special equipment has to be used (dial gauges, supports, etc.) to determine with the necessary precision the position of each individual axis.

It is the responsibility of the user to provide the appropriate instruments and to check the correct positioning of the robot in any user re-calibrations, especially regarding the arrangement of the locating notches.


00/0610


Fig. 3.2 - Summary of Calibration and Turn-Set Operations

SAVING CALIBRATION CONSTANTS

1. NVRAM 2. UD:\SYS in .C5G file3. UD:\SYS in the calibration ASCII file ($<SYS_ID>_CAL<num_arm>.PDL)4. Hard copy


00/0610

Robot motion in Programming mode

4. ROBOT MOTION IN PROGRAMMING MODE

4.1 IntroductionIn 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).

A detailed description follows about :

– Reference frames

– System reference frames

– Manual motion

– Manual motion in WRIST_JNT mode

– Manual motion of a single arm system

– Manual motion of auxiliary axes, slides and rotating columns

– Manual motion with Controller multi-arm configuration

– Motion instruction in programming status

4.2 Reference framesA Cartesian reference system, or reference set of three, is a geometrical concept to enable the representation of an object in space. For example, the corner of a table may be chosen as a reference system to represent the table. The same method can be applied for a book lying on a table, as for a weld gun mounted on the flange of a robot.

A co-ordinates conversion describes the position of one reference system in relation to another. This is described as a POSITION variable. For example, if a table is located in a room, its position in relation to the room is indicated by POSITION p_table, that describes the co-ordinates conversion between the two reference systems. The co-ordinates conversion can also be used to calculate the position of an object in relation to different reference systems. For example, a book with a position in relation to the corner of the table is p_book and will have the position (p_table:p_book) in relation to the corner of the room. The sign (:) indicates the relevant position operation, and makes it possible to compose the effect of various co-ordinate conversions. For further information, see the PDL2 Programming Language Manual.

4.3 System reference framesThe Controller has three system variables ($BASE, $TOOL and $UFRAME) that permit the description of the main co-ordinate conversions. Before starting to explain these conversions, it is necessary to define some reference frames.

For any further information and/or explanations, see the relevant chapter Use of the Teach Pendant, in the C5G Control Unit Use manual.


00/0210


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).

Fig. 4.1 - System reference frame and movement of the co-ordinates

1. Flange frame2. Tool frame3. Recorded position4. User frame5. Base frame6. 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.

World frame – Workshop reference frame in relation to where the machines are positioned

Base frame – frame that indicates the robot base

User frame – frame that indicates the workpiece

Flange frame – frame that indicates the robot flange

TCP frame – frame that indicates the tool tip

Remember that, changing $TOOL or $BASE or $UFRAME, the same position (POS) corresponds to a different actual position of the robot!


00/0210


4.4 Manual motionThe manual movement of the arm is necessary in certain circumstances, among which when learning (recording) the positions or during maintenance of the tool fitted on the arm. The black keys on the Teach Pendant are used for manual motion. To be able to make the move it is necessary to have the system in programming status, i.e. with the status selector switch in position T1, and the Enabling Device pressed.

Before starting to move, the movement mode and the speed should be selected.From the Motion page of the Teach Pendant, Basic sub-page (COORD field), one of the following modes can be selected to move the arm:

– JOINT - joints mode. The ‘+/-’ keys are associated to each of the axes of the selected arm; the keys associated to any auxiliary axes present follow those of the arm (typically they are keys 7 and 8 (‘+/-’)). When one of the keys is pressed, the corresponding axis moves in the positive or the negative direction, according to the directions indicated on the plate on the arm.

– BASE - linear movement mode according to the tool reference x,y,z frame (or TCP frame). The first three '+/-' keys (on the left) are used for linear motion in the direction of the three axes of the world reference system); the next three '+/-' keys (on the right) are for the rotation of the tool around the same axes keeping the TCP position unchanged.. It must be remembered that the world frame is not defined directly by any system variable; in fact, it is the robot base that is represented in relation to the world by means of the $BASE variable.

– TOOL - linear movement mode according to the tool reference x,y,z frame (or TCP frame). The first three ‘+/-’ keys allow linear movement in the direction, of the three axes of the tool reference system (defined by the $TOOL variable); the next three ‘+/-’ keys are for the tool rotation around the same axes keeping the TCP position unchanged (tool working point).

– UFRAME - linear movement mode according to the user reference x,y,z frame (for example the frame that describes the workpiece). The first three ‘+/-’ keys allow linear movement in the direction of the three axes of the user reference system (defined by the $UFRAME variable); the next three ‘+/-’ keys are for the tool rotation around the same axes keeping the TCP position unchanged.

The speed of the manual motion can be selected with the +% and -% keys that act on a percentage value shown on the Teach Pendant status bar. This percentage value is called general override and does not only act on the manual movement speed, but on all types of movements, both in programming and in automatic mode.

The TCP movement speed, during manual movements, is always lower than the safety speed of 250 mm/s also in joints mode. In the Cartesian modes (Tool, Uframe, Base) the maximum speed that can be reached is limited by the system variable $JOG_SPD_OVR that usually has values equal to 50% (i.e. half the safety speed). This value can be changed to adapt the standard manual movement speed to the individual programming requirements.

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.


00/0210


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.

4.5 Manual motion in WRIST_JNT modeIn Cartesian mode movement (Tol, Usr, Bas) of certain types of arms, it is more convenient to change the orientation of the tool to a mode that does not rotate around a Cartesian axis, but moves the axes of the robot wrist directly (the wrist axes, for a 6-axis robot are the last three). This is useful for machines with less than 6 axes since their capacity to rotate the tool is limited and it is not possible to obtain exactly what is required. It is also useful when passing through singularity point. For some types of robot the WRIST_JNT mode may not exist.

The mode on the Teach Pendant, can be selected from the Motion page, Basicsub-page, COORD field. The WRIST_JOINT mode changes the behaviour of the BASE, TOOL and UFRAME modes; the corresponding texts change to WR-BASE, WR-TOOL and WR-UFRAME. The Joint mode remains unchanged.

The difference in the robot movements is most evident regarding the keys to change the geometry, that is, keys 4+/-, 5+/- e 6+/-. In WR-BASE, WR-TOOL e WR-UFRAME modes, these keys are associated directly to each wrist axis and when one of these keys is pressed the corresponding axis is moved leaving the positions of the other wrist axes unchanged. This operation, however holds the TCP position because the first three axes move to offset the change in orientation. It is to be noted that if the robot has only 2 wrist axes (for example 4 and 5), only keys 4+/- and 5+/-, can be enabled, whereas only key 4 will be enabled for a four-axis robot. For the 1X+/-, 2Y+/- and 3Z+/- keys the difference is less obvious: the movement is linear in the direction required but the geometry of the tool is not constant along the path since the wrist axes are not moved.

4.6 Manual motion of a single arm systemTo execute the manual movement of a single arm it is sufficient to set the status selector switch on T1, choose the most appropriate mode and press the ‘+/-’ keys, keeping the Enabling Device on the Teach Pendant pressed.

4.7 Manual motion of auxiliary axes, slides and rotating columnsThe auxiliary axes can be added to an Arm in order to move different types of positioners. Another example of auxiliary axis is the motor driven spot welding gun.An example of an integrated auxiliary axes group is a roto-translating column or a gantry.

Jogging an auxiliary axis is usually only possible in joint mode (JOINT) using the corresponding AUX A/AUX B + e - keys.

The manual movement of an auxiliary axis is usually only possible in joint mode (JOINT) using the corresponding AUX A/AUX B + e - keys. To associate the auxiliary axes to AUX A and AUX B keys, it is needed to open the Motion Page - subpage COOP - section AUX Jog, on the Teach Pendant.


00/0210


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).

4.8 Manual motion with Controller multi-arm configurationIn the case of Controller multi-arm configuration, it is necessary to select the arm to be moved using the Motion page on the Teach Pendant and checking the current value on the status bar.

It is also possible to activate two arms at the same time that belong to two different machines. To do this it is necessary to be in DRIVE OFF status and change the current arm on the Motion page, Basic sub-page (Arm field).

For manual movement of integrated arms (a particular application of multi-arm system) see the specific Chap. Motion Control.

4.9 Motion instruction in programming statusTo program robot movements requires a certain knowledge of the C5G system and the PDL2 programming language. However, before creating an actual program, some simple moves can be made with the immediate execution of an instruction. To do this, the system has to be in programming state with the EXECUTE command called (from Service page of the Teach Pendant) that allows the immediate execution of an instruction.

In its most simple form, the instruction consists of the key words MOVE TO followed by the destination position. The most useful move instruction in the first stages of use is:

MOVE TO $CAL_SYS

This produces a movement of each axis to its calibration position. In its more complete form the arm to be moved, the type of path and the destination can be selected.

The arm is assigned by the key word ARM (num_arm) that is placed immediately after the word MOVE. The definition can be omitted if the system has only one arm (for example an NJ4 robot (6 axes) is one arm only) or if the default arm predefined by the system is to be moved.

The type of path may be joints, linear or circular and is described by the predefined

For further information, please see C5G Control Unit Use - chp. Motion Page - par. COOP (optional), AUX JOG section).

Note that when teaching positions for auxiliary axes, it is recommended to use XTNDPOS.


00/0210


constants JOINT, LINEAR and CIRCULAR respectively (see the Chap. Motion Controlfor 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 theChap. 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 thePDL2 Programming Language Manual).

MOVE LINEAR TO POS(100,200,300,0,0,0,’’) linear movement of pre-defined arm on a point of Cartesian co-ordinates x=100, y=200 and z=300 and the frame of the tool with the same orientation as the user frame

MOVE JOINT TO POS(0,0,0,0,180,0,’’) joints type movement of the predefined arm on a point of Cartesian co-ordinates x=0, y=0 and z=0 and axis z of the tool frame facing the opposite direction to the z of the user reference

MOVE JOINT TO {0,0,0,0,0,0} joints type movement of the first six axes of the default arm on the zero positions

MOVE JOINT TO {, , , , ,90} movement of axis 6 only of the default arm on the position of 90 degrees

MOVE LINEAR TO {45} linear movement that brings the arm to a position that differs from the initial position for axis 1 only, that is brought to 45 degrees. During the linear movement of the TCP all the axes of the arm can move

MOVE ARM[1] LINEAR TO POS(100,100,100,0,0,0,’’) linear movement of arm 1 that takes the TCP to a certain Cartesian position in relation to the user frame

MOVE ARM[2] JOINT TO POS(0,0,0,0,180,0,’’) joints movement of arm 2 that brings the TCP to a certain Cartesian position in relation to the user frame

MOVE ARM[1] LINEAR TO {0,0,0, , ,} linear movement that brings the first arm to a Cartesian position where the first three axes have no value, whereas the wrist axes return to the initial position. During the TCP linear movement all the axes of the arm can move

MOVE ARM[2] JOINT TO {-90} movement of second arm that moves only axis 1 to the position of 90 degrees in negative direction

MOVE CIRCULAR TO POS(100,100,0,0,0,0,’’) VIA POS(0,200,0,0,0,0,’’)

movement of pre-defined arm that joins the starting point to POS (100,100,0,0,0,0,’’) with a circumference that passes through POS (0,200,0,0,0,0,’’)


00/0210


Before executing a movement it is better to check the correct definition of the reference systems, especially the declarations of the tool frame and the user reference ($TOOL, $BASE and $UFRAME). These declarations can only be ignored in the case of joint movements on joint points, for example MOVE JOINT TO $CAL_SYS now MOVE TO {0,90,-100,20,20,200}, or MOVE TO JOINTPOS. In all other cases the consequences could be dangerous with risks for the personnel and for the equipment. In particular if the description of the tool is not correct (wrong $TOOL) the TCP will not reach the required point, nor will it execute a correct linear or circular path. Regarding the description of the user frame ($UFRAME) it is important to check that, at the moment the movement is executed, this is identical to that which was active when the point was stored. Otherwise the positioning will be different to that stored. However, the same paths can be executed again with different $UFRAME values, since this performance is necessary for some applications that require a specific shifting of the whole program inside the work space (palletizing applications).It is also necessary to always check the correct definition of the load used, regarding the weight, centre of gravity and inertia. This data can be automatically calculated by the Controller, given a Tool (also a Tool plus a part), applying the Payload identification (optional function) included in the TO_SET application (that can be activated from the Teach Pendant, Setup page, ToolFrame sub-page).The verification checks that the recorded load data corresponds with the $TOOL_MASS, $TOOL_CNTR and tool $TOOL_INERTIA[1..6] variables currently in use.


00/0210

Motion Control

5. MOTION CONTROL

5.1 OverviewThis 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.

5.2 Frames of ReferenceFor our purposes, the following terminology should be defined.

Cartesian frame of reference is a geometrical concept that represents an object positioned in space. For example, the corner of a table can be the frame of reference that represents the table. The same can be done with a book, as well as with a welding gun mounted on the robot flange.

A Coordinate transformation represents the position of one frame of reference with respect to another. It is described by a POSITION variable. For example, if a table is located in a room then the position of the table with respect to the room is expressed by the POSITION p_table, which describes the coordinate transformation between the two frames of reference. The coordinate transformation can be used to compute the position of an object with respect to another coordinate frame. For example, a book whose position with respect to the table corner is p_book, is located at the position (p_table:p_book) with respect to the corner of the room. The (:) is the relative position operator used to compose the effect of different coordinate transformations. See Data Representation chapter of PDL2 Programming Language manual for further information.

40pr-0-0-gpr_04.fm

00/0210

Motion Control

5.2.1 System Frame of Reference

C5G Controller Unit has got three system variables ($BASE, $TOOL and $UFRAME) which allow to describe the coordinates tranformations. Before describing the meaning of such transformations, it is necessary to define some frames of reference.

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.

Fig. 5.1 - System Frames of Reference and Coordinates Transformation

1 - Flange frame 2 - Tool frame 3 - Recorded position4 - User frame 5 - Base frame 6 - Boundary frame

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:

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

41pr-0-0-gpr_04.fm

00/0210

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.

5.2.2 Base System of Reference definition

The $BASE predefined variable describes the position of the base of the robot in relation to the external world.

It is useful to offset repositioning of the robot inside the cell or to repeat the same program on the same part but with different robots. Also, a well-defined base reference simplifies calculation of points (POSITION) during off-line programming.

To properly calculate $BASE, the POS_FRAME function can be used as follows (the program must be run in a programming environment with Step mode set to Statement):

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

5.2.3 Flange Tooling definition

Cartesian motions (straight lines for example) are defined for the TCP (tool centre point) only. For example, when a straight line motion of the TCP involves large changes in tool orientation during the motion, the tool flange does not necessarily move in a straight line. Therefore, in order for Cartesian motions to work properly, the position (both location and orientation) of the TCP, with respect to the tool flange, must be properly defined.

Proper definition of the TCP orientation is also necessary for the approach vector used in MOVE NEAR and MOVE AWAY statements to be properly defined.

The position of the TCP is defined by defining a transformation from the tool flange frame of reference to the TCP frame of reference. The predefined variable, $TOOL, defines this transformation. The position of flange frame of reference is fixed for each model of robot and is documented in the hardware manual for the specific robot. It is the operators responsibility to define $TOOL for the specific tooling to be mounted on the flange.

Two sets of tool parameters define the $TOOL transformation:

42pr-0-0-gpr_04.fm

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.

5.2.3.1 TCP Offset definition

The offset for tool dimensions can be measured on the arm itself or calculated theoretically based on the tool design. The parameters can vary according to the tool assembly position in that they must be defined according to the tool z axis (ref. z Tool), commonly referred to as the approach vector.

To measure the tool dimensions, proceed as follows:

a. Begin with no tools on the robot. Assign zero values to all six tool parameters of $TOOL.

$TOOL := POS (0, 0, 0, 0, 0, 0, ‘ ‘)

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.

f. Assign measured values to $TOOL using a PDL2 assignment statement:

$TOOL := POS (x, y, z, e1, e2, e3, ‘ ‘ )

Fig. 5.2 - Known position

43pr-0-0-gpr_04.fm

00/0210

Motion Control

5.2.3.2 Calculating the Rotation Angles

Rotation values are independent from offset values and must be calculated after the offset values have been assigned. Depending on the application, the rotation values can be omitted. In this case, tool orientation will be along an axis parallel to the flange axis that starts at the TCP. The rotation values are positive for counterclockwise rotation with the rotation axis pointed toward the observer. These values can be calculated using one of the two methods described below.

5.2.3.2.1 FIRST METHOD

Calculate three rotations that will align the flange z axis with the tool z axis. The rotations, which correspond to Euler angles, are designated (e1) rotation around z, (e2) rotation around y, and (e3) rotation around the new z.

Note that:

– it is not possible to rotate axis x;

– rotation around y must be between 0 and 180 degrees;

– rotation around z must be between -180 and 180 degrees.

Assign the rotation values to $TOOL using the PDL2 assignment statement: $TOOL := POS (x, y, z, e1, e2, e3, ‘ ‘)

Some example calculations follow. In the following diagrams, u indicates the tool z axis.

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.

The following rotations should be performed:

a. Rotate 90 degrees around axis z

44pr-0-0-gpr_04.fm

00/0210

Motion Control

b. Rotate 90 degrees around axis y.

c. Rotate 180 degrees around the new axis z.

The tool z axis (u) now coincides with the flange z axis. The rotation angles (e1, e2, e3) are (90, 90,180).

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).

45pr-0-0-gpr_04.fm

00/0210

Motion Control

5.2.3.2.2 SECOND METHOD

Use the three rotation controls on the teach pendant to move:

– the Tool z axis parallel and in accordance with the base z axis;

– the axis which is to become Tool axis x parallel and in accordance with the base x axis of the user frame.

After these two moves, the final Tool axis y is consequently parallel with the base y axis.

The angle parameters alpha, beta, epsilon can be read on the Teach Pendant Motion Page - Basic subpage - ARM_POS section (System Command: DAP).

Tool parameters will be given by:

– rotation 1 = 180 degrees - epsilon (-360 degrees);

– rotation 2 = beta;

– rotation 3 = 180 degrees - alfa (-360 degrees).(It is needed to add (-360 degrees) if the value of rotation exceeds 180 degrees).

The angle values to be assigned are obtained by rounding off those calculated (typically rounding off is to 0, 90, or 180 degrees).

5.2.3.3 User System of Reference definition

The $UFRAME predefined variable can be used to describe the position of the workpiece with respect to the world. It is useful to compensate the relocation of the workpiece or to execute the same program on workpieces in different positions. Besides a well defined user frame can simplify the computation of positions when doing an off-line.

To compute the correct value of $UFRAME, the POS_FRAME built-in can be used as follows (the program should be executed in the PROGRAM EDIT environment with the Step modality set to Statement):

PROGRAM setframeVAR corner, x, xy : POSITIONBEGIN

$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 TrajectoryIt 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

The TCP is calculated at the tool closing point. Any safety flange logically belongs to the tool and therefore increases the z offset.

46pr-0-0-gpr_04.fm

00/0210

Motion Control

interpolation to be used. It is a program-specific variable (one for each active program). The predefined constants JOINT, LINEAR, or CIRCULAR can be assigned to $MOVE_TYPE. The trajectory can be also expressed in the move statements by assigning the reserved words JOINT, LINEAR or CIRCULAR to the MOVE statement.

The trajectories can be classified as follows:

– joint trajectory: JOINT

– linear trajectory: LINEAR

– circular trajectory: CIRCULAR.

5.3.1 Joint Interpolation

During joint interpolation ($MOVE_TYPE := JOINT or MOVE JOINT TO), the joint angles of the arm are linearly interpolated from their initial to final values. All axes start moving at the same time and reach their destination at the same time. The path followed by the tool centre point (TCP) is not predictable, although it is repeatable.

Joint interpolated movements between two positions are always possible.

5.3.2 Linear Interpolation

During linear interpolation ($MOVE_TYPE := LINEAR or MOVE LINEAR TO), the TCP moves in a straight line from the initial position to the final position. The orientation of the tool also changes from the initial position to the final position according to the mode defined by the $ORNT_TYPE variable. This specific program variable can have the values of the following predefined constants: RS_WORLD, RS_TRAJ, EUL_WORLD, WRIST_JNT.

For further information refer to the par. 5.3.4 Orientation Evolution during Linear or Circular movements on page 47 section.

5.3.3 Circular Interpolation

During circular interpolation ($MOVE_TYPE := CIRCULAR or MOVE CIRCULAR TO), the TCP follows a circular arc from the initial position to the destination. An additional position, called the VIA position, must be specified to define the arc. Only the location component of the VIA position is used; its orientation does not affect the motion.

As for linear interpolation, the $ORNT_TYPE predefined variable indicates the type of evolution of attitude must be performed.

5.3.4 Orientation Evolution during Linear or Circular movements

The orientation of the tool during linear and circular movements evolves from the initial position to the final position in the manner indicated by the $ORNT_TYPE variable. Possible values of this specific variable of the program are as follows:

– RS_WORLD (two-angles related to the world frame)

Orientation interpolation is done by linearly interpolating the values of two rotation angles, tool rotation and tool spin. The tool rotation angle is the angle about the common normal between the beginning tool approach vector and the destination approach vector. The tool spin angle is the angle about the approach vector from the beginning position to the destination position. The evolution is related to the World frame independently from the trajectory.

RS_WORLD is the default value for $ORNT_TYPE.

47pr-0-0-gpr_04.fm

00/0210

Motion Control

– RS_TRAJ (two angles related to the trajectory)

Orientation interpolation is done in the same way than RS_WORLD but the rotation and spin angles are related to the trajectory. This is particularly useful during circular trajectory having an angle grater than 180 degrees when the user wants to maintain the tool orientation constant with respect to the trajectory. During linear motions the orientation evolution is the same than RS_WORLD.

– EUL_WORLD (three-angle)

Orientation interpolation is done by linearly interpolating the values of the three Euler angles of rotation, E1, E2, and E3.

– WRIST_JNT (wrist-joint)

Orientation interpolation is done by using a combination of joint and linear interpolation. This permits the tool to move along a straight line while the wrist joints are interpolated in joint coordinates. The starting and ending orientation will be used as taught, but because of the joint interpolation, the orientation during the movement is not predictable, although it is repeatable. For example, using either EUL_WORLD or RS_WORLD, if the beginning and ending orientations are the same, then the orientation of the tool will remain fixed during the motion. However, with WRIS_JNT orientation interpolation this is not guaranteed. However, WRIST_JNT orientation control allows for much smoother motion near wrist singularities.

5.3.5 Attitude Flags During Linear and Circular Movements

During Cartesian trajectories (LINEAR and CIRCULAR) the attitude flags of the starting and final points of a movement must correspond, otherwise the movement will not be executed. Attitude flags signify the S, E, W, A and B parts of a Cartesian position (see the PDL2 Programming Language Manual for further details).

– S indicates that the WCP (Wrist Center Point) is in the zone lying behind the plane defined by the first and the second axes.

– E indicates that the WCP is in the zone lying behind the extension of the second axis;

– W indicates that the value of the fifth axis is negative.

– A indicates that the TCP (Tool Center Point) is in the zone lying behind the extension of the second axis;

– B indicates that the TCP (Tool Center Point) is in the zone lying behind the plane defined by the first and the second axes.

The only exception to this is when passing over a singularity point, in which the W flag is reversed by the system software.

It is, however, possible to execute the movement even if the flags do not correspond: set the $CNFG_CARE predefined variable to FALSE to make the flag of the final point match that of the starting point.

This setting is mainly used when mixing movements that use JOINTPOS type variables and POSITION type variables with values that have been set directly from the PDL2 program and not taught using the REC key on the teach pendant.

If the starting point is a JOINTPOS, the value of the configuration string is unknown and it is therefore useful to set the $CNFG_CARE variable to FALSE.

48pr-0-0-gpr_04.fm

00/0210

Motion Control

5.3.6 Turn Flag and minimum path

Turn flags (T1, T2, T3, T4) are part of the configuration string and are associated with axes capable of performing multi-turns, i.e. that can rotate by more than 360 degrees ($STRK_END_P[axis] - $STRK_END_N[axis] > 360) (for further details also see the PDL2 Programming Language Manual).

A Cartesian trajectory (LINEAR or CIRCULAR) generally follows the shortest path for the joints and the configuration string of the final point that has been reached may therefore differ from that present in the movement instruction. If so, the system will execute the movement in any case, unless the predefined variable, $TURN_CARE, has been set to TRUE; in that case, an error message will indicate the difference in the number of turns.

POSITION type variables that were taught using a particular $UFRAME may have a different number of turns when the $UFRAME is changed. For instance, if a P0 point was taught with axis 4 at 170 degrees and P1 with axis 4 at 179 degrees, the number of turns will not be included in the position variables (configuration string empty ‘’‘’). However, if a slight change is made to $UFRAME, the joints associated with P0 and P1 may change. For example, P0 may now have axis 4 at 172 degrees and P1 have axis 4 at 181 degrees. In that case, the shortest path is from 172 to 181 degrees, but in order to move axis 4 to 181 degrees, position P1 should have flag T1:1. However, there is no turn flag in the P1 configuration string and therefore, in order to avoid an error on the LINEAR MOVE from P0 to P1 with a new $UFRAME, $TURN_CARE must be set to FALSE.

A joint trajectory (JOINT) or a Cartesian movement with WRIST_JNT evolution, effected on points declared as POSITIONs, sets a path that follows the evolution of the joints, without considering the shortest or longest route. To follow the shortest route (<180 degrees), set the $JNT_MTURN variable to FALSE.

Note that the $JNT_MTURN variable is ineffective in joint movements on points declared as JOINTPOS.

5.4 Position CheckingThere are two functions, called ON TRAJECTORY and ON POS, that can be used to verify the robot’s position in relation to the programmed trajectory or to predefined positions. This is mainly used when monitoring the line from external devices, such as a PLC. By means of appropriate calls to the built-in routines, ON_TRAJ_SET, ON_JNT_SET and ON_POS_SET, it is possible to define the bits of analogue ports (e.g. $WORD) that will be set to 1 when a predefined position is reached or during the robot movement along the programmed trajectory.

5.4.1 On Trajectory Function

This function, which is always enabled, is used to verify, at any time, whether the robot is on the trajectory programmed of the PDL2 program that is running.

$CRNT_DATA[arm].OT_POS indicates the robot’s position along the programmed trajectory. The $CRNT_DDTP[arm].OT_JNT variable includes information concerning any auxiliary axes that may be present. $CRNT_DATA[arm].OT_COARSE is TRUE when the robot is on the programmed trajectory and FALSE if that is not the case.

For safety reasons, the deviation between the current position of the robot and the $CRNT_DATA[arm].OT_POS position is calculated by taking into account the threshold

49pr-0-0-gpr_04.fm

00/0210

Motion Control

in millimeters in relation to the flange ($ARM_DATA[arm].OT_TOL_DIST) and the threshold in degrees in relation to the orientation of the flange ($ARM_DATA[arm].OT_TOL_ORNT). In case of a very long tool (for instance, 1 meter in the tool’s Z direction) and if the robot has stopped in correspondence with $CRNT_DATA[arm].OT_POS, only a slight rotation of the tool is necessary in order to provoke a significant flange movement, so that the $CRNT_DATA[arm].OT_COARSE variable is set to FALSE. In case of rotating auxiliary axes, threshold $ARM_DATA[arm].OT_TOL is used. In case of traversing auxiliary axes, threshold $ARM_DATA[arm].OT_TOL_ORNT is used.

If the arm includes integrated auxiliary axes, in case of jog movements in joint mode, all the axes that have been enabled, including the auxiliary axes, contribute to the modification of the Cartesian position and result in the arm moving away from the trajectory ($CRNT_DATA[arm].OT_COARSE = FALSE). In case of jog movements in Cartesian mode (Base, Tool, etc.) the movement of the auxiliary axis is compensated by the robot’s axes in order to maintain the Cartesian point; however, as the entire configuration of the arm axes is modified, the arm also moves away from the trajectory in this case ($CRNT_DATA[arm].OT_COARSE = FALSE), extending the concept of position on the trajectory to the extended position.

If the arm includes auxiliary axes that are not integrated, in case of jog movements in joint mode, the axis does not modify the Cartesian position, but the overall configuration of the arm is modified and the arm moves away from the trajectory ($CRNT_DATA[arm].OT_COARSE = FALSE). In case of jog movements in Cartesian mode, the auxiliary axis cannot be moved and the arm behaves in the same way as the 6 axes robot.

It is always possible to return to the trajectory ($CRNT_DATA[arm].OT_COARSE = TRUE) by executing a movement on the $CRNT_DATA[arm].OT_JNT variables (or $CRNT_DATA[arm].OT_POS variables, for robots with no auxiliary axes).

Example:MOVE TO $CRNT_DATA[arm].OT_JNToRMOVE TO $CRNT_DATA[arm].OT_POS

WITH $TOOL=$CRNT_DATA[arm].OT_TOOL,WITH $UFRAME = $CRNT_DATA[arm].OT_UFRAME

ENDMOVE

The presence of a Remote Tool does not affect functionality. When the program is deactivated, the $CRNT_DATA[arm].OT_COARSE variable is reset. See followingTab. 5.1 - On Pos and On Trajectory table.

This function is not available on the following machine types: robots with active kinematic compensation (file .ROB in RD), robots with conveyor tracking, enabled cooperative movement.

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.

50pr-0-0-gpr_04.fm

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.

5.4.2 On Position (ON POS)

By means of this function, it is possible to verify, at all times, whether the robot’s Tool Center Point (TCP) corresponds to a specific predefined position, such as the Home position, the Tip-dressing position for SPOT applications or the Service position. The predefined positions must be stored:

– in the $OP_JNT field if the auxiliary axes, or some of these (see predefined variable $ON_POS_TBL[index].OP_JNT_MASK), must also be controlled;

– in the $OP_POS field if only the Cartesian position is concerned.

This information is primarily used to communicate to external devices, such as a line PLC, that the robot is in the aforesaid positions.

To make the On Pos function operational, each time the control unit is restarted, the application program must run the following sequence of operations in the order set out below:

– Initialize the predefined fields with the OP_ prefix, in the $ON_POS_TBL table.

– Run the built-in procedure ON_JNT_SET or ON_POS_SET to define which port and which bit are to be assigned upon reaching the main positions.

– Execute ON_POS(ON) to enable the function, which will remain enabled until the subsequent ON_POS(OFF) is executed on the same item of the $ON_POS_TBL or at the subsequent system restart.

For further details related to the $ON_POS_TBL and $OP_xxx system variables, the ON_JNT_SET, ON_POS_SET and ON_POS built-in routines, the CONDITION events, please refer to the PDL2 Programming Language Manual.

This service is disabled in the case of: robot with active kinematic offset (file .ROB) in UD, robot with cooperative or conveyor tracking enabled.

5.4.2.1 Example of On Pos and On Trajectory

In order to summarize the behavior of the system, let us suppose that a program being executed is interrupted:

– in a configuration in which the arm is on the trajectory;

– on a predefined position;

– on a predefined joint position for all axes of the arm (the mask of the joints on ON_JNT_SET corresponds to the $JNT_MASK).

Let us suppose we wish to perform an arm movement, in jog mode, exceeding the predefined threshold:

51pr-0-0-gpr_04.fm

00/0210

Motion Control

5.5 Speed ControlPredefined variables are used to control the maximum or constant speed of a motion, some of which are system-wide, some of which are program-specific, and some of which are arm-specific. Two kinds of speed controls are used:

– absolute speed values or limit values, measured in normal speed units such as radians per second or meters per second;

– override values that govern the absolute speed values, measured in percentage.

In the C5G system, not only speed can be controlled by the user, but also acceleration and deceleration. Independent basic control values and overrides exist for acceleration, speed, and deceleration. The basic and override values for acceleration and deceleration are discussed in par. 5.6 Acceleration and Deceleration on page 57 in the current chapter.

5.5.1 Speed Overrides

Speed override values govern (or override) the basic speed values (see description par. 5.5.2 Cartesian Speed Control on page 53 section).

The speed overrides (percentage speed values) that apply to all motions are as follows:

– $GEN_OVR allows the operator to change simultaneously the acceleration, speed and deceleration values of Motion programs. Since this influences the acceleration, speed and deceleration values in a coordinated manner, the trajectories are usually maintained (unless there are servo tracking errors) when this variable is changed.

Tab. 5.1 - On Pos and On Trajectory

On Trajectory

Value of:$CRNT_DATA[ ].OT_COARSE

On Pos con JOINTPOS($OP_JNT)Value of:$ON_POS_TBL[ ].OP_REACHED

On Pos con POSITION($OP_POS)Value of:$ON_POS_TBL[ ].OP_REACHED

Initial condition TRUE TRUE TRUE

Movement of robot axis in joint mode

FALSE FALSE FALSE

Movement of integrated auxiliary axis in joint mode

FALSE FALSE FALSE

Movement of non-integrated auxiliary axis in joint mode

FALSE FALSE TRUE

Movement in Cartesian mode with reference to X, Y, Z and/or E1, E2, E3

FALSE FALSE FALSE

Movement in Cartesian mode of integrated auxiliary axis

FALSE FALSE TRUE

Deactivation of movement program

FALSE TRUE TRUE

52pr-0-0-gpr_04.fm

00/0210

Motion Control

$GEN_OVR is an INTEGER type variableIt is common to the whole system and can be changed from the Teach Pendant. The PDL2 programs can read it only.

– $ARM_OVR permits acceleration, speed, and deceleration of a specific arm to be modified from within a program. Since it affects acceleration, speed, and deceleration in a coordinated way, trajectory shapes are generally maintained when this control is modified (except for differences in servo following errors at different values of override).$ARM_OVR is an INTEGER field of the system-wide array of structures, $ARM_DATA[ ]. There is one $ARM_DATA structure per arm, and the ARM_OVR field has a default value of 100%.

Note that if constant speed during transitions between continuous motions is more important than constant trajectory, then $ARM_SPD_OVR or $PROG_SPD_OVR should be used (acceleration and deceleration will be left at current values as these speed overrides are reduced).See section par. 5.10.1 Trajectory Shape During Continuous Motion on page 67 in current chapter.

– $ARM_SPD_OVR permits the speed of a specific arm to be modified by a program. Acceleration and deceleration are not affected. This implies that the shape of continuous motion trajectories may change as this control is changed. See section par. 5.10.1 Trajectory Shape During Continuous Motion on page 67 in current chapter. $ARM_SPD_OVR is an INTEGER field of the system-wide array of structures, $ARM_DATA[]. There is one $ARM_DATA structure per arm, and the ARM_SPD_OVR field has a default value of 100%.

– $PROG_SPD_OVR permits speed of all motions issued from a specific program to be modified by the program. Acceleration and deceleration are not affected. This implies that the shape of continuous motion trajectories may change as this control is changed. It is a program-specific variable with a default value of 100%.

The total speed override for any motion for a specific arm is determined as follows:

total speed override[arm] = $GEN_OVR * $ARM_DATA[arm].ARM_OVR *$ARM_DATA[arm].ARM_SPD_OVR * $PROG_SPD_OVR

$GEN_OVR and $ARM_OVR take effect during motions. That is, if either variable is changed while a motion is in progress, the current motion will speed up or slow down accordingly. However, a change in $PROG_SPD_OVR or $ARM_SPD_OVR will not take effect until the next move statement within the program for which it is defined.Also, please refer to par. 5.10.1 Trajectory Shape During Continuous Motion on page 67section in current chapter, for a discussion of some more effects of such variables.

$ARM_SPD_OVR, $ARM_OVR, and other variables described in this chapter are fields of the predefined system-wide array of structures, $ARM_DATA. The details of this structure and how to reference fields within the structure are fully documented in the chapter referring to the predefined variables of the PDL2 Programming Language Manual.

5.5.2 Cartesian Speed Control

Under normal operation, the following two predefined variables govern the basic speed of a Cartesian motion (linear or circular), with any type of orientation control.

53pr-0-0-gpr_04.fm

00/0210

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:

cartesian speed[arm] = SMS[arm] * total speed override[arm]

where SMS[arm] is $ARM_DATA[arm].ROT_SPD_LIM if rotation takes the longest, or $ARM_DATA[arm].LIN_SPD_LIM if translation takes the longest. (See previous par. 5.5.1 Speed Overrides on page 52 for a definition of “total speed override”).

5.5.2.1 Cartesian Speed Control Options

The process of determining which component governs Cartesian speed is called preplanning. This occurs just before the motion actually occurs (i.e. after each MOVE). It is possible to force the preplanner to pick a particular component of motion using the predefined variable $SPD_OPT. It is a program-specific variable (each program can have its own value) that can be assigned the following predefined constants:

– SPD_CONST is the default value. It moves the arm at constant speed with the SMS being picked by the preplanner, as explained previously.

– SPD_JNT moves the arm along the requested Cartesian trajectory, at the maximum speed of at least one joint. The TCP will not move at constant speed.

– SPD_LIN moves the TCP according to the requested $LIN_SPD, forcing the rotation component to move in coordinate way. Note that in this case, $LIN_SPD replaces $LIN_SPD_LIM in the speed calculation. $LIN_SPD is a REAL field of the system-wide array of structures,

54pr-0-0-gpr_04.fm

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

55pr-0-0-gpr_04.fm

00/0210

Motion Control

rotational ($ROT_SPD) speed as maximum value. In order to use such an option, it is needed to purchase the software option SmartMove.

If the value of $SPD_OPT is not meaningful for the current trajectory type, the default SPD_CONST is assumed. For example, specifying $SPD_OPT=SPD_SECOND has no meaning if $ORNT_TYPE=RS_WORLD, so SPD_CONST would be used.

Changes to $SPD_OPT, $LIN_SPD, and $ROT_SPD only take affect at the beginning of the next move. Changes do not affect the current motion of an arm.

5.5.2.2 Run-Time modifying the Linear Speed Override

It is allowed to run-time modify the TCP speed override, only if the following conditions are satisfied:

– Cartesian movement

– the motion control type is $SPD_OPT := SPD_LIN.

Such conditions BOTH have to be satisfied, otherwise no run-time modifications are allowed. Therefore, it is not possible to apply such a functionality to Arms which CANNOT move with a cartesian motion.

The predefined variable which allows to run-time modify the speed override, is

$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:

MAX = ($LIN_SPD_LIM / $LIN_SPD) * 100

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.

5.5.3 Joint Speed Control

For joint interpolated motions, the actual motion speed for a specific arm is determined by computing the maximum of the motion times for each joint travelling at its maximum limit. The predefined INTEGER array, $MTR_SPD_LIM[], defines the maximum speed of each motor, which in turn defines the maximum speed of each joint. $MTR_SPD_LIM is a field of the predefined system-wide array of structures, $ARM_DATA[]. Thus there is a value for each axis for each arm.

The speed override for each joint is determined by $JNT_OVR, which permits acceleration, speed, and deceleration to be modified together by a program. It is a field of $ARM_DATA and it is an INTEGER array of the system-wide array of

For run-time linear speed variations during synchronized motions, please see Chap.6. - Synchronous Motion (optional feature) in current Manual.

56pr-0-0-gpr_04.fm

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.

5.5.4 Manual Motion Speed Control

If movements are executed while the Control Unit is in PROGR status (status selector switch on T1), a further $MAN_SCALE speed value is used, to keep the maximum speed within the safety values. If the predefined variable $SPD_OPT is set to SPD_LIN, then the speed of the arm is determined by the value of the predefined variable $LIN_SPD. If the value of $LIN_SPD is greater than 0.25 meters per second, then the speed of the arm will be reduced to 0.25 meters per second. $MAN_SCALE is set at the factory and cannot be changed by the Customer.

5.6 Acceleration and DecelerationAcceleration and deceleration in the C5G controller are each broken into three phases, a constant jerk phase, followed by a constant acceleration phase, followed by another constant jerk phase.See Fig. 5.3 - Speed and acceleration profiles.

Fig. 5.3 - Speed and acceleration profiles

1. speed2. 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

57pr-0-0-gpr_04.fm

00/0210

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.

5.6.1 Acceleration/Deceleration Overrides

As with speed, acceleration and deceleration also have overrides. As already explained in par. 5.5.1 Speed Overrides on page 52, $GEN_OVR and $ARM_OVR not only affect speed, but also acceleration and deceleration. In addition, arm specific and program specific variables exist to further override acceleration and deceleration. Such variables are arm or program specific:

– $PROG_ACC_OVR permits acceleration of all motions issued from a specific program to be modified by the program. It is a program specific INTEGER with a default value of 100%;

– $PROG_DEC_OVR permits deceleration of all motions issued from a specific program to be modified by the program. It is a program specific INTEGER with a default value of 100%;

– $ARM_ACC_OVR permits acceleration of a specific arm to be modified by a program. It is an INTEGER field of the array, $ARM_DATA, with one field for each arm. The default value is 100%;

– $ARM_DEC_OVR permits deceleration of a specific arm to be modified by a program. It is an INTEGER field of the array, $ARM_DATA, with one field for each arm. The default value is 100%.

The equations for total override for acceleration and deceleration are:total acceleration override[arm] =

58pr-0-0-gpr_04.fm

00/0210

Motion Control

$GEN_OVR*$ARM_DATA[arm].ARM_OVR*$ARM_DATA[arm].ARM_ACC_OVR*$PROG_ACC_OVR

total deceleration override[arm] =$GEN_OVR*$ARM_DATA[arm].ARM_OVR*$ARM_DATA[arm].ARM_DEC_OVR*$PROG_DEC_OVR

$PROG_ACC_OVR and $PROG_DEC_OVR are program specific INTEGER values with default values of 100%. $ARM_ACC_OVR and $ARM_DEC_OVR are INTEGER fields with one field per arm in multi-arm systems. Changes in these four overrides take effect only on succeeding motions, not during any current motion. However, as with speed, changes in $GEN_OVR and $ARM_OVR take affect in the current motion.

When HOLD, CANCEL, LOCK, or DEACTIVATE are used, maximum deceleration is used regardless of the above override settings. In addition, a predefined variable, $HLD_DEC_PER, can be used to increase the deceleration rate beyond normal maximum settings. At high speed, normal maximum deceleration for some arms may require several hundred millimeters to stop. The range of $HLD_DEC_PER is from 100 to 400 percent, permitting the normal maximum to be multiplied by a factor up to 4. $HLD_DEC_PER is a read-only INTEGER array field of the system-wide array of structures, $ARM_DATA[]. Thus, there is one element per axis for each arm.

5.6.2 Joint Interpolation

After the governing joint is picked (based on speed), the speed of each of the remaining joints is scaled by the ratio of original time for the joint to the time of motion of the governing joint. Each joint must accelerate to its scaled speed, not to its requested speed.

The acceleration time for each joint is evaluated to determine which joint will govern acceleration. (This is not necessarily the same as the joint governing speed).

This time is a combination of $MTR_ACC_TIME[axis] and $JNT_OVR[axis]. A similar combination, using $MTR_DEC_TIME and $JNT_OVR is used to find the governing joint for deceleration.

After the limiting joints for acceleration and deceleration are determined (not necessarily the same joint), all joints are scaled to accelerate and decelerate in the same amount of time.

The previously described acceleration and deceleration overrides are also applied to each joint.

5.6.3 Cartesian Interpolation

The same type of analysis done for joint acceleration and deceleration is done for Cartesian acceleration and deceleration, except that instead of joints being compared, translation and rotation are compared.

The acceleration and deceleration in the Cartesian motion (either linear or circular), with any orientation evolution modality, is controlled by means of the following predefined variables:

– $LIN_ACC_LIM specifies the maximum acceleration for linear translation. There is a variable for each axis of each arm, whose values depend on the robot model and cannot be modified by the User.

59pr-0-0-gpr_04.fm

00/0210

Motion Control

– $ROT_ACC_LIM specifies the maximum acceleration for rotation. There is a variable for each axis of each arm, whose values depend on the robot model and cannot be modified by the User.

– $LIN_DEC_LIM specifies the maximum deceleration for linear translation. There is a variable for each axis of each arm, whose values depend on the robot model and cannot be modified by the User.

– $ROT_DEC_LIM specifies the maximum deceleration for rotation. There is a variable for each axis of each arm, whose values depend on the robot model and cannot be modified by the User.

The predefined variables $LIN_ACC_LIM, $ROT_ACC_LIM, $LIN_DEC_LIM, and $ROT_DEC_LIM are used to compute the component that takes the longest time. These variables are REAL fields of the system-wide array, $ARM_DATA[ ], with one field per arm. The user is allowed to modify them by system level commands only.

The other components are scaled so that both rotations and translations use the same time to accelerate and the same time to decelerate. The overrides are also applied.

5.6.4 Manual Motions

When programmed or immediate motions are issued in PROGR state, the described above acceleration and deceleration overrides are used. However, when jog motions are issued from the teach pendant, maximum deceleration is used to stop the arms.

An additional override, $MAN_SCALE, is used during manual motions to limit the maximum speed to safe values. This manual override also affects acceleration and deceleration to maintain trajectory shape for all motions issued in PROG state, except for jog motions. For jog motions, $MAN_SCALE only affects speed. $MAN_SCALE is set by the Builder and cannot be changed by the Customer.

5.7 Motion terminationIt specifies the accuracy in robot positioning on the motion final destination, for a NON FLY movement, before the next operation is performed.

For non-continuous motions, the predefined variable $TERM_TYPE is used to determine when the motion will be terminated based on how close the arm must be to its destination.

The predefined constants COARSE, FINE, JNT_COARSE, JNT_FINE, or NOSETTLE can be assigned to $TERM_TYPE, with NOSETTLE being the default.

5.7.1 COARSE and FINE Termination

The COARSE and FINE values indicate two different thresholds that can be used to define the motion stop (in-threshold). These thresholds, in the Cartesian frame, are the radius of a sphere that has the target point as its centre. Furthermore:

– COARSE - must be used in Cartesian movements and indicates that the movement is accomplished if the TCP stays inside the sphere which is centered in the final destination, with a radius specified by $TOL_COARSE predefined variable, for a time greater equal to $TOL_ABT (anti-bounce time).

– FINE - must be used in Cartesian movements and indicates that the movements is accomplished if the TCP stays inside the sphere which is centered in the final destination, with a radius specified by $TOL_FINE predefined variable, for a time greater equal to $TOL_ABT (anti-bounce time).

60pr-0-0-gpr_04.fm

00/0210

Motion Control

The predefined variables $TOL_COARSE and $TOL_FINE indicate the tolerance values. The default values for $TOL_COARSE and $TOL_FINE are arm dependent.

The predefined variable $TOL_ABT (anti-rebound time) indicates the time during which the arm is to be within the specified tolerance before the motion is declared completed/finished. It has a range of 0 to 2000 milliseconds and a default value of 0 milliseconds. A value of 0 means the motion is terminated as soon as the arm is within the specified tolerance.

The predefined variable $TOL_TOUT (time out) determines the length of time the system will continue checking to see if the arm is within the specified tolerance. It has a range of 0 to 20000 milliseconds and a default value depending on the kind of robot. The value is rounded up to the nearest interpolator frequency ($IPERIOD) tick, so a value less than this frequency is interpolated as one tick. If the arm does not come within the specified tolerance within the specified timeout, an error with hold severity is issued.

5.7.2 JNT_COARSE and JNT_FINE Termination

The JNT_COARSE and JNT_FINE values specify the two different tolerances that can be used to define the conclusion of the motion.

The predefined variables $TOL_JNT_COARSE and $TOL_JNT_FINE indicate the COARSE and FINE tolerance values respectively, for each joint, measured in degrees.They represent, for each joint, the acceptable tolerance range in degrees, to be able to state that the motion has terminated on the final point. They are one dimension vectors.

Note that tolerance settings are joint settings, not tool centre point settings. To obtain the correct tool centre tolerance values if the tool itself is large, it is necessary to use lower tolerances than those used for smaller tools; in this case make reference to the Cartesian frame thresholds (Fine, Coarse)

5.7.3 NOSETTLE Termination

The NOSETTLE value indicates that the motion is to be declared terminated as soon as the deceleration profile has been completed. There is no settling time for the arm to position itself precisely within a specified tolerance.

No controls are executed; NOSETTLE is the default setting.

5.8 Trajectory Recovery If needed, motions can be stopped even before they are accomplished. For example, an operator might press the HOLD key or the DRIVE OFF softkey. When HOLD button is pressed, arms will smoothly decelerate and stop exactely on current trajectory. Pressing START button will resume motion on current trajectory. No trajectory recovery is needed. The same happens when the DRIVE OFF is requested but the power is also cut out from the drives and the brakes are activated. The robot can be stopped by opening the gates: in this case braking will take place with stop on the trajectory. The robot can be stopped by pressing the safety mushroom-head button. In this case braking will take place with stop on the trajectory, but with no in-threshold check.

With the status selector switch on T2, pressing the mushroom-head button causes a stop WITHOUT control of the trajectory, with the power cut off and the brakes opened.

5.8.1 Recovery Strategy

Two forms of recovery are defined, short range and long range. Short range recovery means recovery from a position that is very close to the original trajectory, as defined by

61pr-0-0-gpr_04.fm

00/0210

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:

Wherever it is possible to interrupt a program motion executed in Automatic mode, for example setting it in HOLD state, then switch to Programming mode and jog the robot, then go back to an Automatic mode. When START button is pressed, short or long range recovery is determined and such a specified recovery strategy is performed.

When the system is in Programming state and a motion is interrupted by the DRIVE OFF, recovery will be based upon conditions that exist when the drives are turned back again and either START or BACK button is pressed. The recovery type will be determined by whether or not there is a pending motion and from where the motion was issued. The exact recovery type is determined as follows.

5.8.1.1 Pending Motion Status

If there are no pending motions either START or BACK button is pressed, then no motion is performed. Recovery will only occur when there is a pending motion, and the recovery type will be based on the recovery range.

5.8.1.2 Recovery Range

In Programming mode the same strategy is used as for the Automatic status. If the distance between the stop position and the nominal position is limited, a joints interpolation move is used to bring the arm to the point where the motion was interrupted (short range); otherwise the $RCVR_TYPE variable is used (long range recovery) to execute the recovery move.

5.8.1.3 Execution Environment

When executing from within the edit environment, messages about the recovery are displayed for the user. After bringing the arm to the position where the motion was interrupted, press the START key, then press it a second time to continue the motion along the original path. If the motion command was issued from within an execution environment which is NOT a modification environment, then no messages are displayed

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

62pr-0-0-gpr_04.fm

00/0210

Motion Control

and no user interaction is required to perform the recovery.

If the user jogs the robot immediately after the interruption, then recovery will not be performed. If the controller is switched into Automatic state during the interruption, then all of the recovery rules are followed.

5.9 Process ResumeThe process reset allows the robot to return back along the trajectory in progress before returning to the programmed move. Hereafter this movement will be referred to as return movement. The maximum distance requested must be defined in the system variable $RCVR_DIST (in millimeters). If a zero value is attributed to $RCVR_DIST, such a performance is disabled.

This performance is useful for applications in which the robot effects the process activity during movement (typical examples are the welding arc and sealant application). If, during some of these applications, movement is interrupted for any reason, part of the trajectory that has already been covered should be retraced in order to avoid the risk of skipping parts of the process.

The return movement is enabled after any stop: HOLD sent from the Teach Pendant, HOLD due to error, LOCK, state selector switching, DRIVE OFF, emergency stop.

If the interruption is the result of an emergency or DRIVE OFF state, the trajectory will probably be recovered before the return movement starts. In such cases the return movement will start after trajectory restore has been performed. The user should remember that the no return movement t is only allowed in the trajectory restore modes at the point of interruption ($RCVR_TYPE=0 or 4); it is disabled if a return is performed on either start or end point.

The return movement is interrupted in advance if it intersects a not in FLY position (Fig. 5.7 - Return Movements - example D) or upon exhaustion of the movement preceding the one in progress (Fig. 5.5 - Return Movements - example B and Fig. 5.6 - Return Movements - example C).

Fig. 5.4 - Return Movements - example A

Simplest situation.

1. Programmed Fly position, between two movements2. First movement - fly termination3. Second movement - fly beginning4. Second movement - fly termination5. Stop position6. Motion direction7. First movement – fly beginning

63pr-0-0-gpr_04.fm

00/0210

Motion Control

Fig. 5.5 - Return Movements - example B

$RCVR_DIST programmed value is greater than the maximum recoverable one

1. Maximum recoverable distance2. Stop position

Fig. 5.6 - Return Movements - example C

If a fly movement is interrupted, it is possible to go back twice

1. Stop position2. Maximum recoverable distance

Fig. 5.7 - Return Movements - example D

The return movement is interrupted if a position is encountered

1. Maximum recoverable distance (because there is a non fly position)2. Stop position

64pr-0-0-gpr_04.fm

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).

Fig. 5.8 - Example in case of $RCVR_DIST modification

1. Stop position of the return movement2. First value of $RCVR_DIST=20 mm3. Return movement interruption: $RCVR_DIST is read again4. $RCVR_DIST=30 mm after the modification5. Stop position

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).

5.9.1 Automatic Process Resume

It also exists a Process Resume mode working like trajectory recovery number 4 ($RCVR_TYPE := 4); in such a modality the covered distance during the return movement is $RCVR_DIST plus the covered distance, while decelerating, between the stop command and the actual machine stop.

To enable such a modality, $RCVR_TYPE predefined variable is to be set to 9.

65pr-0-0-gpr_04.fm

00/0210

Motion Control

1. motion direction2. trajectory3. calculated return movement4. $RCVR_DIST5. decelerate distance6. motion stop command7. actual motion stop position

5.10 Continuous MotionThe Continuous Motion allows the Program execution without stopping the Arm on the taught positions.

To indicate a countinuous motion, the MOVEFLY statement is to be used, instead of the MOVE statement. If one more movement follows the MOVEFLY, the Arm will not stop on the first destination, moving instead from the starting position to the final position of the second movement, without stopping on the common position of the two movements.

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.

Fig. 5.9 - Example of continuous motion in case of linear movement

1. Movement start towards c2. Movement end towards b

Fly movements between Joint trajectories an Cartesian trajectories are not allowed (NO mixed fly).

66pr-0-0-gpr_04.fm

00/0210

Motion Control

5.10.1 Trajectory Shape During Continuous Motion

Fig. 5.9 - Example of continuous motion in case of linear movement shows a rounded corner during the transition (fly) between the motion from A to B and the motion from B to C. This rounding is a result of the deceleration of the first motion combined with the acceleration of the second motion. The shape and amount of such rounding is a function of the user settings ($FLY_PER, $FLY_DIST, $FLY_TRAJ), the speed of the two motions, the values used for acceleration and deceleration, and the capability of the servo system of the particular arm and payload.

When $GEN_OVR or $ARM_OVR are changed (or $JNT_OVR in the case of joint interpolated motions), acceleration and deceleration are changed along with speed in order to preserve the shape of the trajectory regardless of override. The shape will remain nearly the same except for the effect of servo following error. The purpose of this feature is to permit teaching at low override values with little or no touch-up required at production speeds.

Another effect of maintaining trajectory shape at low overrides is that the arm will accelerate and decelerate more slowly. However, when HOLD, LOCK, CANCEL, or DEACTIVATE are used, maximum deceleration is used to stop the arm.

When other speed overrides are changed, such as $PROG_SPD_OVR or $ARM_SPD_OVR, acceleration and deceleration are not changed, and the shape will change as a result. These overrides are used from within programs where it is desirable to change only speed, and trajectory shape is unimportant during fly.

5.10.2 Continuous Motion Modes (FLY)

The predefined variable $FLY_TYPE determines which of several different algorithms are used to control continuous motion. The algorithm used affects not only the speed and shape of the trajectory during fly motions, but also the amount of stress placed on the arm and on the component or tool connected to it. The available $FLY_TYPE values are FLY_NORM and FLY_CART.

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

67pr-0-0-gpr_04.fm

00/0210

Motion Control

be achieved by using FLY_CART. (par. 5.10.2.2 FLY_CART (Controller Aided Resolved Trajectory) on page 68).

5.10.2.2 FLY_CART (Controller Aided Resolved Trajectory)

Fly_CART is used for $FLY_TYPE when TCP constant speed is needed.It also allows to control the shape of the trajectory during fly, or the stress on the arm, the part, or the tool. For FLY_CART to be effective, $SPD_OPT must be set to SPD_LIN and any movement must be cartesian. The default value for $SPD_OPT is SPD_CONST.

As long as various constraints (described below) are not exceeded, the TCP speed will be maintained constant during fly between Cartesian (linear or circular) segments using FLY_CART. FLY_CART may also be used during path motions between Cartesian segments. FLY_CART has no effect when one or both of the motions is joint interpolated.

5.10.2.2.1 Dynamic Machine Stress Control

The algorithm for FLY_CART control implements the idea of generalized stress, which is made up three components of stress on the arm and tooling. Large changes in orientation of the tool, high TCP speed, or large changes in direction of the TCP all can cause large acceleration forces either on individual components of the arm, on the part, or on the tooling. A generalized stress limit is defined, which is proportional to programmed speed, the angle between adjoining trajectories, and the required orientation change. This stress limit is user setable by the predefined variable $STRESS_PER.

The default value of $STRESS_PER is 50%, and it must be in the range of 1% - 100%. Higher values for $STRESS_PER indicate more stress, lower values less stress. Higher values indicate to the system that higher values of acceleration and deceleration may be used. It will therefore begin and end fly closer to the taught intermediate point. A value of 100% will attempt to pass directly through the intermediate point, with little or no fly.

With $STRESS_PER = 50% and two straight line segments at 90 degrees and little orientation change, the fly trajectory will be nearly the same as if $FLY_TYPE were set to FLY_NORM. However, unlike FLY_NORM, the TCP speed will remain constant. If the angle between the straight line segments is increased (the segments are more towards collinear), the distance covered by the fly, in FLY_CART mode, will be shorter and therefore the trajectory will be nearer to the intermediate position taken in relation to FLY_NORM. If the angle is sharper, the trajectory will be farther from the intermediate point than with FLY_NORM, but lower stress will occur than with FLY_NORM.

See Fig. 5.10 - Comparison between FLY_CART and FLY_NORM ($STRESS_PER=50) for a graphical display of such situations.

68pr-0-0-gpr_04.fm

00/0210

Motion Control

Fig. 5.10 - Comparison between FLY_CART and FLY_NORM ($STRESS_PER=50)

A similar control is placed on the generation of circular trajectories. The velocity of circular motions will be reduced to keep the stress of the arm within the limits specified by $STRESS_PER. This reduction of motion velocity is more likely to occur with circular motions having a small radius. (Note that this reduction is for the entire circle, not just the fly trajectory between the circle and the next motion).

Keep the following points in mind when determining a value for $STRESS_PER.

– The larger the value of $STRESS_PER, the larger the probability that the speed will remain constant. Also, larger values of $STRESS_PER will bring the trajectory nearer the taught intermediate position. In reality however, an increase in $STRESS_PER can place greater demands on the controller, causing the quality of the trajectory to be reduced.

– When $STRESS_PER is set to 100%, the planned trajectories become very sharp since they pass through the programmed point without a reduction in speed. This can cause very high stress on the robot, the part, and the tooling in some cases.

– Lower values of $STRESS_PER can be used to reduce the stress caused by large wrist orientation changes. However, this “smoother” trajectory will pass farther from the taught intermediate position.

5.10.2.2.2 Constant Speed Maintenance

As already described, FLY_CART allows the TCP speed to be maintained as a constant during the fly motion as long as the limit set by $STRESS_PER is not exceeded. It is strongly suggested that this feature be used to take advantage of the built-in computations for fly motion. The following rules affect speed control in this mode:

– As for all fly motions, if the planned motion is too short the desired speed can not be reached. In this situation the speed maintained during the fly motion is the speed at the moment the fly started.

– When using high linear speeds, some motions will be too short and not allow time for the necessary preliminary calculations. In this case the FLY_CART setting behaves the same as all the other settings-i.e. the speed can not always be maintained as a constant.

– The speed will not remain constant if the limit set in $STRESS_PER is exceeded by the programmed trajectory.

5.10.2.2.3 Control of Trajectory During FLY

Quando la modalità fly viene impostata a FLY_CART, la traiettoria può essere controllata impostando:

69pr-0-0-gpr_04.fm

00/0210

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.

Fig. 5.11 - FLY Movements

The above picture (Fig. 5.11 - FLY Movements) shows an example of the use of these

Be careful! $FLY_DIST is only used if $FLY_TRAJ is DIFFERENT from FLY_AUTO

70pr-0-0-gpr_04.fm

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.

5.10.2.2.4 Debug of Fly Motions

When debugging FLY_CART motions a field of $CRNT_DATA can be used to determine the status of the last motion. The field name is $FLY_DBUG and will be zero if the optimized trajectory was obtained or will contain a value to indicate the state of the movement.

The FLY_DBUG field can be used in a NOHOLD program, from condition handlers, etc.

The programs can simply write the value to the display device for evaluation or undertake some corrective actions. After the program has been properly configured these debugging aids should be removed so they don’t slow the system down unnecessarily. The following program demonstrates a simple example of the FLY_DBUG used in a CONDITION.

PROGRAM mov_cartCONST

arm_num = 1cond_num = 1

ROUTINE print_debugBEGIN

WRITE ($CRNT_DATA[arm_num].FLY_DBUG, NL)END print_debugBEGIN

$CRNT_DATA[arm_num].FLY_DBUG := 0CONDITION[cond_num] NODISABLE :WHEN AT END DO print_debugENDCONDITION

-- initialisationENABLE CONDITION[cond_num]-- move statements

END mov_cart

Tab. 5.2 - FLY_DBUG field codes for $CRNT_DATA variable

Code Description

0 Optimal situation indicating that the speed is maintained constant and the trajectory, planned with $FLY_DIST, is guaranteed.

1 The fly lasts for less than 40ms. It is impossible to activate the constant speed algorithm. This code is informational only; speed is maintained constant.

2 The angle between the trajectories is too small (less than 5 degrees) so it is impossible to activate the constant speed algorithm.

3 Acceleration reduction due to an extreme orientation evolution. This is caused by the evolution of the tool orientation during fly. In this situation, the fly is smoothed and the speed is maintained constant.

71pr-0-0-gpr_04.fm

00/0210

Motion Control

5.10.2.2.5 Variables used with FLY Motion

If $FLY_TYPE is equal to FLY_CART, the following table summarizes the other values that must be defined.

– $STRESS_PER { value from 1% to 100% }

– $CRNT_DATA[arm].FLY_DBUG: usually used for read-only

4 Replanning due to weaving causes a distance to be set, which is greater than the user programmed one ($FLY_DIST). The speed is maintained constant.

5 Speed for passing the planned distance is reduced. In order to respect the restriction of the passage ($FLY_DIST) and the restriction on the stress ($STRESS_PER), speed is automatically reduced during fly. By default, $FLY_DIST is set to 5 and $FLY_TRAJ is set to FLY_TOL. To overcome this speed reduction, increased the tolerance on the planned trajectory (i.e. increase $FLY_DIST) or increase $STRESS_PER.

6 Speed reduction on a circular motion due to extreme stress. This code means that the limitation on the maximum stress ($STRESS_PER) is imposing a speed reduction on the whole circular trajectory. This can be overcome by increasing the radius of the circle, increasing the value of $STRESS_PER, or reducing programmed speed.

7 Speed reduction due to an extreme orientation evolution. The orientation evolution required during fly imposes speeds that are greater than the maximum allowed and the speed is reduced during trajectory. To overcome, spread the orientation variation on the previous and next motion or increase $STRESS_PER.

8 It is impossible to respect the passage at the planned distance and the resulting distance is in effect reduced. This occurs only when $FLY_TRAJ is set to FLY_PASS or FLY_FROM. The passage was programmed by the user to pass through a point that is too far away. It is possible to obtain some advantages by decreasing the speed or by increasing the $STRESS_PER value.

9 e 10 Current motion is too short to keep constant speed during fly. The planned speed is reached during the movement. To change such a condition, increase (if possible) the distance between the planned points and increase $STRESS_PER.

11 Motion too short to reach the planned speed because the acceleration phase cannot be terminated. If possible, increase the distance between the two planned points. In some cases, it could be useful to increase $STRESS_PER.

12 Extreme stress for a short motion. The resulting motion is too short for the execution of the fly that guarantees the limitations on the maximum stress. The resulting stresses are greater than the planned ones and the speed could change during fly. To change this condition, increase (if possible) the distance between the planned points and increase $STRESS_PER.

13 Extreme stresses on the orientation evolution due to a short motion. The resulting motion is too short for executing a fly that guarantees the limitations on the maximum stress in the orientation evolution. The resulting stresses are greater than the planned ones and the speed could change during fly.

14 e 15 Impossibility of fly re-planning due to lack of time. The movement does not last long enough to allow the completion of the preliminary counts. The resulting stresses are greater than the planned ones and the speed could change during fly. If possible, increase the distance between the two planned points. In some cases, it could be useful to increase $STRESS_PER.

16 Impossibility of fly re-planning with extreme stresses on the orientation evolution. The resulting stresses are greater than the planned ones and the speed could change during fly. If possible, increase the distance between the planned points and reduce the planned speed ($LIN_SPD). In some cases, it could be useful to increase $STRESS_PER.

Tab. 5.2 - FLY_DBUG field codes for $CRNT_DATA variable

Code Description

72pr-0-0-gpr_04.fm

00/0210

Motion Control

– $FLY_TRAJ values: FLY_AUTO, FLY_TOL, FLY_PASS, FLY_FROM

– $FLY_DIST: values in millimeters. This is used when $FLY_TRAJ is different from $FLY_AUTO.

5.11 Remote Tool SystemRemote tool system is a particular configuration in which the robot is treated as a positioner referred to a fixed tool. The robot carries the workpiece so that the TCP of the fixed tool follows the right trajectory on the workpiece.

This is very common in applications where the tool either is much heavier than the part or is immobile for some reason.

The remote tool system is enabled by setting the $TOOL_RMT system variable to TRUE: it is a predefined variable belonging to $ARM_DATA group which is NOT reset at Program deactivation; furthermore, its value is saved in the .C5G file by means of the Config.Function (F1) - SETUP Page on the Teach Pendant.

Since this variable is a field of $ARM_DATA, it is not reset upon program deactivation and, in addition, its current value is saved in file.C5G by ConfigureSave command.

Note that the workpiece frame is now defined with respect to the flange of the robot by means of $UFRAME, while $TOOL represents the position of the remote TCP with respect to the world frame (Fig. 5.12 - Remote Tool System).

Fig. 5.12 - Remote Tool System

1 - Flange Frame 2 - User Frame 3 - TCP Frame 4 - Fixed Tool 5 - Base Frame

In cartesian movement ($BASE, $TOOL, $UFRAME), WITH ENABLED REMOTE TOOL, while programming robot movement it is necessary to consider the remote tool virtual motion, INSTEAD OF the actual robot motion.Example: WITH ENABLED REMOTE TOOL, to be able to execute a Z+ motion in $BASE Frame of reference (which means Z upward motion), robot must move along Z downward, because, in such a way, it is a virtual upward movement of the remote tool (which is actually fixed!): this means Z+ in $BASE as requested by the user.

73pr-0-0-gpr_04.fm

00/0210

Motion Control

5.12 Integrated MovementWhen the base of a robot is mounted on another mechanism in order to extend the work envelope, integrated management of the two mechanical systems is possible. Two situations may arise according to whether the mechanism that transports the robot consists of a single auxiliary axis (integrated axis) or of a second robot (integrated arms).

1. Slide Base Reference2. Robot Base3. User Reference4. World Reference5. Side View6. Top View7. Column rotation8. Rotating Column9. Column Base Reference10. Robot Base11. User Reference12. World reference13. Rotating Column14. Column rotation15. Slide

5.12.1 Integrated Axis

A robot can be mounted on an auxiliary axis in order to extend the work envelope. The

74pr-0-0-gpr_04.fm

00/0210

Motion Control

axis may be a slide (translating axis) or a Rotating Column.

In such a situation, it is possible to integrate the auxiliary axis in the movement of the robot. This means that the cartesian position of the robot is calculated taking into account the position of the auxiliary axis and therefore in relation to a reference integral with the floor of the cell (WORLD reference), rather than with the base of the robot. Practically speaking, it will be possible to move the TCP along a linear or circular path while the slide/column is moving or to move the slide/column keeping the TCP still in relation to the floor: in both cases, the robot axes will offset the movement of the auxiliary axis.The system sees the set of axes of the two mechanisms as a single manipulator. All the types available, i.e. JOINTPOS, POSITION, XTNDPOS, can be used to assign the destination positions of the movements. In the case of XTNDPOS, it is also possible to specify the cartesian position of the TCP as well as the position of the auxiliary axis at the same time.

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.

5.12.1.2 Reference Systems

With the slide/integrated column, the base reference of the system of axes (defined using the $BASE variable) is located at the base of the slide/column. The other reference systems remain unchanged as described in Frames of Reference section and shown in following Fig. 5.13 - Base Reference System – integrated axes.

Fig. 5.13 - Base Reference System – integrated axes

1 - Rotating Arm Radius (R) 2 - Right-hand rotation of the Column3 - Column Height (H) 3 - Left-hand rotation of the Column

For the configuration parameters, see the Chap. Use of Positioners managed by C5G.

75pr-0-0-gpr_04.fm

00/0210

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).

5.13 Palletizing functionality (optional feature)

This optional feature allows using as a PALLETIZER, any anthropomorphic or parallelogram robots, with 6 axes, spherical wrist.

The robot moves always keeping the flange parallel to the floor (with the TOOL z) downward; axis 4 is NOT used.

Such a functionality allows to reduce the cycle time and to perform mixed trajectories (both with and without FLY).

The wrist (W) configuration flags are NOT taken into consideration, making programming easier.

To use such a functionality, it is needed:

– purchasing the software option,

– spherical wrist SMART robot,

– moving the robot to have:• axis 4 set to 0 • orientation set to <0, 180°, E3> (which results, depending on the robot,

adding joints 2, 3 and 5);

– no pending movements on the corresponding Arm,

– setting $JNT_MTURN flag (minimum path joint trajectory) to FALSE.

If one or more of the listed above conditions are not satisfied, an error occurs.

The following topics are now described:

– Enabling

– Disabling

– Example of a Palletizing Program.

Note that it is possible to use the robot either in standard functioning (anthropomorfic/parallelogram with 6 degrees of freedom) or as a Palletizer (4 degrees of freedom), just by modifying the machine configuration, with no needs of restarting it.

76pr-0-0-gpr_04.fm

00/0210

Motion Control

5.13.1 Enabling

a. Move the robot (the functionality must be disabled) to the required position to enable it,

b. issue the enabling command in one of the following ways:– from within a PDL2 Program - call ARM_PALLETIZING (ON, <arm_num>)

built-in routine to activate the functionality for Arm “arm_num”

– 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.

Fig. 5.14 - Palletizing Funtionality on the TP - enabling

c. Verify that in the sixth field of the TP status bar, Pallet is now specified (see Fig. 5.15 - purple highlighted field).

5.13.2 Disabling

To disable the Palletizing Functionality and recover the usual robot functioning again, it

For further information, please refer to PDL2 Programming Language manual - BUILT-IN Routines List chapter.

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.

First of all, it is needed that there are NO PENDING MOVEMENTS.

77pr-0-0-gpr_04.fm

00/0210

Motion Control

is needed to issue the disabling command in one of the following ways:

– from within a PDL2 Program - call ARM_PALLETIZING (OFF, <arm_num>)built-in routine to deactivate the functionality for Arm “arm_num”

– 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.

Fig. 5.15 - Palletizing Functionality on TP - disabling

5.13.3 Example of a Palletizing Program

PROGRAM test_arm_palletizing VAR pnt0006P, pnt0007P : POSITION pnt0001P, pnt0002P, pnt0003P, pnt0004P, pnt0005P : POSITION

BEGIN

$JNT_MTURN := FALSE

ARM_PALLETIZING(ON,1)MOVE JOINT NEAR pnt0002P BY 300MOVEFLY LINEAR TO pnt0002P ADVANCEMOVEFLY LINEAR NEAR pnt0003P BY 20 ADVANCEMOVE LINEAR TO pnt0003P

MOVEFLY LINEAR AWAY 400 ADVANCEMOVEFLY JOINT TO pnt0004P ADVANCEMOVEFLY LINEAR TO pnt0005P ADVANCEMOVEFLY LINEAR NEAR pnt0006P BY 300 ADVANCEMOVEFLY LINEAR TO pnt0006P ADVANCEMOVEFLY LINEAR NEAR pnt0007P BY 20 ADVANCEMOVE LINEAR TO pnt0007PMOVEFLY LINEAR AWAY 1000ARM_PALLETIZING(OFF,1)

END test_arm_palletizing

For further information, please refer to PDL2 Programming Language manual - BUILT-IN Routines List chapter.

78pr-0-0-gpr_04.fm

00/0210

Synchronous Motion (optional feature)

6. 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

6.1 Synchronization with Auxiliary AxesIf the axes belong to the same robot arm they are called auxiliary axes and they always move in a synchronized way with the robot. This means that all the axes start and stop at the same time.

The movement can be programmed with the JOINTPOS data type, which contains the joint position of each axis, or by means of the XTNDPOS data type which is composed of a Cartesian position for the robot and an ARRAY of joint values for the remaining axes. The use of XTNDPOS data type is recommended.

6.2 Synchronized ArmsThe motion of two arms is said to be time synchronized when they start and stop together. To program synchronized motions of two arms the SYNCMOVE clause on the MOVE statement has been implemented.

This feature is useful, for example, in a double P-MAST workcell with the two arms carrying a single workpiece. In addition this feature is necessary for cooperative motion (see par. 7.1 Cooperative Motion with Auxiliary Axes on page 84).

The Arms involved in synchronised motion are:

– MASTER Arm - it is always the arm that executes the MOVE;

– SERVER Arm - it is always the arm that executes the SYNCMOVE.

In the following synchronised MOVE:

MOVE ARM[1] LINEAR TO PNT0001P SYNCMOVE ARM[2] JOINT TO PNT001J

the MASTER Arm is ARM[1] and the SERVER Arm is ARM[2]; whereas in the next synchronised MOVE :

MOVE ARM[2] LINEAR TO PNT0001J SYNCMOVE ARM[1] JOINT TO PNT001P

79pr-0-0-gpr_07.fm

00/0210


the MASTER Arm is ARM[2] and the SERVER Arm is ARM[1].All this does not depend on the declared (or implied) Arm, PROG_ARM, at the head of the program.

The system variable $SYNC_ARM specifies the default synchronized arm for the SYNCMOVE clause, similar to $PROG_ARM that defines the default arm for the MOVE statement. This variable is specific for the program and initialized by the user. For example, in writing MOVE TO p1, since the arm has not been specified, the value of $PROG_ARM is assumed. Similarly, in writing SYNCMOVE TO p2, since the arm for the SYNCMOVE has not been specified, the value of $SYNC_ARM is assumed.

An example follows of a program that controls two Arms that move in synchronised mode:

PROGRAM exampleBEGIN-- 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 p1MOVE 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 p2MOVE 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.

6.3 Motion limitation of the two ArmsThe combined motion of the two Arms imposes motion limitation. The following table highlights the parameters that limit the motion in two frequent situations :

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

MASTER Arm trajectory $SPD_OPT value Limiting arm

joints or Cartesian SPD_JNT or SPD_CONSTArm with more restrictive parameters

Cartesiandifferent to SPD_JNT and to SPD_CONST

MASTER Arm

80pr-0-0-gpr_07.fm

00/0210


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.

6.4 Jogging Synchronized ArmsIn a double arm system the user may activate two arms (DRIVES ON) and then jog each of them. Before switching to DRIVES ON it is required to select the main arm (stored in $TP_SYNC_ARM[1]) and the synchronized arm (stored in $TP_SYNC_ARM[2]). This has to be performed from the Motion page, Basic sub-page, on the Teach Pendant if the SYNCARM option has been acquired. If $TP_SYNC_ARM[2] is set to zero, only one arm will be used, i.e. $TP_SYNC_ARM[1].

The arm specified in the Teach Pendant status bar, can be moved with the manual keys. To pass from one arm to the other, the required Arm has to be either specified in the Arm field of the Motion page, Basic sub-page, or using the Arm key (if needed SHIFT+Arm) available in the Right Menu of the Teach Pendant. For further information, see the C5G Control Unit Use - par. Use of the Teach Pendant - Right menu.

6.5 Teaching and Modifying Positions (REC/MOD) with Synchronized ArmsThe enabling and disabling of the SYNCMOVE teaching are selected through either IDE Page (‘Selection - REC Setup’ command), or Program Edit and Memory Debug environments, under item DEBUG SETUP SYNC. When disabled, by pressing the REC key, MOVE ARM[#] TO p1 is taught, where # is the number of the selected arm. Enabling the teaching of SYNCMOVE, by pressing the REC key the MOVE ARM[#] TO p1 SYNCMOVE ARM[&] TO p2 is taught, where # is the number of the $TP_SYNC_ARM[1] value and & is the value of $TP_SYNC_ARM[2] (regardless of the ARM currently selected). Tab. 6.1 - Teach examples (REC key)illustrates some teach examples.

For further information, please refer to C5G Control Unit Use manual, IDE Pagesection.

Tab. 6.1 - Teach examples (REC key)

Main Arm Action

1 teaches “MOVE ARM[1] TO p1"

2 teaches “MOVE ARM[2] TO p2"

1 teaches “MOVE ARM[1] TO p3 SYNCMOVE ARM[2] TO p4"

2 teaches “MOVE ARM[2] TO p4 SYNCMOVE ARM[1] TO p5"

81pr-0-0-gpr_07.fm

00/0210


6.6 Loss of SynchronizationThe cases in which loss of synchronization between several arms occurs are described below. The first case is that of the TIL clause that can be applied either to the main arm or to the synchronized one; when the event associated with the TIL clause triggers, the related movement is cancelled and the synchronization is lost. If, during a synchronized motion, the CANCEL statement is executed, the main arm motion is cancelled, while the synchronized one continues, hence synchronization is lost. If the user needs to cancel both, he must cancel the move on both arms.

If the user locks (with LOCK statement) one arm during a synchronized move, the synchronization is lost. To maintain the synchronization, he must lock both the arms, with the statement:

LOCK ARM[1], ARM[2]

This is not equivalent to:

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]).

6.7 Run-time modifying the Linear Speed Overridew

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

MOVE ARM[i] TO P1 SYNCMOVE ARM[j] TO P2

we have three possibilities:

a. BOTH the Arms AREN’T a Robot

b. ONE Arm ONLY IS a Robot

c. BOTH the Arms ARE Robots.

A functionality exists which allows, under some special conditions, to run-time modify the Linear Speed Override. For further information see also par. 5.5.2.2 Run-Time modifying the Linear Speed Override on page 56.

82pr-0-0-gpr_07.fm

00/0210


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.

a. no Run-time modifications are allowed for linear speed

b. the Run-Time modification of the linear speed is allowed on the Robot only (using the $LIN_SPD_RT_OVR predefined variable which is associated to such an Arm)

c. the Run-time modification is allowed on the Arm which is executing a cartesian motion. Anyway it is always needed to use the $LIN_SPD_RT_OVR predefined variable which is associated to the Arm on which the Run-time modification functionality is active.

83pr-0-0-gpr_07.fm

00/0210

Cooperative Motion (optional feature)

7. COOPERATIVE MOTION (OPTIONAL FEATURE)

The cooperative motion feature simplifies the programming of applications where a workcell is composed of a robot and one or more positioners (i.e. a rotating table). When cooperative motion is enabled, the robot position is defined with respect to the positioner so that Cartesian trajectory can be executed at constant speed while moving the workpiece. This is mainly useful in welding complex shapes or large workpieces.

A general rule can be followed in the case of cooperative motion: the $UFRAME transformation defines the position of the workpiece with respect to the flange frame of the active positioner and not with respect to the world frame. This is shown in (Fig. 7.1 - System frames with auxiliary axes cooperative motion and Fig. 7.2 - User frame with auxiliary axes cooperative motion). This is because the user frame is not fixed but is linked with the positioner.

Cooperation can be enabled between a robot and its auxiliary axes or between two different arms.

This chapter describes the following subjects :

– Cooperative Motion with Auxiliary Axes

– Cooperative Arms

– Multi-cooperative motion

– Jogging

7.1 Cooperative Motion with Auxiliary AxesIf the robot and the positioner are organized in a single arm workcell, the positioner axes are controlled by means of XTNDPOS data types as auxiliary axes. The cooperative motion for this type of positioner can only be enabled after the positioner has been correctly configured. The $AUX_BASE system variable is an array of POSITION used to define the location of the bases of the positioners with respect to the world.

Fig. 7.1 - System frames with auxiliary axes cooperative motion

84pr-0-0-gpr_08.fm

04/0711


1 - Positioner Flange Frame 2 - Positioner 1 3 - Positioner 2

Fig. 7.2 - User frame with auxiliary axes cooperative motion

1 - User Frame 2 - Positioner Flange frame 3 - Positioner Base Frame

To enable and disable cooperative motion, the following built-in procedure is available:

AUX_COOPAUX_COOP(flag, joint_aus <<, arm>>)

The data type for the flag is boolean. It can be set to ON or OFF for switching the auxiliary cooperative motion on or off. Aux_joint field is the number of the last axis composing a positioner.

The arm field is the arm on which the auxiliary cooperative motion should be executed, if not explicitly defined, $PROG_ARM is used.

For example, in a system with a 5-axes robot, a first 2-axes positioner (axis 6, 7) and a second 1-axis positioner (axes 8) the syntax could be the following:

AUX_COOP(ON, 7) -- enables the cooperative motion with the first -- positioner

AUX_COOP(ON, 8) -- disables the previous cooperative motion end -- enables the cooperative motion with the

-- second positionerAUX_COOP(OFF) -- disables the cooperative motion

7.2 Cooperative ArmsThe cooperative motion between two arms of the same work cell controlled by the C5Gcan be enabled defining the first arm as the working arm and the second one as positioner arm. The working arm trajectory will be computed with respect to the flange of the positioner arm.

To enable and disable cooperative motion between two arms, the following built-in procedure is available:

ARM_COOP(flag <<, arm_posizionatore <<, arm_lavoro>>>>)

The data type of flag is boolean. It can be ON or OFF to enable and disable the cooperation. The second parameter is optional and specifies the positioner arm. If the positioner arm is not specified, the value of the $SYNC_ARM system variable is assumed. The third parameter is optional and specifies the working arm. If the working arm is not specified, the value of the $PROG_ARM system variable is assumed.

Cooperation can be performed independently from the synchronization of the arms by

85pr-0-0-gpr_08.fm

04/0711


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).

Fig. 7.3 - System frames with cooperative Arms

1. 1 - Working Arm 2 - Positioner Arm

7.3 Multi-cooperative motionThe word Multi-Cooperative means the possibility, for 2 ARMs, to cooperate together with the same group of auxiliary axes (e.g. a positioner) belonging to one of the two Arms.

NO MORE than 2 Arms can be involved in the multi-cooperation.

To enable/disable multi-cooperative motion, the following built-in routine must be used:

ARM_MCOOP(flag<, aux_joint<, positioner_arm<, working_arm>>>)

where

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.

86pr-0-0-gpr_08.fm

04/0711


For further information, please refer to PDL2 Programming Language manual, chap.BUILT-IN Routines List.

Fig. 7.4 - System frames with multi-cooperative Arms

1. Working Arm2. 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 JoggingCooperative 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 (Executesoftkey) on the Teach Pendant.

Very important requirement for using multi-cooperation, is the proper positioning, inside the cell, of all the involved objects, which means to properly assign both $BASE and $AUX_BASE (see Fig. 7.4).

87pr-0-0-gpr_08.fm

04/0711

Sensor Tracking (optional feature)

8. SENSOR TRACKING (OPTIONAL FEATURE)

The "Sensor Tracking" environment allows real-time correction of the Cartesian trajectory based on indications coming from various sensors. The main characteristics are:

– possibility to interface with a wide range of sensors (integrated in C5G, analog I/Os, serial ports);

– projection of corrections in all the main reference systems (tool, user, world, weaving);

– translation corrections and geometry variations;

– relative and absolute corrections;

– control possibilities with and without programmed move;

– sensors dedicated to each arm in multi-arm applications;

– possibility to configure the robot dynamic response;

– compliance to safety restrictions;

– complete compatibility with other C5G services.

Detailed information follows regarding these subjects:

– Principle of operation

– Configuration on several arms

– Sensor interface

– Sensor reference system

– Type of information acquired by the sensor

– Correction actuation criteria

– Sensor tracking enable mode

– Sensor malfunctioning

– Accumulative overall deviations management

– Programming example

8.1 Principle of operationDuring normal operation, the robot is controlled on a programmed position that is periodically updated at each interpolation period ($IPERIOD predefined variable). The sensor tracking environment allows the robot to progressively move away from this position concordantly with the requests coming from a sensor. This is obtained keeping a deviation vector (overall deviations) that is applied to the nominal programmed position.

The vector is composed of 6 components; the first three are the deviations in X, Y and Z directions and the other three the rotations around the same axes. To better understand the effect of sensor tracking, let us consider an application where there is a programmed trajectory and a sensor that can bring the TCP on an optimised trajectory

88pr-0-0-gpr_10.fm

00/0210


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 sensorVAR

p1, p2, p3, p4 : POSITIONBEGIN

$SPD_OPT:=LIN_SPD--To check the linear speed$LIN_SPD:=0.1 --Linear speed in m/sMOVE JOINT TO p1MOVEFLY LINEAR TO p2 ADVANCE

MOVE LINEAR TO p3MOVE 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.

Fig. 8.1 - Programmed trajectory and sensors control

1. Starting point2. Arrival point3. Programmed trajectory4. Trajectory controlled by sensor

8.2 Configuration on several armsC5G can control several robots at the same time (multi-arm system); to do so, the sensor tracking can be enabled separately on different arms by system variables that are $ARM_DATA and Built-In fields that allow the arm referred to as an optional parameter .All the variables are listed in Tab. 8.1 - System variables for Sensor

89pr-0-0-gpr_10.fm

00/0210


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.

8.3 Sensor interfaceA sensor is suitable for sensor tracking applications if it is able to measure one or more physical values and obtain from them geometrical information regarding the optimal position, i.e. calculate the error between the actual TCP position and the optimal position on the workpiece. A sensor may be integrated in the system at different levels; it is therefore possible to distinguish between INTEGRATED sensors and EXTERNAL sensors. The $SENSOR_TYPE system variable distinguishes between these two possibilities.

8.3.1 Integrated Sensors

Some sensors are pre-set for integration into the control system hardware. These devices are integrated sensors if the communication between sensor and control system is managed by system software and not only by PDL2 programs. The intgegrated handling allows real-time correction of the robot trajectory exploiting the reading of the arc current/voltage during high frequency weaving (Cartesian or joints weaving). In this configuration the torch is kept on the being welded joint by subsequent corrections in two directions: crosswise and vertical to the trajectory.

Tab. 8.1 - System variables for Sensor Tracking

Name Type Limits Default WITH

$SENSOR_ENBL BOOLEAN True-False False YES

$SENSOR_TYPE INTEGER [ 0, 30 ] 0 YES

$SENSOR_CNVRSN ARRAY [6] OF REAL [ -inf, +inf ] 0 NO

$SENSOR_GAIN ARRAY [6] OF INTEGER [ 0, 100 ] 00 NO

$SENSOR_TIME INTEGER [ 0, 10000 ] 0 ms YES

$SENSOR_OFST_LIM ARRAY [2] OF REAL [ 0, +inf ] [0,0] mm, degrees NO

$SFRAME POSITION null position YES

Tab. 8.2 - Built-In for Sensor Tracking

SENSOR_SET_DATA ( err_track <,arm> )

SENSOR_GET_DATA ( sens_read <,flag <,arm>> )

SENSOR_GET_OFST ( ofst_tot <,arm> )

SENSOR_TRK ( bool <,arm> )

Where:– errp_track, sens_read, ofst_tot are ARRAY[6] OF

REAL– flag is an INTEGER value in read– arm is INTEGER type

90pr-0-0-gpr_10.fm

00/0210


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:

$SENSOR_GET_DATA ( sens_read <, flag <, arm>> )

This copies the six components of the vector coming from the sensor into the sens_read parameter: the first three elements correspond to the translations in X, Y and Z directions and the others are the rotation around axes X, Y and Z.

If the sensor is only able to control some of the six components, the others will remain at a value zero. The optional flag parameter is set to value 1 if the data is new i.e. it has never been read by a previous SENSOR_GET_DATA instruction. Otherwise it is set at 0. The optional arm parameter selects the data relating to an arm that is not the default one.

8.3.2 External sensors

External sensors are those which are not integrated in the Control System Hardware. Examples of this type of sensors are:

– Simple limit switches or binary proximity sensors that give a single digital datum (they change the signal when the distance measured exceeds a certain threshold);

– Capacitive or inductive proximity sensors that communicate by an analog input or by coded information on several digital inputs;

– Sensors connected to the control system by a communication line managed by a PDL2 program. The two-three dimension cameras may belong to this category since they usually have a dedicated controller, that makes the necessary calculations to interpret the image, and a communication line to receive the commands and transmit the information.

These types of sensors have the characteristic that the reading of the information is performed by a PDL2 program (usually NOHOLD), created specifically for the sensor.

The $SENSOR_TYPE values reserved for this type of sensor are included between 5 and 12 (see Tab. 8.3 - Correction_Speed = Factor*Reference_Speed). To send the correction request to the movement environment the following Built-In has been introduced :

SENSOR_SET_DATA ( err_track <, arm> )

The err_track parameter is the vector of the corrections required, the first three elements correspond to the translations in X, Y and Z directions, whereas the others are the rotations around the same axes.

The unused err_track components have to be initialised in any case to value zero. With the optional "arm" parameter corrections can be sent to an arm that is not the default one. The Built-In SENSOR_GET_DATA, described in the previous paragraph can also be used with this type of sensors. In this case the sens_read variable will contain the same data as sent with SENSOR_SET_DATA.

8.4 Sensor reference systemThe sensors measure the deviations in relation to a reference system that depends on

91pr-0-0-gpr_10.fm

00/0210


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 .

8.4.1 Sensor integral with the tool (TOOL)

This type of reference is used when the sensor is mounted on the tool itself.

– This is the case of a proximity sensor mounted on the tip of the tool or a laser camera on the welding torch. The most frequent case is the arc parameters sensor in the arc height control mode or with joint type weaving; in the latter case the TOOL reference has to be used because if the weaving is joints type, a weaving reference system is not defined (therefore it would not make sense to use the mode in WEAVE reference).

The $SENSOR_TYPE values reserved for this reference are: 1 for seam-tracking (not available in 1.0 sw version), 5 and 9 for external sensors (Tab. 8.3 - Correction_Speed = Factor*Reference_Speed).

In these tracking modes (TOOL reference) the reference system that describes the TCP position ($TOOL variable) can be distinguished from the reference in which the sensor makes the measurements.

To do this there is the $SFRAME system variable. This is a conversion of co-ordinates referred to the TCP reference system, since it follows $TOOL in the kinematic chain (see Fig. 8.2 - Tool frame conversion).

Fig. 8.2 - Tool frame conversion

1. Flange2. Tool3. Sensor4. Sensor frame5. TCP frame

8.4.2 Sensor integral with the user reference system (USER)

With this possibility the corrections can be projected in relation to the user reference system defined by the $UFRAME system variable.

– This case also includes sensors that are mounted in a fixed position as to the work station or that are handled by kinematics that permit the measures executed to be brought back to the USER reference system .

$SENSOR_TYPE can enable this modality only for external sensors with codes 6 and 10 (see Tab. 8.3 - Correction_Speed = Factor*Reference_Speed).

92pr-0-0-gpr_10.fm

00/0210


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).

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.

8.4.3 Sensor integral with the world reference system (WORLD)

This is an extension of the USER case. This mode permits the projection of the corrections in relation to the world reference system - the system to which $BASE and $UFRAME refer. The values of $SENSOR_TYPE for this mode, for external sensors only , are 7 and 11 (Tab. 8.3 - Correction_Speed = Factor*Reference_Speed).

8.4.4 Sensor integral with the weaving reference system (WEAVE)

This is exclusively for arc parameter sensors with Cartesian type weaving. In this case the sensor makes the measurement through the torch; it is independent in its orientation but depends on the direction of the weaving. The corrections calculated have to be projected, not in the torch reference system (TOOL) but with regard to the weaving (WEAVE).

The $SENSOR_TYPE values for this type of reference are 2 for seam-tracking (not available in 1.0 sw version), 8 and 12 for external sensors (see Tab. 8.3 - Correction_Speed = Factor*Reference_Speed).

8.5 Type of information acquired by the sensorThe most sophisticated sensors give Cartesian corrections directly in millimetres, whereas others just give the measurement of the physical value that, in the most frequent cases, is directly proportional to the distance measured. In such cases the C5Gautomatically converts the data read by the sensor (for example ampere, Newton, etc.) to corrections in millimetres through the $SENSOR_CNVRSN system variable. This is

93pr-0-0-gpr_10.fm

00/0210


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).

8.6 Correction actuation criteriaThere are three elements that regard the actuation of the corrections: the first is to distinguish between relative and absolute deviations; the second is for the mode in which a correction is actuated in time; the third is to check the overall deviations between the programmed position and the position reached under the control of the sensor.

The following subjects are described:

– Relative and absolute deviations

– Actuation of deviation in time

– Overall deviations control

8.6.1 Relative and absolute deviations

The deviations are considered ABSOLUTE if the correction is requested regarding the nominal trajectory of the robot, i.e. that which is programmed (Fig. 8.4 - Absolute deviations). The term RELATIVE deviations means a correction that is made with reference to the current robot position, i.e. without taking into consideration the error already accumulated during previous sensor readings (Fig. 8.5 - Relative deviation).

Fig. 8.4 - Absolute deviations

1. Programmed trajectory2. Trajectory controlled by sensor 3. Correction required = +3 mm

94pr-0-0-gpr_10.fm

00/0210


4. Required = +1 mm5. Required = -2 mm6. Final deviation = 0 mm7. Required = 0 mm

Fig. 8.5 - Relative deviation

1. Programmed trajectory2. Trajectory controlled by sensor 3. Correction required = +3 mm4. Required = +1 mm5. Required = -2 mm6. Final deviation = 0 mm7. 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).

8.6.2 Actuation of deviation in time

Corrections measured by the sensor may also be several millimetres, especially if the frequency at which the information is read is low. Therefore, in some cases it is not possible to apply the entire deviation in one interpolation operation. There are two possible rules for the distribution of the deviation during the move execution:

– define the speed (SPEED) at which the correction will be performed;

95pr-0-0-gpr_10.fm

00/0210


– 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.

Fig. 8.6 - Effects of $SENSOR_TIME (with relative corrections)

1. Programmed trajectory2. 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

96pr-0-0-gpr_10.fm

00/0210


correction (0%) and immediate assimilation of the correction (100%).

If $SPD_OPT is set for one of the rotation control modes (SPD_ROT, SPD_SPN, SPD_AZI, SPD_ELV, SPD_ROLL, SPD_FIRST, SPD_SECOND, SPD_THIRD) the reference speed for the first three components of $SENSOR_GAIN is one fourth of the maximum linear speed for that arm ($LIN_SPD_LIM/4).

The last three elements of $SENSOR_GAIN serve to control the speed of rotation around the X, Y and Z axes. If it is $SPD_OPT=SPD_LIN, the reference speed is a quarter of the maximum rotational speed ($ROT_SPD_LIM/4) thus the value of 50% corresponds to a speed equal to $ROT_SPD_LIM/4 whereas the values 0% and 10% represent the extreme cases of no correction (0%) and immediate assimilation of the geometry variation (100%). If $SPD_OPT is set to one of the rotation control modes (SPD_ROT, SPD_SPN, etc.) the reference speed for this component is $ROT_SPD.

Tab. 8.3 - Correction_Speed = Factor*Reference_Speed contains the multiplication factors that, applied to the reference speed, make it possible to obtain the actual programmed speed. These values are given as an explanation only, since in practice, the value of $SENSOR_GAIN will be determined by experimentation .

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%.

Fig. 8.7 - Effects of $SENSOR_GAIN

1 - Programmed trajectory 2 - Trajectory controlled by sensor 3 - Maximum speed 4 - Time increase

Tab. 8.3 - Correction_Speed = Factor*Reference_Speed

$SENSOR_GAIN[ i ] Factor

0102030405060708090

100

0.00.110.250.430.671.01.52.34.09.0

infinite

97pr-0-0-gpr_10.fm

00/0210


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.

8.6.3 Overall deviations control

The overall deviation has already been defined as a vector with 6 elements that represent the actual position of the robot in relation to its programmed position. This vector can be read through the following Built-In:

SENSOR_GET_OFST ( ofst_tot <, arm> )

The first three components of ofst_tot are the deviations in X, Y and Z directions, and the other three components are the rotations around the same axes. The optional arm parameter can be used to read the data of an arm that is not the default one.

This deviation vector will always refer to the USER reference system (the system defined by $UFRAME by which all POSITIONs are defined) regardless of the $SENSOR_TYPE value.

8.7 Sensor tracking enable modeThe sensor tracking can be activated on Cartesian trajectories only (LINEAR or CIRCULAR) or, in certain situations, when there is no programmed move. The sensor tracking is enabled by the $SENSOR_ENBL system variable. This can be assigned a BOOLEAN type value (TRUE to enable and FALSE to disable). The variable can be used alone in a single program line ( $SENSOR_ENBL:=TRUE/FALSE) or together with a MOVE instruction with the WITH (MOVE LINEAR TO p1 WITH $SENSOR_ENBL=TRUE/FALSE). The enabling and disabling of the tracking is closely linked to the holding or the resetting of the overall deviations (see par. 8.9 Accumulative overall deviations management on page 101”).

The standard enable mode of sensor tracking permits the application of corrections read by the sensor only during the execution of a programmed move and therefore the sensor is ignored when the robot is stationary (even if in DRIVES ON). This is the mode most frequently used in practical applications.

However, there are certain applications where it is necessary that the robot position is enslaved to the sensor even without a programmed move.

– a typical example is when the robot has to be latched to a moving object, or it interacts with the workpiece without movement of any controlled axes, but closing grippers or moving additional axes;

– there are also sensors that can move the robot autonomously without the need of a programmed move.

C5G is preset for this type of application, offering the possibility to enable the arm in a certain state in which it is completely enslaved to the sensor although still having the possibility to resume the programmed move at any time.

When introducing this service complete consistency of behaviour has been maintained with that already possible in C5G in compliance with safety requirements. In particular

98pr-0-0-gpr_10.fm

00/0210


the following points are highlighted:

a. robot enslaving to a sensor without a programmed move can only be enabled by a HOLDABLE program with the Control Unit in AUTO;

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;

d. the enslaving terminates when the program that started it is deactivated.

These services have been obtained by introducing a special type of Built-In that can only be executed by HOLDABLE. programs. The syntax is:

SENSOR_TRKSENSOR_TRK ( boolean <, arm> )

The execution of the SENSOR_TRK(TRUE) instruction selects a certain option so that, enabling the sensor tracking with the $SENSOR_ENBL variable, the arm is in an extended mode that permits enslaving even without a programmed move.

The optional arm parameter can enable the service on an arm that is not the default one.

There are the following limitations (they refer to the Built-In executed always on the same arm):

a. the actual enabling of the enslaving without a programmed move is subordinated to the value of $SENSOR_ENBL (however, it is not necessary to re-run SENSOR_TRK(TRUE) after bringing $SENSOR_ENBL to FALSE and then to TRUE);

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;

c. the service disabling through SENSOR_TRK(FALSE) can be executed only from the same program that enabled it;

d. SENSOR_TRK cannot be executed if it is already enabled by a second HOLDABLE program that is active at the same time;

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).

8.8 Sensor malfunctioningThere are two characteristics of the sensor tracking environment that help to minimise the negative consequences of a sensor malfunctioning: the first makes it possible to stop the robot, the second to redefine the correct deviations before resuming the interrupted program.

Description of the following subjects:

– Robot stop in the case of sensor malfunctioning

99pr-0-0-gpr_10.fm

00/0210


– Redefinition of overall deviations

8.8.1 Robot stop in the case of sensor malfunctioning

In cases where the sensor is not reliable or is subject to disturbances, it could happen that the robot moves too far from the programmed position with the risk of damaging the fixture. For this situation the $SENSOR_OFST_LIM system variable has been provided. It consists of 2 REAL type elements that indicate the maximum deviation allowed between the programmed trajectory and the robot guided by the sensor. The first element is for the translations (along X, Y and Z axes) and is in millimetres; the second is for the rotations and is in degrees. When the limit of any of these components is passed, an error message is sent and the robot is stopped in HOLD condition.

8.8.2 Redefinition of overall deviations

When examining error situations caused by malfunctioning of sensors, cases have been noted where it is necessary to reassign the value of the accumulated deviations. In particular this is indispensable when, because of a sensor error, the robot is taken away from the optimal trajectory until it stops because it has exceeded the maximum thresholds ($SENSOR_OFST_LIM). In these conditions the robot can be brought back to the correct position and resume the running of the program by using two special modes to restore the trajectory ($RCVR_TYPE).By setting $RCVR_TYPE=7 the correct position can be redefined, bring the robot back to the trajectory with the Teach Pendant and starting again: the interrupted movement will be picked up again exactly from that position with no recovery. The deviations will be automatically redefined with a new value. Fig. 8.8 - Effect of $RCVR_TYPE = 7shows the procedure.

Fig. 8.8 - Effect of $RCVR_TYPE = 7

1. Programmed trajectory2. Trajectory controlled by sensor 3. Trajectory after a sensor failure4. Optimal trajectory5. 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

100pr-0-0-gpr_10.fm

00/0210


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.

Fig. 8.9 - Effect of $RCVR_TYPE = 8

1 - Programmed trajectory 2 - Trajectory controlled by sensor 3 - Recovery trajectory 4 - HOLD caused by an error message

8.9 Accumulative overall deviations management In the par. 8.1 Principle of operation on page 88 a brief description has been given of the procedure in which the robot position is modified according to the indications of a sensor. Below it is explained how the enabling and disabling of tracking can interact with the holding or resetting of overall deviations. To do so, it is necessary to introduce the following concepts: interrupted sensor tracking session (INTERRUPTED), suspended session (SUSPENDED) and the spread resetting of the deviations (RESETTING SPREAD) .

The following subjects are described below:

– Interrupted sensor tracking session

– Suspended sensor tracking session

– Resetting in spread condition

– Limitations in parameter changes

8.9.1 Interrupted sensor tracking session

A sensor tracking session is considered interrupted when, during SENSOR_TRK(FALSE), the robot stops on a position without the move that took it to that position being in ADVANCE and where the FLY clauses have not been defined.

The interruption of the tracking is important because with this event an acquisition is made of the TCP actual position, with the consequent resetting of the deviations.

To understand the effect of an interruption, compare Fig. 8.10 - Interrupted sensor tracking session with Fig. 8.1 - Programmed trajectory and sensors control; the

101pr-0-0-gpr_10.fm

00/0210


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.

Fig. 8.10 - Interrupted sensor tracking session

1 - Programmed trajectory 2 - Trajectory controlled by sensor 3 - Starting point 4 - Arrival point 5 - New nominal trajectory

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).

8.9.2 Suspended sensor tracking session

There are some cases where it is necessary to ignore the sensor corrections along a complete move although keeping the deviations acquired up to that moment. This can be obtained by setting $SENSOR_TYPE:=0 along the move involved (obviously interruption must be avoided linking the movements in fly or entering SENSOR_TRK(TRUE)). Fig. 8.11 - Suspended sensor tracking session illustrates this operation.

Fig. 8.11 - Suspended sensor tracking session

1 - Programmed trajectory 2 - Trajectory controlled by sensor 3 - Suspended sensor tracking

102pr-0-0-gpr_10.fm

00/0210


8.9.3 Resetting in spread condition

Resetting in spread is the opposite condition to the suspension of a sensor tracking session. The latter allows the deviations to be kept along a linked move in fly, whereas the resetting in spread allows the progressive resetting of deviations terminating the move very close to the nominal programmed point. It is usually used by introducing an interruption (as illustrated in Fig. 8.10 - Interrupted sensor tracking session); however where it is necessary to keep the fly between the moves the $SENSOR_ENBL variable can be set with the FALSE value, resetting mode in spread, along the move; this can also be obtained using the WITH clause on the required move. During the move the sensor is ignored. The effect is shown in Fig. 8.12 - RESETTING SPREAD during a Move.

Fig. 8.12 - RESETTING SPREAD during a Move

1. Programmed trajectory2. Trajectory controlled by sensor3. OFFSET RESET without interrupt

Tab. 8.4 - $SENSOR_TYPE allowed values

$SENSOR_TYPE SIGNIFICANCE

0 Sensor suspended

1 Seam-tracking sensor in TOOL reference (NOT AVAILABLE in 1.0 sw version)

2 Seam-tracking sensor in WEAVING reference (NOT AVAILABLE in 1.0 sw version)

5 External sensor in TOOL reference, relative mode

6 External sensor in UFRAME reference,relative mode

7 External sensor in WORLD reference, relative mode

8 External sensor in WEACING reference, relative mode

9 External sensor in TOOL reference, absolute mode

10 External sensor in UFRAME reference, absolute mode

11 External sensor in WORLD reference, absolute mode

12 External sensor in WEAVING reference, absolute mode

13-14 Reserved

15 Reserved for the management of a certain type of laser camera

16-30 Reserved

103pr-0-0-gpr_10.fm

00/0210


8.9.4 Limitations in parameter changes

When using the sensor tracking there are some conditions that would cause discontinuity in the move, and that are therefore monitored by error messages.

– It is not possible to enable sensor tracking on joint type moves; therefore $SENSOR_ENBL has to be set to FALSE before executing the move.

– A joints move cannot be linked in fly, nor be in ADVANCE, with Cartesian moves where sensor tracking was enabled. In the same way a joints move cannot follow an enslaving phase without a programmed move before the Built-In SENSOR_TRK(FALSE) has been executed to disable it.

– In the absolute tracking mode ($SENSOR_TYPE=9, 10, 11 or 12) the $BASE, $TOOL, $USER or $SFRAME cannot be changed without interrupting the sensor tracking session (see par. 8.9.1 Interrupted sensor tracking session on page 101). On the other hand, the change of reference systems in relative modes does not create any problems.

– It is not permitted to change from relative modes to absolute or vice-versa, without interrupting the Sensor Tracking session. In the same way, it is not possible, in absolute modes, to change the type of reference system in which the tracking is required, without interrupting the enslaving (see par. 8.9.1 Interrupted sensor tracking session on page 101).

8.10 Programming exampleBelow the program already given in the par. 8.1 Principle of operation on page 88 is shown, completed with the instructions needed to configure and enable the sensor tracking. It is assumed to use an external sensor mounted on the torch that is able to calculate corrections in Y an Z directions in relation to the TOOL reference. The system variables that are not shown in the example are left at their default value. The GET_CORR routine, that is not indicated, will be written in PDL2 so as to read the information of the sensor, process it and copy it in the two corr_y and corr_z. parameters

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

104pr-0-0-gpr_10.fm

00/0210


CONDITION[1] : WHEN $TIMER[1] > 500 DO send_corr --Corrections sent every 500 ms ENDCONDITIONcorr[1]:=0; corr[2]:=0; corr[3]:= 0 corr[4]:=0; corr[5]:=0; corr[6]:= 0 --Sensor tracking environment configuration $SPD_OPT := SPD_LIN --to check linear speed $LIN_SPD := 0.1 --Linear speed in m/s $SENSOR_TYPE := 5 --External sensor in relative mode and TOOL reference $SENSOR_CNVRSN[2] := 0.2 --Example of Y conversion factor $SENSOR_CNVRSN[3] := 0.2 -- Example of Z conversion factor $SENSOR_GAIN[2] := 60 -- Example of Y gain $SENSOR_GAIN[3]:= 80 -- Example of Z gain $SENSOR_TIME := 500 -- Deviation distribution in time $SENSOR_OFST_LIM[1] := 50 --Translation maximum limit -- Program in movement MOVE JOINT TO p1 -- Sensor tracking session $TIMER[1] := 0 ENABLE CONDITION[1] $SENSOR_ENBL := TRUE MOVEFLY LINEAR TO p2 ADVANCE MOVE LINEAR TO p3 $SENSOR_ENBL := FALSE DISABLE CONDITION[1] MOVE JOINT TO p4

END sensor

105pr-0-0-gpr_10.fm

00/0210

Conveyor Tracking (optional feature)

106pr-0-0-gpr_11.fm

00/0210

9. CONVEYOR TRACKING (OPTIONAL FEATURE)

For any information about this functionality, please contact Comau.

Motion with Weaving (optional feature)

10. MOTION WITH WEAVING (OPTIONAL FEATURE)

Weaving is an oscillating motion superimposed on a Cartesian trajectory. It is useful for arc-welding applications and some gluing and sealing applications. Weaving is a method used to distribute material in gaps with large cross sections relative to the material bead.

Weaving can be superimposed on any Cartesian motion (either linear or circular) or multiple motions connected in fly. The shape of the weaving pattern is defined by a set of parameters (parametric weaving). Two modes of weaving are available, cartesian weaving and joint weaving.

The subjects described in this chapter are the following :

– Weaving Mode

– Weaving Activation

– Weaving Parameters

– Stopping Motions with Weaving

– Programming Weaving

– Weaving without Arm motion

10.1 Weaving ModeThe weaving mode can be selected through the $WEAVE_TYPE variable Leaving this variable set at default value zero, cartesian weaving is selected. In this mode, weaving is defined relative to a frame determined by the trajectory itself and is not affected by changes in tool orientation along the trajectory. If $WEAVE_TYPE is assigned a value between 1 and 10, the selected weaving is joint mode. In this case, the value of the predefined variable indicates the axis on which the weaving is performed and the weaving direction depends on the position of all axes. Joint weaving allows higher weaving frequencies than cartesian weaving.

10.2 Weaving ActivationWeaving is activated and deactivated using the predefined variable $WEAVE_NUM. This variable contains the number of the active weave table. The default value of 0 means that weaving is disabled.

Weaving is activated by simply assigning the index number of the desired weave table to $WEAVE_NUM. All succeeding Cartesian movements will be performed using the weaving parameters of the active $WEAVE_TBL[$WEAVE_NUM] table.

It is possible to weave during a series of continous motions (fly) or along a path motion. However, weaving will only occur during the Cartesian motions or Cartesian path segments. If a series of fly motions or a path includes a joint interpolated motion, weaving will stop during the joint motion and then start again with the next Cartesian motion or path segment.

The first move with weaving is the movement after a weaving stop. A weaving stop can occur if the user disables it intentionally, or if the movement is a joint motion, or if two

107pr-0-0-gpr_09.fm

03/0111


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).

10.3 Weaving Parameters$WEAVE_TBL predefined variable is used to define all the weaving characteristics. $WEAVE_TBL is an array of records that allows a user to define up to 10 different weave tables. The fields of $WEAVE_TBL are defined as follows:

– $WEAVE_MODALITY the weaving wave form generation modality. It is an INTEGER with possible values 0,1 and 2 :E’ un INTEGER con valori da 0 a 4• $WEAVE_MODALITY=0 - the wave form is generated by the transverse

speed;• $WEAVE_MODALITY=1 - the wave form is generated by the wavelength. In

this case the wave form does not change as the overrides related to the feed speed vary;

• $WEAVE_MODALITY=2 - the wave form is generated with 4 different transverse speeds, to produce asymmetrical profiles.

• $WEAVE_MODALITY=3 weaving con forma d'onda circolare generato dalla velocità trasversale.

• $WEAVE_MODALITY=4 weaving con forma d'onda circolare generato dalla lunghezza d'onda.

– an INTEGER field defines the wave length in the weaving form:• $WV_LENGTH_WAVE (from 0 to 10.000 mm);

– two REAL fields define the left and right amplitudes, in case of trapezoidal weaving: • $WEAVE_TBL[n].WV_LEFT_AMP defines the left amplitude (0 - 20), • $WEAVE_TBL[n].WV_RIGHT_AMP defines the right amplitude (0 - 20);

– two REAL field define the circular wave form:• $WEAVE_TBL[n]. WV_RADIUS defines the weaving amplitude (in mm) in the

trajectory direction in case of circular weaving (it is the semi-minor axis of the ellipse representing the weaving form).

• $WEAVE_TBL[n]. WV_AMPLITUDE defines the weaving amplitude (in mm) in the direction perpendicular to the trajectory in case of circular weaving (it is the semi-major axis of the ellipse representing the weaving form).

– four INTEGER fields define the dwell time: • $WEAVE_TBL[n].WV_LEFT_DWL defines the dwell time (in ms) on the left;

if $WEAVE_MODALITY=1 it defines the distance covered (in mm) on the left along the path. Limits: from 0 to 10,000;

• $WEAVE_TBL[n].WV_CNTR_DWL defines the dwell time (in ms) in the centre; if $WEAVE_MODALITY=1 it defines the distance covered (in mm) at the centre along the path. Limits: from 0 to 10,000;

• $WEAVE_TBL[n].WV_RIGHT_DWL defines the dwell time (in ms) on the right; if $WEAVE_MODALITY=1 it defines the distance covered (in mm) on the right along the path. Limits: from 0 to 10,000;

• $WEAVE_TBL[n].WV_END_DWL defines the dwell time (in ms) at the end of the move; if $WEAVE_MODALITY=1 it defines the distance covered (in mm) at the end of the move, along the path. Limits: from 0 to 10.000;

– a BOOLEAN field controls the corners smoothness of the wave shape (see explanation below):• $WEAVE_TBL[n].WV_SMOOTH ;

– a REAL field controls the transverse speed:

108pr-0-0-gpr_09.fm

03/0111


• $WEAVE_TBL[n].WV_TRV_SPD (recommended 0.035 m/sec);

– four REAL fields for the four transverse speeds that are used in modality 2:• $WEAVE_TBL[n].WV_TRV_SPD_PHASE[m]; (con 1<=m<=4)

– a REAL field defines the weave plane and weave direction (see explanation below):• $WEAVE_TBL[n].WV_PLANE (from -180 to +180 degrees);

– an INTEGER field for the weaving plane evolution modality:• $WEAVE_TBL[n].WV_PLANE_MODALITY defines the modality in which the

weaving plane is calculated. If this variable is set to 0 (default), the weaving plane is kept constant compared to the sequence of the fly connected trajectories. If this variable is set to 1, the weaving plane is calculated on the trajectory and it is integral with the tool and perpendicular to it;

– a REAL field for the weaving direction:• $WEAVE_TBL[n].WV_DIRECTION_ANGLE defines the allowed angle for

the weaving direction in case of either Weaving without Arm motion or in case of weaving plane integral with the tool. The default direction (angle 0) corresponds to the TOOL X direction;

– an INTEGER field defines the weave amplification factor (%):• $WEAVE_TBL[n].WV_AMP_PER (from 0% to 1000%);

– a BOOLEAN field indicates that the acceleration and deceleration characteristics are used• $WEAVE_TBL[n].WV_SPD_PROFILE; using this function the transverse

speeds are reached with a ramp, so as to remain within the acceleration/deceleration limits of the axis involved in the weaving, for joints weave; or within Cartesian acceleration/deceleration limits for Cartesian weave. Furthermore, a test is made on the maximum speed that can be reached. Index n varies from 1 to 10 and the user can change a range of the 10 elements of the table at any time

Parametric weaving is defined by three indications:

– Wave Shape

– Weave Plane (angle of weaving plane)

– Weave Amplification (used to vary the weaving amplitude)

10.3.1 Wave Shape

The basic weave pattern can be either trapezoidal or circular. The units of measurement of some fields of $WEAVE_TBL depend upon the type of selected weaving. If cartesian weaving is being used, $WV_LEFT_AMP and $WV_RIGHT_AMP, $WV_RADIUS and $WV_AMPLITUDE are expressed in millimeters; in case of joint weaving these parameters are expressed in degrees or millimeters depending on whether the selected axis is rotational (degrees) or translational (mm). $WV_TRV_SPD is expressed in meters/second when using cartesian weaving, in radians/second for a rotational axis with joint weaving, and in meters/second for a translational axis with joint weaving.

If WEAVE_MODALITY = 0 or 3, the wave is described by the transverse speed, the amplitude, the dwell times, and the speed along the trajectory. The frequency of the pattern is fixed by the first three of these parameters. The motion speed along the trajectory ($LIN_SPD) does not affect frequency, but rather the wave length. Fig. 10.1shows the basic shape and defines the various dwell times. It also shows how the speed

109pr-0-0-gpr_09.fm

03/0111


and slope are calculated in case of trapezoidal wave.

If WEAVE_MODALITY = 1 or 4, the wavelength (and therefore the frequency) are maintained as the speed varies; overrides do not influence the wave form.

If WEAVE_MODALITY=2, the wave form is generated with 4 different transverse speeds. Profiles are asymmetric.

Fig. 10.1 - Weave Parameters - A

Note that the following formula is used for transverse speed calculation Left amplitudeTransverse speed = ---------------------------- ts

a. Weaving direction b. Time

1 - ts[1] 2 - Left dwell time 3 - ts[2] 4 - Central dwell time5 - ts[3] 6 - Right dwell time 7 - ts[4] 8 - Final dwell time9 - Left amplitude 10 - Right amplitude

Fig. 10.2 - WeaveParameters - B

1 - Weaving direction 2 - Path 3 - Transverse speed4 - Torch speed = Linear speed 5 - Torch speed = Resulting speed 6 - Linear speed

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].

110pr-0-0-gpr_09.fm

03/0111


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.

Fig. 10.3 - Weave waves

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 amplitudes6 - 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.

111pr-0-0-gpr_09.fm

03/0111


Fig. 10.4 - WeaveParameters - C

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 è:

10.3.2 Weave Plane

Weave plane only applies to cartesian weaving and is established as explained below. At the beginning of the first move with weaving, the approach vector of the tool and the tangent to the move trajectory establish a plane, called the torch plane. A plane called the zero plane is defined perpendicular to the torch plane and contains the trajectory. (If the motion is a straight line, then the tangent to the trajectory is the straight line. If the motion is a circle, then the tangent to the trajectory is the tangent to the circle at its start point). If the torch approach vector is in the same direction as the intended trajectory, an error is generated

(“37111 tool collinear with weave trajectory”).

Fig. 10.5 - Weave Plane

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 plane9 - Weaving plane 10- Approach vector (along Z Tool)

112pr-0-0-gpr_09.fm

03/0111


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.

Fig. 10.6 - Weaving with fly

1 - Start point 2 - Weaving plane angle= 0°

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.

113pr-0-0-gpr_09.fm

03/0111


Fig. 10.7 - Circular Weaving

1 - Initial weaving direction 2 - Start point 3 - Final weaving direction4 - Final point 5 - Centre of circumference

10.3.3 Weave Amplification

Weave amplification permits weaving to be performed on V-grooves or flat butt welds where the gap between parts varies from beginning to end because of imperfect alignment.

The weave amplification factor in $WEAVE_TBL[n].WV_AMP_PER is used to grow or shrink the weave amplitude linearly along the motion. The start of the move is considered 100%. The value from $WEAVE_TBL determines the percentage at the end of the move.

If a series of moves is issued in fly or a path is executed, the amplitude corresponding to 100% is determined at the first move with weaving. Then at the beginning of every succeeding move, the percentage starts the same as the end of the previous move, and $WEAVE_TBL[n].WV_AMP_PER is read to determine the percentage at the end of the move. Thus, a series of moves can be used to weld a long groove or seam without stopping, and the amplification will change continuously from the start of the first move to the end of the last move. (Note that the $WEAVE_TBL[n].WV_AMP_PER variable is read each move, but the definition of 100% is only determined at the first move with weaving). Fig. 10.8 illustrates the weave amplification feature.

Fig. 10.8 - Weave amp

1 - Final amplitude 2 - Final point 3 - Start point 4 - Initial amplitude

114pr-0-0-gpr_09.fm

03/0111


1 - Welded part 2 - First move in fly 3 - Second move in fly4 - Welding 5 - Fly move node

10.4 Stopping Motions with WeavingWhen movement stops at the last position of a move or because an operator has pressed HOLD, the tool can be far away from the original trajectory because of weaving. In this case, the C5G Controller will bring the torch to the end position before stopping.

In emergency stop or power failure cases, the arm stops as fast as possible, which could be far from the original trajectory. When power is restored and pressed, trajectory recovery will occur before the weaving motion resumes.

Fig. 10.9 - Weave stop illustrates these cases.

Fig. 10.9 - Weave stop

1. System in Hold state 2. Stop point 3. Original path4. Emergency stop or Power failure 5. Path reset 6. Original path

115pr-0-0-gpr_09.fm

03/0111


10.5 Programming WeavingWeaving is done by first assigning weave table values and then activating weaving by selecting an appropriate index into the table by assigning it to $WEAVE_NUM. $WEAVE_NUM can also be used in a WITH clause. In that case the $WEAVE_NUM applies only to the current movement. If $WEAVE_TYPE is changed during fly, the following error occurs:

“(37158) mismatch in fly $WEAVE_TYPE”

$WV_AMP_PER also can be used in a WITH clause. $WV_AMP_PER is not needed to be assigned the parent structure name and index ($WEAVE_TBL[n]); the current value of $WEAVE_NUM will apply.

It is not possible to switch the active weave table during a move or path segment, as the same table is used for the entire segment or move. However, the weave shape can be changed during a motion by changing the parameters values of the active table. This can be done either by using a CONDITION statement or by changing the $WEAVE_TBL[$WEAVE_NUM] fields directly.

The following table is a summary of the predefined variables for Weaving (see. Tab. 10.1).

Tab. 10.1 - Predefined variables for Weaving

Nome Tipo Limiti Default WITH

$WEAVE_NUM INTEGER [ 0, 10 ] UNINIT YES

$WEAVE_MODALITY INTEGER [ 0, 4 ] 0 YES

$WV_LENGTH_WAVE INTEGER [ 0, 10000 ] 0 NO

$WEAVE_TYPE INTEGER [ 0, 10 ] UNINIT YES

$WEAVE_TBL ARRAY [$NUM_WEAVES] OF RECORD

NO

$WEAVE_TBL[idx].WV_PLANE REAL [-180, +180] deg

0.0 NO

$WEAVE_TBL[idx].WV_AMP_PER INTEGER [ 0, 1000 ] % 100 % YES

$WEAVE_TBL[idx].WV_RIGHT_AMP REAL [0, 20] mm o deg

0,0 NO

$WEAVE_TBL[idx].WV_LEFT_AMP REAL [0, 20] mm o deg

0.0 NO

$WEAVE_TBL[idx].WV_CNTR_DWL (*) INTEGER [0, 10000] mm o ms

0 NO

$WEAVE_TBL[idx].WV_RIGHT_DWL (*) INTEGER [0, 10000] mm o ms

0 NO

$WEAVE_TBL[idx].WV_LEFT_DWL (*) INTEGER [0, 10000] mm o ms

0 NO

$WEAVE_TBL[n].WV_END_DWL INTEGER [0, 10000] mm o ms

0 NO

$WEAVE_TBL[idx].WV_SMOOTH BOOLEAN FALSE NO

$WEAVE_TBL[n]WV_TRV_SPD REAL 0 NO

$WEAVE_TBL[n]WV_TRV_SPD_PHASE REAL 0 NO

$WEAVE_TBL[n]WV_SPD_PROFILE BOOLEAN FALSE NO

$WEAVE_TBL[idx].WV_AMPLITUDE REAL 0.0 NO

116pr-0-0-gpr_09.fm

03/0111


(*) If $WEAVE_MODALITY=0, mm If $WEAVE_MODALITY=1, ms

10.6 Weaving without Arm motionThis kind of weaving allows to weld without a programmed Arm motion: the target is to be able to weave the Arm while the being welded part is moved by another Arm.

This kind of weaving is similar to the previously described one; the differences are explained in the following sections.

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 Parameterson 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.

10.6.4 Example - Using the weaving without Arm motion

To better understand how this kind of weaving does work and how to use it, an example is provided: let’s suppose that Arm 2 must execute a weaving operation without motion, Arm 1 moves the part to be welded, and the required time to perform the welding operation is 3 seconds. Note that it is needed to know the welding time in order to weld.

a. definition of a suitable weave table (e.g. table 1)

$WEAVE_TBL[idx].WV_RADIUS REAL 0.0 NO

$WEAVE_TBL[idx].WV_PLANE_MODALITY INTEGER [0, 1] 0 NO

$WEAVE_TBL[idx].WV_DIRECTION_ANGLE REAL [-180, +180] deg

0.0 NO

$NUM_WEAVES INTEGER [ 0, 16 ] 10 NO

Tab. 10.1 - Predefined variables for Weaving (Continued)

Nome Tipo Limiti Default WITH

117pr-0-0-gpr_09.fm

03/0111


$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

b. setup of the following features:• the Arm must not weave, • the Arm must use 0 mode related to the transverse speed,• the weaving is performed in cartesian (WEAVE_TYPE_NOMOT := 0):

$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

d. Arm motion, to go to the position where Arm 2 is supposed to weld

MOVE LINEAR TO p1

e. weave on p1 position, for the required time (3 s).

$CRNT_DATA[2].WEAVE_NUM_NOMOT := 1 DELAY 3000 $CRNT_DATA[2].WEAVE_NUM_NOMOT := 0

The statement $CRNT_DATA[2].WEAVE_NUM_NOMOT := 0 disables weaving after 3 seconds, in order to allow the Arm to continue its working motions.

118pr-0-0-gpr_09.fm

03/0111

Path Governor (optional)

11. PATH GOVERNOR (OPTIONAL)

11.1 IntroductionThe 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.

– Enable Path Governor

– Disable Path Governor

11.2 Enable Path GovernorThe user can enable the use of the Path Governor algorithm by a simple PDL2 assignment:

$SPD_OPT:=SPD_PGOV

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

This function has to be used when MAXIMUM ACCURACY is the priority.If instead the priority is to obtain robot MAXIMUM SPEED, it is necessary to use the SmartMove (optional)

Important note: greater path accuracy is obtained accepting lower performance regarding speed, since the enabling of the Path Governor increases the cycle time, if $PGOV_MAX_SPD_REDUCTION is not zero. Therefore, according to the application to be executed, the user will have to find the compromise between reduction in Cartesian speed and increase in cycle time.

The Path Governor is enabled ONLY in Local Automatic status (status selector switch on AUTO).

119hs-0-0-mot_05.fm

00/0210


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.

Fig. 11.1 - Cartesian Speed profile with Path Governor enabled/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.

120hs-0-0-mot_05.fm

00/0210


11.3 Disable Path GovernorThere are two ways the user can disable the Path Governor:

– Assign a value that is not SPD_PGOV to the predefined variable $SPD_OPT, or

– Assign a zero (0) value to the predefined variable $PGOV_MAX_SPD_REDUCTION.

121hs-0-0-mot_05.fm

00/0210

SmartMove (optional)

12. SMARTMOVE (OPTIONAL)

– Description

– Jerk Limitation

– Cartesian Motions

12.1 DescriptionIt 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.

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)

It is recommended to reduce such tolerances, because they are directly related to the stress passed by the reducers.

122hs-0-0-mot_06.fm

00/0210

SmartMove (optional)

Fig. 12.1 - SmartMove - Comparison

Spd - SpeedTr - Time reduction

12.2 Jerk LimitationIt is an algorithm to limit the dynamic over-stress, avoiding moves, especially short moves, with acceleration variations that limit the joints oscillation.

The Jerk limitation is incorporated in SmartMove and automatically manages the Jerk value to be used for each move.However, if, for the particular application to be executed, the moves cause too much stress, or on the contrary a reduction of the cycle time is preferred, to the detriment of the stress, it is possible to ask COMAU to change the Jerk limitations to suit the specific requirements.

12.3 Cartesian MotionsUnlike joint motions (MOVE JOINT), to perform cartesian motions (either LINEAR or CIRCULAR) it is needed to set the following $SPD_OPT value:

$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.

123hs-0-0-mot_06.fm

00/0210

Flow Modulate Algorithm

13. 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 / $AOUTvalue), 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.

124pr-0-0-gpr_12.fm

02/0610

Flow Modulate Algorithm

Example:

The voltage, in bits, is determined by the formula:

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 ).

Fig. 13.1 - Delivery voltage

1. Delivery flow2. 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)

125pr-0-0-gpr_12.fm

02/0610

Presuppositions for SMART Robot programming

14. PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

14.1 IntroductionCurrent 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:

The following topics are fully described:

– Glossary

– Offset algorithm with Dynamic Model

– Kinematic offset algorithm (optional feature)

– Moving through axis 5 singularities

– Robots without compensation (effect of the inverse kinematics)

– Programming rules for non-spherical wrist robots (SMART NJ4)

The list of error messages is reported and the meaning is explained. Some notes are also given about mapping between C5G error messages and RRS (Robot Realistic Simulation) ones that are sent by Robcad while simulating a program. This is useful because RRS specification doesn't include messages enough to describe all the expected situations.

Tab. 14.1 - Involved Robot models

Robot Spherical wrist Non-spherical wrist

SMART NJ1 X

SMART NJ2 X

SMART NJ3 X

SMART NJ4 X

SMART NS X

SMART NM X X

126pr-0-0-gpr_05.fm

03/0111


14.2 GlossaryTCP - 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.

14.3 Offset algorithm with Dynamic ModelThis algorithm improves the mechanical precision in movement and positioning, thus

127pr-0-0-gpr_05.fm

03/0111


cutting down the cycle time.

The algorithm functions continually, both during robot movement and during stops, regardless of the type of trajectory or the duration of the pause: the only condition is that the arm be in DRIVE ON.

The modelling of the robot dynamic characteristics requires an accurate definition of the tool that is mounted on the flange.

The description of the tool can be executed by means of three system variables that are added to $TOOL. These are $TOOL_MASS, that is the tool mass, $TOOL_CNTR, which is the centre of the tool mass and $TOOL_INERTIA.

It must be noted that accuracy in the assignment of the tool characteristics has a strong influence on the machine performance.

Furthermore, if the robot is used to transfer components, it is important that the declaration of the dynamic characteristics includes the contribution of the workpiece mass, as well as that of the gripping tool; this also applies for the definition of the mass centre coordinates.

14.4 Kinematic offset algorithm (optional feature)This algorithm improves the precision of the robot positioning in the work area.

The software offsets the kinematic errors, caused by the imprecision of the robot lever lengths or the incorrect coupling of the axes (axis orthogonality ), and deflection error caused by the weight of the mechanical parts.

To make it operational, it is necessary to identify the actual kinematic model of each individual robot so as to obtain a machine offset file.

14.5 Moving through axis 5 singularitiesIn current paragraph information are given about the following topics:

– Using WRIST_JNT modality to go through singularities

– Manual motion (jog keys)

14.5.1 Using WRIST_JNT modality to go through singularities

In all the robot mechanical structures there are particular positions where performances are reduced; such positions are called singularities. Usually, when robot gets close to a singularity while moving in a linear/circular way, either the speed is reduced or the trajectory is changed as to the espected one. This is true for every robot regardless the manufacturer.

Anthropomorphic robots, like the ones in Tab. 14.1 - Involved Robot models, have three singularities. The most evident one happens when axis 5 is at zero degrees. When this occurs, axis 4 is aligned with axis 6. This produces different behaviors depending on the shape of the wrist. Further information are described in the following par. 14.6.1.4 Axis 5 singularity on page 133 for non-spherical wrist robots and par. 14.6.2.1 Axis 5 singularity on page 139 for spherical wrist robots.

Nevertheless there is a general feature available with Comau C5G Robot Controller that allows the robot to achieve high performances while moving through axis 5 singularity (wrist singularity).It is possible to enable this type of evolution by setting the $ORNT_TYPE system variable to the WRIST_JNT value ($ORNT_TYPE:=WRIST_JNT). It is advisable to

128pr-0-0-gpr_05.fm

03/0111


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.

1. Side view 2. Front view

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.

1 - Linear trajectories while getting near the singularity.

The curved lines are the flange trajectories, while the TCP moves along the right path2 - Exact singularity position 3 - Behaviour of the WRIST_JOINT modality.

Getting closer to the singularity, speed is maintained high while orientation slightly changes

129pr-0-0-gpr_05.fm

03/0111


14.5.1.1 Using WRIST_JNT modality to go through singularities

As already explained, the use of WRIST_JNT evolution modality is the right method to solve all singularity problems. This method is useful mainly for moving through the singularity zone because it allows axis 5 to reach the zero position while TCP is following the required Cartesian trajectory.

Here follows an example involving SMART NJ4 model. With WRIST_JNT modality it is possible to perform vertical trajectories around the singularity point. Of course, all the positions must be out of the singularity zone (see par. 14.6.1.4 Axis 5 singularity on page 133) but any trajectory can cross it.

If the program is correctly designed, axis 5 is asked to move from a negative to a positive value (or vice-versa) while the wrist offset is always maintained on the same side. As already explained, the orientation is slightly changed during the movement. This is automatically done by the system without any need of modifying points.

1 - Level of the singularity point

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.

1 - Singularity exact position

130pr-0-0-gpr_05.fm

03/0111


14.5.2 Manual motion (jog keys)

Also during the jogging phase (manual movement of the robot) it is possible to avoid all problems due to axis 5 singularity by using the WRIST_JNT evolution.

There are 4 standard modalities for jogging:

– TOOL

– UFRAME

– BASE

– JOINT

The first three ones are for Cartesian movements, with reference to tool frame, user frame and world frame; the last one allows moving each single robot joint. These modalities are usually the best from the application point of view but they do not allow robot to move in a Cartesian way when axis 5 is inside the singularity zone. To achieve this task it is necessary to enable the WRIST_JNT modalities for jogging.The WRIST_JNT evolution can be set for Cartesian manual, from the Motion page, Basic sub-page, COORD field of the Teach Pendant. On theTeach Pendant status bar the following words will be seen: Wr-Base, Wr-Tool, Wr-Ufrm, Joint.

WRIST_JNT modalities allow TCP to move along a straight line without moving wrist axes, by pressing the first three jog buttons: +1X/-1X, +2Y/-2Y, +3Z/-3Z. On the other hand, pressing jog buttons +4/-4, +5/-5, or +6/-6, it is possible to move a single wrist axis while maintaining TCP steady. These modalities are useful to go through the singularity because they allow the robot to be jogged in a Cartesian way also if axis 5 is exactly at 0 degrees.

14.6 Robots without compensation (effect of the inverse kinematics)In current paragraph, information are given about the following topics:

– Inverse conversion of SMART NJ4 (non-spherical wrist) model

– Inverse conversion of SMART NJ models (spherical wrist only)

14.6.1 Inverse conversion of SMART NJ4 (non-spherical wrist) model

SMART NJ4(L) robot has a particular hollow wrist with an offset between axis 4 and 6. To compute the value of the axes that allows the robot moving to a specific Cartesian position (inverse kinematics conversion), it is necessary to run an iterative algorithm that uses the WCP position and the TCP position of the robot, with reference to its base.

In the following sections the related effects are shown:

– Approximation in the orientation

– Move to a taught POSITION

– Fly between MOVE LINEAR/CIRCULAR and MOVE JOINT

– Axis 5 singularity

– Cartesian position out of range

– TCP in the back of the robot

– TCP behind axis 2

131pr-0-0-gpr_05.fm

03/0111


– WCP close to axis 1

14.6.1.1 Approximation in the orientation

The Cartesian position reached by the TCP is always correct in X, Y and Z. This means that the X, Y and Z coordinates of the final position correspond to the taught one (unless some effect due to compensation). On the other hand, the orientation can be approximated. This means that the robot reaches the final position with the Euler angles slightly different to the original ones. This difference is usually less than 0.8 degrees (can be bigger in proximity of the border of the working area).

This approximation affects all the axes and can produce some unexpected error message because some of the axes can get closer to some limit than the taught joints. For this reason some bigger ranges are advised in the following paragraphs. These ranges are called safe ranges.

The approximation does not affect the locations recorded as JOINTPOS.

14.6.1.2 Move to a taught POSITION

The approximation in the orientation can produce the following effect. When a MOVE is executed to a Cartesian position, the flange (not the TCP) can move a few millimetres around its position. The displacement is usually less that 10 millimeters with a tool 1500 millimeters long.

1a - 1b: difference between the two flange positions, due to the orientation approximation2a - 2b: orientation approximation

14.6.1.3 Fly between MOVE LINEAR/CIRCULAR and MOVE JOINT

The approximation in the orientation causes a small difference between the computed joint values (to finish current movement) and the real values.

For this reason it is advisable not to use a fly between a linear/circular move and a joint

132pr-0-0-gpr_05.fm

03/0111


move or vice-versa.

14.6.1.4 Axis 5 singularity

Due to the hollow wrist the singularity zone for SMART NJ4(L) robot is wider than the position at 0 degrees of axis 5. The conversion can give back a solution only if axis 5 is out of range ±6° around zero value and multiple of 180°. If, during the conversion, axis 5 enters this zone an error message is issued.

Due to the approximation in orientation, the error message can come out also on a POSITION that had been taught with axis 5 slightly out of ±6° threshold . Since the approximation is usually less than 0,8°, a safe range is ±7°.

Fig. 14.1 - SMART NJ4 forbidden zone

1. ±6 degrees around 0° and 180°

Forbidden ranges[ -6; +6 ]

[ -174; -186 ][ +174; +186 ]

Safe ranges[ -7; +7 ]

[ -173; -187 ][ +173; +187 ]

Actions Allowed Forbidden Notes

REC JOINTPOS inside the singularity zoneX

It is possible to record a joint position (JOINTPOS).

REC POSITION/XTNDPOS inside the singularity zone X

It is NOT possible to record a Cartesian position (POSITION or XTNDPOS).

MOVE JOINT through singularity zone X

MOVE LINEAR/CIRCULAR through singularity zone with the standard evolution modality (RS_WORLD)

XIt is possible to move in a Cartesian way only with the WRIST_JNT evolution (see par. 14.5 Moving through axis 5 singularities on page 128). In the standard modality (RS_WORLD) MOVE LINEAR/CIRCULAR is not allowed.

MOVE LINEAR/CIRCULAR through singularity zone with the WRIST_JNT evolution modality X

133pr-0-0-gpr_05.fm

03/0111


14.6.1.5 Cartesian position out of range

Due to the particular wrist of SMART NJ4(L) model, the external boundary of the Cartesian working area is slightly reduced with respect to spherical-wrist machines.This reduction depends on the direction of the wrist offset:

– If the wrist offset is downward there is no limitation.

– If the wrist offset is upward there is an additional forbidden area for SMART NJ4(L) robot. The width of this area is 180 mm in the front area and 225 mm in the rear area. For SMART NJ4(L) robots, the width is 140 mm in the front area and 215 mm in the rear area.

JOG JOINT inside the singularity zone X It is possible to jog the robot in a Cartesian way only if the WRIST_JNT modalities are enabled (WR-BASE, WR-UFRM, WR-TOO, see par. 14.5.2 Manual motion (jog keys) on page 131). It is not allowed to jog inside the singularity zone with the standard jog modalities (BASE, UFRAME, TOOL).

JOG BASE, UFRM, TOOL inside the singularity zone

X

JOG WR-BASE, WR-UFRM, WR-TOOL inside the singularity zone

X

MOVE JOINT TO JOINTPOS inside the singularity zone

X

MOVE LINEAR TO JOINTPOS inside the singularity zone

X If the destination point is inside the singularity zone it is not possible to move there both with the standard evolution and with WRIST_JNT.

MOVE JOINT TO POSITION/XTNDPOS inside the singularity zone

X

MOVE LINEAR TO POSITION/XTNDPOS inside the singularity zone

X

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


REC JOINTPOS inside the forbidden zoneX


REC POSITION/XTNDPOS inside the forbidden zone X



134pr-0-0-gpr_05.fm

03/0111


14.6.1.6 TCP in the back of the robot

There are some limitations in the working area that are not immediately visible to the user. They depend on the position of the TCP with respect to the robot axes. For this reason they are related to the current dimension of the tool (both remote and local). There is a forbidden zone when the TCP tries to go in the back of the robot with respect to axis 1. The width of this area is approximately 150 mm on both sides.

Approaching this area the approximation on the orientation increases up to some degrees.

MOVE JOINT through the forbidden zone X It is allowed to move through this zone with every type of movement. It is sufficient that the destination point is out of the forbidden zone.

MOVE LINEAR/CIRCULAR through the forbidden zone X

JOG JNT inside the forbidden zone X

It is possible to jog the robot in every modality.

JOG BAS, USR, TOL inside the forbidden zone

X

JOG BWR, UWR, TWR inside the forbidden zone

X

MOVE JOINT TO JOINTPOS inside the forbidden zone

X

If the destination point is inside the forbidden zone, it is possible to reach it only if it is a JOINTPOS.

MOVE LINEAR TO JOINTPOS inside the forbidden zone

X

MOVE JOINT TO POSITION/XTNDPOS inside the forbidden zone

X

MOVE LINEAR TO POSITION/XTNDPOS inside the forbidden zone

X

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".


135pr-0-0-gpr_05.fm

03/0111


The same situation can also happen with remote tool.

1 - Remote TCP inside the forbidden zone






MOVE JOINT through forbidden zone X

MOVE LINEAR/CIRCULAR through forbidden zone with the standard evolution modality (RS_WORLD)


MOVE LINEAR/CIRCULAR through forbidden zone with the WRIST_JNT evolution modality

X

JOG JNT inside the forbidden zone X It is possible to jog the robot in a Cartesian way only if the WRIST_JNT modalities are enabled (BWR, UWR, TWR, see par. 14.5.2 Manual motion (jog keys) on page 131). It is not allowed to jog inside the forbidden zone with the standard jog modalities (BAS, USR, TOL).


X


X

136pr-0-0-gpr_05.fm

03/0111


14.6.1.7 TCP behind axis 2

There is a forbidden zone when the TCP tries to go behind a plane containing axis 2. The width of this area is approximately 150 mm on both sides. Approaching this area the approximation on the orientation increases up to some degrees.

This same situation can happen also with remote tool ($TOOL_RMT:=TRUE or nodal move with rtf(i,j)).

1. TCP inside the forbidden zone 2. remote TCP inside the forbidden zone


X

If the destination point is inside the forbidden zone, it is possible to reach it only if it is a JOINTPOS.


X


X


X

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".






MOVE JOINT through forbidden zone X


137pr-0-0-gpr_05.fm

03/0111


14.6.1.8 WCP close to axis 1

There is a forbidden zone when the WCP tries to enter a cylinder around axis 1. The radius of the cylinder is approximately 200 mm.

14.6.2 Inverse conversion of SMART NJ models (spherical wrist only)

SMART NJ robots have spherical wrist and this simplifies the conversion algorithm with respect to SMART NJ4 robots. The most part of the limitations explained in previous

MOVE LINEAR/CIRCULAR through forbidden zone with the standard evolution modality (RS_WORLD)


MOVE LINEAR/CIRCULAR through forbidden zone with the WRIST_JNT evolution modality

X

JOG JNT inside the forbidden zone X It is possible to jog the robot in a Cartesian way only if the WRIST_JNT modalities are enabled (BWR, UWR, TWR, see par. 14.5.2 Manual motion (jog keys) on page 131). It is not allowed to jog inside the forbidden zone with the standard jog modalities (BAS, USR, TOL).


X


X


X

If the destination point is inside the forbidden zone, it is possible to reach it only if it is a JOINTPOS


X


X


X

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".


138pr-0-0-gpr_05.fm

03/0111


par. 14.6.1 Inverse conversion of SMART NJ4 (non-spherical wrist) model on page 131don’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.

14.6.2.1 Axis 5 singularity

There is not a forbidden zone when axis 5 is close to zero degrees but it is anyway advisable not to move through the singularity because close to this zone axes 4 and 6 are required to accelerate and move very fast. The speed of the TCP is reduced while moving in a Cartesian way close to this zone.

The WRIST_JNT modality (see par. 14.5 Moving through axis 5 singularities on page 128) is a good method to move through the singularity zone when the accelerations are too high or when the behavior of the robot is not proper for the specific application.

14.7 Programming rules for non-spherical wrist robots (SMART NJ4)In current paragraph, some programming rules are described in order to help the robot user and the CAD programmer, to properly use COMAU robots (mainly SMART NJ4 models).

Here following, some hints are given about:

– How to stay away from a singularity zone

– Using WRIST_JNT modality to go through singularities

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.

14.7.1 How to stay away from a singularity zone

The width of the singularity zone for non-spherical wrist robots (SMART NJ4) is ±6 degrees. As it has been explained in par. 14.5 Moving through axis 5 singularities on page 128 it is possible to go through this zone also following a Cartesian path, but in most cases it is possible to stay away from the singularity. There are three methods to achieve this task:

– Changing the orientation of the points along the path;

– Properly designing the work-cell layout;

– Modifying tool inserting a small angle between robot flange and tool flange.

The same methods are useful to solve problems with points which are very close to the

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.

139pr-0-0-gpr_05.fm

03/0111


working area borders.

14.7.1.1 Changing the orientation of the points along the path

In most applications the tool has a shape that allows rotating around the approaching direction, without reducing the process quality. This is possible with tools that are symmetric along a direction. The arc-welding torch and the spot-welding gun are typical examples.

1 - Tool approach vector

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 following picture shows three different cases with a spot welding gun.

Fig. 14.2 - BEST situation (90° between axis 6 and gun approach vector)

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.

140pr-0-0-gpr_05.fm

03/0111


Fig. 14.3 - WORST situation (approach vector aligned to axis 6)

Fig. 14.4 - MEDIUM situation (approach vector parallel to axis 6, but not aligned)

1 - Distance between axis 6 and tool approach vector

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.

14.7.1.2 Properly designing the work-cell layout

There are some cases where the first method (par. 14.7.1.1 Changing the orientation of the points along the path on page 140) doesn’t apply. This happens, sometimes, with palletizing applications where the orientation is fixed. In such cases it is necessary to properly design the work-cell layout, in order to avoid entering the singularity zone. Also the shape of the tool is very important to solve bad situations and improve the robot performances (see par. 14.7.1.3 Modifying tool inserting a small angle between robot flange and tool flange on page 144).

The programmer must avoid situations in which pallets are exactly in front of the robot and grippers are oriented in the direction of axis 6 (see pictures below).

Such a bad situation comes from the following three conditions:

– the gripper is aligned with axis 6;

141pr-0-0-gpr_05.fm

03/0111


– 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).

142pr-0-0-gpr_05.fm

03/0111


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.

143pr-0-0-gpr_05.fm

03/0111


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.

144pr-0-0-gpr_05.fm

03/0111


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.

145pr-0-0-gpr_05.fm

03/0111


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

146pr-0-0-gpr_05.fm

03/0111


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.

147pr-0-0-gpr_05.fm

03/0111

Collision Detection (optional feature)

15. COLLISION DETECTION (OPTIONAL FEATURE)

15.1 IntroductionThe 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

Current chapter supplies information about the following topics:

– Basic concepts

– Activation/deactivation of Collision Detection function Collision Detection functionality

– Collision Detection sensitivity type

– Reliability of Collision Detection functionality

– Notes about the collision detection use procedure

– Sample Programs.

15.2 Basic conceptsWhen enabled, the Collision Detection functionality allows detecting situations such as

– robot arm collisions with the surrounding environment

– stuck tips in welding operations,

– etc.When a collision condition is detected (error message 62513SAX: collision detected), the system may enter into a particular phase during which the robot gets compliant and the emergency braking takes place

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.

Severity of collision error

The severity of the collision error can be changed by bringing it from 10 (that causes a DRIVE OFF) to 8 (that generates a HOLD). To do this, set the new predefined variable $COLL_EFFECT ($ARM_DATA field ) to the value:

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!

148pr-0-0-gpr_06.fm

03/0111


– 0 to generate, in the case of collision, a DRIVE OFF;

– 1 to set the machine in HOLD state.

– 2 to generate the system event 197 that indicates "collision detected"

If it is wished, in the case of a severity 8 alarm, to activate the compliance mode, it is better to increase the SoftServo after collision ($TUNE[25]) timeout bringing it from 600 (default) to 1000 or 1200.This way of managing the Collision Detection is useful for "Pallet Search" applications in the robot operating area: the arm moves along a Cartesian direction and when it meets the pallet it stops, remaining fed, instead of generating an error and passing in DRIVE OFF.

15.3 Activation/deactivation of Collision Detection functionSince System Software release 2.02, Collision Detection handling is changed.

In order to enable the Collision Detection functionality, it is enough to set $CRNT_DATA[num_arm].COLL_ENBL predefined variable to TRUE, by either a Program Statement or a System Command: $CRNT_DATA[num_arm].COLL_ENBL := TRUE

By default, it is not reset by the system upon each DRIVE OFF command; it continues to be working until the user consciously decides to disable it, by setting the mentioned above flag to FALSE.

It is also possible to change to the operating mode for automatically disabling the Collision Detection functionality, setting to 1 bit number 10 of $ARM_DATA[num_arm].A_ALONG_1D[12] predefined variable, by means of the BIT_SET built-in.

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).

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.

149pr-0-0-gpr_06.fm

03/0111


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 Collision Detection sensitivity typeA detailed description follows of the predefined variables which are involved in the Collision Detection functionality. They are:

– $COLL_TYPE

– $ARM_SENSITIVITY (sensitivity threshold of the axes)

– $COLL_SOFT_PER (axes compliance thresholds)

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_LOWMOVE 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.

150pr-0-0-gpr_06.fm

03/0111


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.

15.4.2 $ARM_SENSITIVITY (sensitivity threshold of the axes)

This bidimensional array represents the snsitivity threshold for each robot axis, used by the Collision Detection algorithm. Maximum sensitivity is 100, minimum is 0.

The first dimension is the one of all possible values of $COLL_TYPE. The second one is the axis number. Example: $ARM_SENSITIVITY[COLL_LOW, 1]

The calculation of the Collision Detection sensitivity thresholds is possible by means of a built-in that can be run while the robot executes the work cycle.The characteristics of this built-in are the following:

ARM_COLL_THRS(Arm, Coll_type, Time, Margin)

– Arm is the arm where the acquisition is to be made.

– Coll_type is the type of sensitivity for acquisition: the built-in will go directly to load the $ARM_SENSITIVITY variables for the specified Coll_type. To obtain the optimising of the sensitivity thresholds, the types of collision increase from 6 to 14, with the introduction of the types from COLL_USER3 to COLL_USER10.

– Time is the time, in seconds, that the acquisition lasts, and it has to correspond to at least the duration of the path for which the thresholds are to be valid (a work cycle or a single motion). It may be from 1 to 300 seconds.

– Margin is a flag (TRUE/FALSE) that defines whether the thresholds are to be calculated with a margin of variability (TRUE, default value) or exactly on the assigned path (FALSE).The value of the variability margin is contained in the predefined variable $A_ALONG_2D[10,ax] that will be initialised, in the configuration file, with the value {7,7,6,6,6,0,0,0,0} which means 7% of the drive full scale on the first 3 axes, and

When the Collision Detection functionality is enbled in PROGR state (jog, ProgramEdit, etc.), the COLL_MANUAL correponding thresholds (which means $ARM_SENSITIVITY [COLL_MANUAL,nax] and $COLL_SOFT_PER [COLL_MANUAL,nax] ) are used, regardless the current value of $COLL_TYPE.

Values 1 and 0 of the Time parameter, have the following meaning:– 1 - indicates to start the data acquisition in order to calculate the sensitivity

thresholds– 0 - indicates to stop the data acquisition and to assign the sensitivity

thresholds.Example of usage:

ARM_COLL_THRS(1,COLL_USER7,1)MOVE .......MOVE ...ARM_COLL_THRS(1,COLL_USER7,0)

151pr-0-0-gpr_06.fm

03/0111


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

62520 - 02 SA DETERMINATION OF THE COLLISION CONCLUDED THRESHOLD

loads the values obtained, with no variability margin, in the predefined variables $ARM_SENSITIVITY[COLL_USER2, ax].

The built-in can be used in a PDL2 program, linked to opportune CONDITIONS, to adjust the sensitivity thresholds should the movement execution conditions change.

15.4.3 $COLL_SOFT_PER (axes compliance thresholds)

This predefined variable represents the compliance percentage for each robot axis, in the compliance condition (when enabled), caused by a detected collision. Maximum compliance percentage is 100, minimum is 0.

The first dimension is one of all possible values of $COLL_TYPE. The second one is the axis number. Example: $COLL_SOFT_PER[COLL_HIGH, 3]

15.5 ReliabilityIn 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.

15.6 Notes about the collision detection use procedure– Introduction

– Use of the Collision Detection Procedure

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 .

For these reasons, before activating the Collision Detection function, the user is to check that the load used has been defined precisely.

152pr-0-0-gpr_06.fm

03/0111


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.

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).

15.6.2 Use of the Collision Detection Procedure

Now, let’s go through Collision Detection variables setting. It is strongly recommended to follow all the listed below steps:

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.

153pr-0-0-gpr_06.fm

03/0111


a. What is to be done before enabling the Collision Detection?

a.1 It is necessary to have the final work program.

a.2 To identify the thresholds for the work cycleBecause of the sensitivity of the algorithm, there is a difference between identifying the COLD ROBOT thresholds (robot stationary, has been in DRIVE OFF for hours, if possible overnight) and WARMED ROBOT (a robot is considered WARMED after it has performed at least 15-20 work cycles).To be certain that false collisions will not occur, the thresholds are to be identified with the machine COLD.

If greater sensitivity is desired with WARMED ROBOT, 2 sets of thresholds have to be identified:• one for COLD ROBOT and • one for WARMED ROBOT.It will be the task of the user to provide a non-holdable PDL2 program that, at the same time as the work cycle, manages the graduation of the thresholds from COLD to WARMED and from WARMED to COLD, based on events (for example machine stop for maintenance or a halt in the working activities and a restart) and the associated timers.

b. Splitting-up the programThe user program is to be splitted-up in some parts, in order to make it more efficient end effective. For example:– A: Via point movements– B: short positioning movements– C: technological movements (pick, drop, welding, etc.)The user has to specify, for each type of movement, the right threshold which is due both to the robot position and its payload.When the program movements have been logically splitted-up, based upon the different movement types, go to the following step.

c. Activating the functionalityIn order to activate the functionality, it is enough to insert the following statement at the program beginning:

$CRNT_DATA[num_arm].COLL_ENABLE:=TRUE

To deactivate it:

$CRNT_DATA[numero_arm].COLL_ENABLE:=FALSE

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 !

154pr-0-0-gpr_06.fm

03/0111


d. Definition of Nodal/ModalSensitivityThe system is provided with some predefined thresholds, for a general payload, like the robot payload:– COLL_LOW– COLL_MEDIUM– COLL_HIGHWhile in programming state, the system automatically uses a 4th threshold:– COLL_MANUALTwo 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 collisionsIf 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).

f. What does the sensitivity percentage threshold mean?For each axis, there is a maximum value of its deliverable current; for example, if IMAX=60 A, saying that the axis sensitivity is 90%,it means:

(100% - 90%) * 60 A = 6 A

g. Use strategyFirst of all the user must understand what he really does need:– REQUIREMENT No.1: immediate use of the Collision Detection

functionalityThe 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

155pr-0-0-gpr_06.fm

03/0111


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 useThe 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 tipsIf 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.

156pr-0-0-gpr_06.fm

03/0111


15.7 Sample ProgramsThe following sample Programs are provided:

– Enabling the Collision Detection functionality for a single MOVE statement

– Enabling Collision Detection again from within a Program

– Automatic calculation of the sensitivity thresholds

– Managing "collision detected" event

– Use of CDetect open source library.

15.7.1 Enabling the Collision Detection functionality for a single MOVE statement

PROGRAM collisionVAR 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_SYSCYCLE MOVE TO pnt0001j MOVE TO pnt0002j

-- activating the collision detection functionality when needed only

MOVE LINEAR TO pnt0003j WITH CONDITION[1], CONDITION[2] MOVE TO pnt0004jEND collision

157pr-0-0-gpr_06.fm

03/0111


15.7.2 Enabling Collision Detection again from within a Program

To be used in the case in which Collision Detection is disabled upon DRV OFF.

PROGRAM collision2VAR pnt0001j, pnt0002j, pnt0003j, pnt0004j : JOINTPOS FOR ARM[1]BEGIN

CONDITION[1] NODISABLE : WHEN EVENT 99 DO

-- enabling collision detection upon drive on (useful until 2.01 sw version)

$CRNT_DATA[1].COLL_ENBL := TRUE ENDCONDITION

ENABLE CONDITION[1] MOVE TO $CAL_SYS

-- activating collision detection in modal mode, low sensitivity

$COLL_TYPE := COLL_LOW $CRNT_DATA[1].COLL_ENBL := TRUECYCLE MOVE TO pnt0001j MOVE TO pnt0002j

-- increasing the sensitivity for the movement to be monitored

MOVE LINEAR TO pnt0003j WITH $COLL_TYPE = COLL_HIGH MOVE TO pnt0004jEND collision2

158pr-0-0-gpr_06.fm

03/0111


15.7.3 Automatic calculation of the sensitivity thresholds

---- Recalculates the collision sensitivity thresholds every delta_t minutes --and at each GEN_OVR variation.--PROGRAM thresholds NOHOLDVAR dummy : BOOLEAN coll : INTEGER delta_t : INTEGER

ROUTINE ru_thrsBEGIN-- 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] -- Calculates the start thresholds ru_thrs

-- Keeps the program active WAIT FOR dummyEND thresholds

159pr-0-0-gpr_06.fm

03/0111


15.7.4 Managing "collision detected" event

Simply as an example, a program segment is given that manages the "collision detected" event 197 .

PROGRAM colltouchVAR pnt0006p, pnt0007p, pnt0008p: POSITIONpnt0001p, pnt0002p, pnt0003p, pnt0004p, pnt0005p: POSITIONBEGIN

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

CYCLEMOVE TO ... . . .

END colltouch

160pr-0-0-gpr_06.fm

03/0111


15.7.5 Use of CDetect open source library

In UD:\SYS\UTIL directory, an open source library called CDetect is released, which contains two exported routines, very important for the Collision Detection functionality.

They are associated to the motion statements, for starting and ending the acquisition of the Collision thresholds to be used in such a motion section:

– CD_START (ai_coll) - indicates the beginning of the Collision thresholds acquisition. It is possible to specify a parameter (ai_coll) which is the number of the table including the Collision thresholds associated to such a motion section.

– CD_END - indicates the end of the Collision thresholds acquisition. This routine stops the acquisition and the motion segment, and freezes its corresponding values.

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

VAR pnt0001j, pnt0002j, pnt0003j, pnt0004j : JOINTPOS FOR ARM[1]

-- EXPORTED ROUTINESROUTINE CD_Start(ai_Coll : INTEGER) EXPORTED FROM CDetectROUTINE CD_End EXPORTED FROM CDetectROUTINE CD_Read EXPORTED FROM CDetect

BEGIN

MOVE TO $CAL_SYSCYCLE

CD_START(1)MOVE TO pnt0001jMOVE TO pnt0002jCD_END

CD_START(2)MOVE LINEAR TO pnt0003j MOVE TO pnt0004jCD_END

END mov

161pr-0-0-gpr_06.fm

03/0111

Use of Positioners managed by C5G

16. USE OF POSITIONERS MANAGED BY C5G

16.1 IntroductionThis 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.

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.

16.2 Summary

In any case, even with a standard positioner, the radius of the part overall dimensions always has to be defined.

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 padsthe unit behaves in a manner that complies with current safety standards.

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

162hs-0-0-mot_04.fm

00/0210


The positioners described herein are grouped as follows:

– Positioners with 1 rotating axis type MP, PTDO, PTDV, TR3000/6000

– PTORB - Positioner with 2 perpendicular axes

– Positioners with 2 non perpendicular axes, type PTORB-alfa

– Integrated robot positioning axes

The following indications are contained for each of the above topics:

– definition mode of base and flange reference systems,

– how to execute the calibration and

– characteristic parameters for the positioner kinematic description.

16.3 General ConventionsConventions regarding axis rotation and mechanical location of points P1, P2 and P3 (to calculate cooperated motion) are described, to be used for positioner models managing two axes.

These conventions acquire importance when a cooperative motion is to be executed, i.e. to enslave a robot to the position of the part mounted on the positioner: if they are not followed it will not be possible to correctly measure the positioner base position by means of the TO_SET program (see Chap. TO_SET Program - Tool handling).

– Axis rotation directions

– Convention for the mechanical positioning of points P1, P2 and P3

16.3.1 Axis rotation directions

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.

16.3.2 Convention for the mechanical positioning of points P1, P2 and P3

The references for points P1, P2, P3 described in the Chap. TO_SET Program - Tool handling to calculate the base of the positioners ($BASE if the positioner is an independent arm or $AUX_BASE if it is a group of auxiliary axes) are to be mechanically positioned according to the following convention (see . Fig. 16.1):

– P1 and P3 are to be chosen along the Yflange axis, with positive direction from P1 to P3 (P1 in the negative part of Yflange and P3 in the positive part);

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)..

163hs-0-0-mot_04.fm

00/0210


– 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.

Fig. 16.1 - Mechanical positioning of P1, P2 and P3

1 - axis 1 2 - axis 2

Xb, Yb, Zb, Ob= Xbase, Ybase, Zbase, ObaseXf, Yf, Zf, Of = Xflange, Yflange, Zflange, Oflange

16.4 Programming override value calculationTo comply with the safety standards in force for robots and positioners, a configuration tool is provided on the Teach Pendant (SETUP page, AUX_AXES sub-page). This calculates the speed value in manual mode.

The following formula is used:

where:

250 = maximum speed allowed as per standard [mm/s]955 = numeric conversion factorRt = motor transmission ratio [Mt/axt]Vm = motor maximum speed [Rpm]r = part overall dimension radius [mm]

164hs-0-0-mot_04.fm

00/0210


16.5 Positioners with 1 rotating axis type MP, PTDO, PTDV, TR3000/6000

16.5.1 Definition of the reference system

The reference system for the lathe positioner flange (bearing plate) is defined according to the following conventions (see Fig. 16.2):

– the flange reference system origin (Oflange) lays on the surface of the flange coinciding with the positioner axis rotation centre;

– the Zflange axis is to be perpendicular to the flange surface with outward direction.

Fig. 16.2 - Definition of the reference system

1 - axis 1 Xf, Yf = Xflange, Yflange

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).

16.5.2 Calibration

The lathe positioner does not require special rules for the calibration position.

MAXIMUM PROGRAMMING SPEEDIt is very important that the calculation is made with extreme accuracy, so as to meet the requirements of current safety standards. If parts are machined that have very different dimensions, the worst case is to be used for the calculation (part maximum overall dimensions).The override value is inserted with the configuration tool.

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

165hs-0-0-mot_04.fm

00/0210


16.5.3 Kinematic description

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.

Fig. 16.3 - Part maximum radius measurement

1 - Part to be machined 2 - Lathe bearing plate

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.

To configure these positioners, see the C5G Control Unit Use Manual, Setup Page, paragraph AUX_AXES.

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

OPTION AXIS VALUE

Axis length [mm] 7 /

Type of axis 7 ROTATING

Axis offset [mm] 7 /

Programmed speed override 7 X

166hs-0-0-mot_04.fm

00/0210


16.6 PTORB - Positioner with 2 perpendicular axes – Positioner with two tilting-rotating axes

– Positioner with two axes in "L" arrangement

16.6.1 Positioner with two tilting-rotating axes

16.6.1.1 Definition of the reference system

The positioner base reference system is defined by the following conventions (see Fig. 16.4):

– the origin of the positioner base reference system (Obase) lays on the bearing surface (typically the floor);

– the Zbase axis is perpendicular to the bearing surface and in upward direction;

– the Xbase axis lays on the bearing surface with direction parallel to the positioner first rotation axis;

– the Ybase axis is therefore on the resting surface perpendicular to the positioner first rotation axis.

The positioner flange reference system is defined according to these conventions (see Fig. 16.4):

– the origin of the flange reference system (Oflange) lays on the flange surface that coincides with the centre of rotation of the positioner second axis;

– the Zflange axis is perpendicular to the flange surface with outward direction.

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).

Both of these conditions are important: an approximation in relation to one of these will jeopardise the machine precision during cooperative motion (the robot does not hold the position on the part).

167hs-0-0-mot_04.fm

00/0210



1 - axis 1 2 - axis 2 Xf, Yf = Xflange, Yflange Xb, Yb = Xbase, Ybase

16.6.1.3 Kinematic description

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.

Fig. 16.5 - Parameters for the positioner kinematic description

1 - axis 1 2 - axis 2 3 - part to be machined

$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


168hs-0-0-mot_04.fm

00/0210



Two tables follow, summarising the useful mechanical data, assuming that the positioner is handled with auxiliary axes 7 and 8 respectively.

16.6.2 Positioner with two axes in "L" arrangement


As can be noted, the positioner base reference system is in an unusual position in relation to the other positioners, that is to say, its origin does not lay on the bearing surface but is displaced in correspondence to axis 2 (seen from above). This happens because the software uses the same mathematic model of the tilting-rotating positioner that does not support this type of offset.

The positioner base reference system is defined according to these conventions (see Fig. 16.6):

– The origin of the positioner base reference system (Obase) lays on the level of the bearing surface, (typically the floor) on the extension of rotation axis 2;


– the Xbase axis lays on the bearing surface with direction parallel to the first rotation axis of the positioner;

– the Ybase axis is therefore on the bearing surface in perpendicular direction to the first rotation axis of the positioner.

The positioner flange reference system is defined according to the following conventions (see Fig. 16.6):

– the origin of the flange reference system (Oflange) lays on the surface of the flange to coincide with the centre of rotation of the positioner second axis;

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.

OPTION AXIS VALUE

Axis length [mm] 7 L1

Axis type 7 ROTATING


Program speed override 7 X1

OPTION AXIS VALUE



Axis offset [mm] 8 L2


169hs-0-0-mot_04.fm

00/0210



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


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,

Both of these conditions are important: an approximation in relation to one of these will jeopardise the machine precision during cooperative motion (the robot does not hold the position on the part.).


170hs-0-0-mot_04.fm

00/0210


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.

Fig. 16.7 - Parameters for the kinematic description of the positioner

1 - axis 1 2 - axis 2 3 - part to be machined

$AX_LEN[ax_logic1] = L1 $AX_OFST[ax_logic2] = -L2

For example, for a positioner formed by auxiliary axes 7 and 8: ax_logic1 = 7 e ax_logic2 = 8


Two tables follow that summarise the useful mechanical data, assuming that the positioner is handled with auxiliary axes 7 and 8 respectively.

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

OPTION AXIS VALUE





171hs-0-0-mot_04.fm

00/0210


16.7 Positioners with 2 non perpendicular axes, type PTORB-alfa

16.7.1 Definition of the reference system

The positioner base reference system is defined according to the following conventions (see. ):

– The origin of the positioner base reference system (Obase) lays on the bearing surface(typically the floor);


– the Xbase axis lays on the bearing surface and is perpendicular to the two axes of the positioner;

– the Ybase axis consequently results with the direction indicated in .

The positioner flange reference system is defined according to the following conventions (see ):

– The origin of the flange reference system (Oflange) lays on the flange surface coinciding with the centre of rotation of the positioner second axis;


Fig. 16.8 - Definition of the reference systems

1 - axis 1 2 - axis 2 Xb, Yb, Zb, Ob= Xbase, Ybase, Zbase, Obase Xf, Yf, Zf, Of = Xflange, Yflange, Zflange, Oflange

OPTION AXIS VALUE



Axis offset [mm] 8 -L2


172hs-0-0-mot_04.fm

00/0210


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).

16.7.3 Kinematic description

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.

Fig. 16.9 - Parameters for the kinematic description of the positioner

1 - part to be machined

$AX_LEN[ax_logic1] = L1 $AX_LEN[ax_logic2] = L3 $AX_OFST[ax_logic1] = alpha, with alpha that is not 90° $AX_OFST[ax_logic2] = L2For example, for a positioner formed by auxiliary axes 7 and 8: ax_logic1 = 7 e ax_logic2 = 8

Both of these conditions are important: an approximation in relation to one of these will jeopardise the machine precision during cooperative motion (the robot does not hold the position on the part).


173hs-0-0-mot_04.fm

00/0210



Two tables follow, summarising the useful mechanical data, assuming that the positioner is handled with auxiliary axes 7 and 8 respectively.

16.8 Integrated robot positioning axes– Integrated slide

– Integrated rotating column

– Three linear axes portal

– Two linear axes Portal

– Integrated trans-rotational Column

16.8.1 Integrated slide

Regarding the configuration of a robot resting on a linear slide handled by an auxiliary axis.

By integrated motion it is intended that the calculation of the TCP position takes into account the position of the slide (only X axis). In other words, the slide is integrated in the direct kinematics of the system of axes.This has two practical effects:

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..

OPTION AXIS VALUE



Axis offset [mm] 7 *


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.

OPTION AXIS VALUE



Axis offset [mm] 8 L2


174hs-0-0-mot_04.fm

00/0210


– 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.


The integrated slide base reference system is defined according to these conventions (see Fig. 16.10):

– The origin of the slide base reference system (Obase) lays on the bearing surface (typically the floor);


– the Xbase axis lays on the bearing surface and orientated in the direction of the positive stroke;

– the Ybase axis consequently results with the direction indicated in Fig. 16.10.

The Z axis reference of the $BASE variable to the slide is not managed and therefore this remains linked to the position of the robot base.

On the slide there is the mounting flange of the robot base that can only be positioned standing with the base always perpendicular to the slide motion axis.

Vice-versa 4 robot base orientation positions are allowed (at 90° intervals ) in relation to the slide base (see Fig. 16.12).


1. slide base reference2. robot base

Xbs, Ybs, Zbs = Xbase_slide, Ybase_slide, Zbase_slideXbr, Ybr, Zbr = Xbase_robot, Ybase_robot, Zbase_robot

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).

175hs-0-0-mot_04.fm

00/0210



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.


The parameters needed for the correct kinematic description of the integrated slide are indicated in Fig. 16.11.


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.

Fig. 16.11 - Parameters for the kinematic description of the integrated slide

L = slide useful strokeXbs, Ybs, Zbs = Xslide_base, Yslide_base, Zslide_base

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;


OPTION AXIS VALUE

Axis length [mm] 7 L

Axis type 7 TRANSLATING


Program speed override 7 X

176hs-0-0-mot_04.fm

00/0210


– 0° rotation ==> Xrobot_base in the direction of Xslide_base;

– 270° rotation ==> Xrobot_base in opposite direction to Yslide_base ;

– 90° rotation ==> Xrobot_base in the direction of Yslide_base;

Fig. 16.12 - Assembly angle

Xbs, Ybs = Xslide_base, Yslide_base Xbr, Ybr = Xrobot_base, Yrobot_base

16.8.2 Integrated rotating column

Regarding the configuration of a robot resting on or hanging from a lever on the rotating column handled by an auxiliary axis .

By integrated motion it is intended that the calculation of the TCP position takes into account the position of the column. In other words, the column is integrated in the direct kinematics of the system of axes.

This has two practical effects:

– The Cartesian positions (POSITION) are defined in the cell space regardless of the rotating column axis position and therefore moving only the column will change the Cartesian position;

– Manually moving the column (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 lever displacement ;


The integrated column base reference system (defined by variable $BASE) is defined according to the following conventions (see Fig. 16.13):

– The origin of the column base reference system (Obase) lays on the bearing surface (typically the floor);


– the Xbase axis lays on the resting surface and is oriented in the direction of the robot cantilever in calibration position (see Fig. 16.13);

– the Ybase axis consequently results with the direction indicated in Fig. 16.13.

On the cantilever (lever) there is the mounting flange of the robot base that can be arranged in two positions only: either hanging on the lever (see Fig. 16.13) or resting on

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.

177hs-0-0-mot_04.fm

00/0210


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


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.


The parameters needed for the column correct kinematic description are indicated in Fig. 16.14.

It is also necessary to calculate the rotation speed to be attributed to the column being programmed, so that the maximum tangential speed does not exceed the value of 250 mm/s (see standard in force). Therefore, first of all radius r has to be measured with maximum robot extension, complete with tool mounted on the flange, as indicated in Fig. 16.14. Next, the configuration software, on the Teach Pendant, calculates the manual mode speed value.

Fig. 16.14 - Parameters for the kinematic description of the integrated column - 1

1 - column right-hand rotation R = column radius H = column height Xb, 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.

178hs-0-0-mot_04.fm

00/0210


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 ;

Fig. 16.15 - Parameters for the kinematic description of the integrated column - 2

Xbc, Ybc = Xcolumn_base , Ycolumn_base Xbr, Ybr = Xrobot_base Yrobot_base

16.8.3 Three linear axes portal

The current section describes the configuration of a robot mounted on a portal composed by three integrated linear auxiliary axes.

Integrated motion means that the TCP position calculation takes into account the portal position (thus the three X, Y and Z axes positions) besides the robot configuration; this implies that the portal 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 the portal axes, so even if the portal axes only are moved, the cartesian position is anyway modified;

– jogging (JOG) the portal axes 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 portal motion.

OPTION AXIS VALUE

(7) Axis length [mm] 7 R

(13) Axis type 7 ROTATING

(15) Axis offset [mm] 7 H

(18) Program speed override 7 X

179hs-0-0-mot_04.fm

00/0210



The base reference system of the Integrated 3 linear axes Portal is defined according to the following conventions (see Fig. 16.16):

– the origin of the reference system of the Portal Base (Obase) lays on the bearing surface;

– Zbase axis is perpendicular to the bearing surface, exiting from it and oriented according to the Z axis positive stroke;

– Xbase lays on the bearing surface and is oriented according to the X axis positive stroke;

– Ybase consequently results.

The mounting flange of the robot base is on the portal.

It is possible to configure the mounting angle of the robot base.

It is also possible to configure the axis type (X, Y e Z) for each one of the three portal axes (please note that the first one must be axis 7 and the next axes are in sequence).

Fig. 16.16 - Definition of the reference systems


The calibration position of the Portal, is usually defined close to the negative stroke of each auxiliary axis, marked with a zero notch.

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

180hs-0-0-mot_04.fm

00/0210



The parameters needed for the 3 linear axes Portal kinematic description are indicated in Fig. 16.7. 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 ones are in sequence.

Fig. 16.17 - Parameters for the kinematic description of the 3 linear axes Portal

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.

To configure the 3 linear axes Portal, please also refer to the C5G Control Unit Usemanual, par. AUX_AXES .

OPTION AXIS VALUE


Axis type [Tras/Rot] 7 TRANSLATING

Axis offset [mm] 7 H

Axis type [Coord] 7 [X,Y,Z]







181hs-0-0-mot_04.fm

00/0210


16.8.4 Two linear axes Portal

The current section describes the configuration of a robot mounted on a portal composed by two integrated linear auxiliary axes.

Integrated motion means that the TCP position calculation takes into account the portal position (thus the two XY, XZ and YZ axes positions) besides the robot configuration; this implies that the portal 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 the portal axes, so even if the portal axes only are moved, the cartesian position is anyway modified;

– jogging (JOG) the portal axes 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 portal motion.


The base reference system of the Integrated 2 linear axes Portal is defined according to the following conventions (see Fig. 16.18):

– the origin of the reference system of the Portal Base (Obase) lays on the bearing surface;

– Zbase axis is perpendicular to the bearing surface, exiting from it and oriented according to the Z axis positive stroke;

– Ybase lays on the bearing surface and is oriented according to the Y axis positive stroke;

– Xbase consequently results.

The mounting flange of the robot base is on the portal. It is possible to configure the mounting angle of the robot base.

It is also possible to configure the axis type (X, Y e Z) for each one of the two Portal axes (please note that the first one must be axis 7 and the next one is in sequence).


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

182hs-0-0-mot_04.fm

00/0210



The calibration position of the Portal, is usually defined close to the negative stroke of each auxiliary axis, marked with a zero notch.


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.

Fig. 16.19 - Parameters for the kinematic description of the 2 linear axes Portal

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.

16.8.5 Integrated trans-rotational Column

The current section describes the configuration of a robot bearing on or hanging from a lever on the rotating column, handled by an auxiliary axis which is, in turn, bearing on a linear rail handled by a second auxiliary axis.

To configure the 2 linear axes Portal, please also refer to the C5G Control Unit Usemanual, par. AUX_AXES .

OPTION AXIS VALUE



Axis offset [mm] 7 H





183hs-0-0-mot_04.fm

00/0210


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.


The base reference system of the Trans-rotational Column is defined according to the following conventions (see Fig. 16.20):

– the origin of the reference system of the trans-rotational Column Base (Obase) lays on the bearing surface (which usually is the floor);

– Zbase axis is perpendicular to the bearing surface, exiting from it and oriented upwards;

– Xbase lays on the bearing surface and is oriented according to the rail axis positive stroke;

– Ybase consequently results, having the direction shown in Fig. 16.20.

On the cantilever (lever) there is the mounting flange of the robot base that can be arranged in two positions only: either hanging on the lever (see Fig. 16.20) or bearing on 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. Furthermore, it is also allowed to select the mounting angle of the column base on the rail flange ( angle shown in Fig. 16.21), as well as the offset between the rail flange and the column base (H1 in Fig. 16.21).

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

184hs-0-0-mot_04.fm

00/0210




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.


The parameters needed for the Integrated trans-rotational Column complete kinematic description are indicated in Fig. 16.21.

It is also necessary to calculate the rotational speed to be set for the Column while in PROGR mode, so that the maximum tangential speed does not exceed the value of 250 mm/s (see standard in force). Therefore, first of all radius r has to be measured with maximum robot extension, equipped with the tool mounted on the flange, as indicated in Fig. 16.21.

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 Integrated trans-rotational Column is number 7 and it is the linear axis of the Rail (the translating axis).

To configure the Trans-rotational Column, please also refer to the C5G Control Unit Use manual, par. AUX_AXES .

OPTION AXIS VALUE

Axis length [mm] 7 L


Axis offset [mm] 7 H1

Axis length [mm] 8 R

185hs-0-0-mot_04.fm

00/0210


Fig. 16.21 - Parameters for the kinematic description of the Integrated Trans-rotational Column

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 .

Axis type [Tras/Rot] 8 ROTATIONAL

Axis offset [mm] 8 H2

OPTION AXIS VALUE

186hs-0-0-mot_04.fm

00/0210

TO_SET Program - Tool handling

17. TO_SET PROGRAM - TOOL HANDLING

17.1 IntroductionTO_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)


02/0610


17.2 ActivationTO_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).

Fig. 17.1 - Access to TO_SET program

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

17.2.1 From Teach Pendant

To reinstall TO_SET from the Teach Pendant, follow the procedure described below:

a. Select the SETUP Page and choose the Install function

TO_SET program is always present in the Controller Unit


02/0610


b. Select the device containing the TO_SET files

c. Select the TO_SET program

d. Press ENTER to confirm.

17.2.2 From WinC5G on Personal Computer

To reinstall TO_SET from a Personal Computer that has the WinC5G program installed, follow the procedure described below:


02/0610


a. select the directory containing the TO_SET files

b. from the WinC5G terminal, send the FilerUtilityInstall TO_INST.COD command

17.3 First screen page of TO_SETIn Fig. 17.2, the MAIN MENU is displayed.

TO_SET is presented in this way, as soon as it is activated.

Fig. 17.2 - Screen page 0.0

The screen page contains the following information:

The following detailed description illustrates the available procedures, specifically:

– TOOL automatic calculation

– UFRAME automatic calculation

– BASE automatic calculation for POSITIONERS (optional)

– Payload identification (optional function)

TO_SET 003 program name + version number

Ov:100 the value of $GEN_OVR

Ar: 1 the number of the selected ARM

Ty: Jnt type of selected movement

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.


02/0610


17.4 TOOL automatic calculationPress F1 in TO_SET main menu (see Fig. 17.2) to enter it.In this environment it is possible to define the dimensions of the work tool mounted on the robot flange. The precision of the calculation is the same as the robot, used as a measuring instrument.

Detailed information is given on the following:

– Needed Tools

– General characteristics

– Procedure

17.4.1 Needed Tools

– Calibrated tool (Tool Master)

– Reference point (or master cube)

17.4.1.1 Calibrated tool (Tool Master)

This is a calibrated tool with known X, Y, Z measurements that will be mounted on the robot flange for the acquisition of the reference position. As an alternative an identified point on the work tool can be used, for which the distance from the robot flange centre must be known and precise.

Taking as an example a Smart NJ 110-3.0 o NJ 130-2.6, the calibrated tool may be :

measurement: 117 [mm]

In this case the calibrated tool is to be mounted on the robot flange in X_tool direction and the values to be declared are : X=190, Y=0, Z=-8.

Fig. 17.3 - SMART NJ 110-3.0 o NJ 130-2.6 - Calibrated tool

For any further information about the calibrated tool, see the Robot Technical Specifications Manual.

17.4.1.2 Reference point (or master cube)

It is very important to identify a physical reference point in the environment surrounding the robot, so as to bring the robot TCP on to this point: once with the Tool Master then


02/0610


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).

17.4.2 General characteristics

– The TOOL MASTER can be mounted in Z_tool or in X_tool. Position B is made possible by a threaded precision hole on the robot flange. In this way it is possible to have the measuring tool mounted on the flange and at the same time the tool master screwed on the flange in X_tool direction.

– Possibility to calculate the tool with the robot on the FLOOR, on the WALL or hanging from the CEILING , taking care to position the cube (or any other point taken as reference) 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).

– All the robot positions on the reference, whether with tool master or with measuring tool, are not rigid: the operator can position the TCP on the reference as desired, according to requirements.

– Possibility to calculate the tool relocation as to the robot flange centre (X, Y, Z Tool) with three reset Euler angles (orientation nil).

– Possibility to calculate (besides X, Y, Z Tool) also the rotations around X_tool and Y_tool (<A>: Euler 1 and <E>: Euler 2) so as to fix the new Z_tool on the tool, in the required direction and sense (see also Tool orientation calculation).

– Possibility to calculate (besides X, Y, Z, A, E Tool) also the rotation around the new Z_tool (<R>: Euler 3), so as to fix for a certain "tool plane" the direction and sense of the X_tool and Y_Tool , rotating around the new Z_tool (see also Tool orientation calculation).

Detailed descriptions are given below, dealing with the following subjects:

– Tool orientation calculation

– How to identify the "dummy reference system"

17.4.2.1 Tool orientation calculation

After calculating the dimensions of the tool to be measured (X, Y, Z Tool), with TO_SETan orientation (A, E, R Tool) can also be fixed to the new TCP

To fix the orientation on the new TCP a known reference system is necessary.

TO_SET has defined this reference system on the "reference point" .

The "dummy reference system" is created by TO_SET when the robot is brought on to the "reference point" with TOOL MASTER (Complete procedure ) and will be assumed by the new TCP every time the robot is brought to the "reference point" with "TOOL TO BE MEASURED" to calculate the orientation.

17.4.2.2 How to identify the "dummy reference system"

It is advised (with values of $BASE = 0) to make positive and negative movements in BASE for axis 1 (X_base), axis 2 (Y_base) and axis 3 (Z_base) .Knowing that X_rifer = -X_base; Y_rifer = Y_base; Z_rifer = -Z_base, it is easy to identify the direction and the sense of the "dummy reference system".


02/0610


– 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:

F1: calculates LOCAL TOOL ; a second screen page is accessed (Fig. 17.5 - Screen page 1.1) that asks the user to insert the number of the tool to be measured or checked

F2: calculates REMOTE TOOL(see. par REMOTE TOOL Automatic Calculation)

F6: returns to main menu (see Fig. 17.2)


02/0610



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:

F1: executes Tool calculation with standard method - Complete procedure; access given to screen page 1.4 (in Fig. 17.8)

F2: executes Tool verification with standard method - Partial procedure; access given to screen page 1.6 (in Fig. 17.10)


02/0610


If the Tool already exists in the table, Fig. 17.7 is shown.


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

17.4.4 Tool calculation with standard method - Complete procedure

The procedure is accessed by pressing F1, Fig. 17.6.

When to execute the procedure:

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).

F3: executes Tool Calculation with "4 points method" - Complete procedure; access given to screen page 1.17 (in Fig. 17.21)


F1: tool verification; there are two possibilities:• when the standard method is used access is given to partial procedure

screen page 1.6 (in Fig. 17.10),• when the 4-points method is used , access is given to screen page 1.17

(in Fig. 17.21)

F2: executes a new calculation then returns to screen page 1.2 (in Fig. 17.6)


– 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.


02/0610



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:

F1: continues the procedure (see Fig. 17.9)

F2: changes tool master values (see Fig. 17.17)


F1: to be pressed when the robot is on the point; continues procedure (Fig. 17.10)

F6: returns to main menu (Fig. 17.2)


02/0610


17.4.5 Tool verification with standard method - Partial procedure

To have access to this procedure press F1 from Fig. 17.7 or F3 from Fig. 17.6.

When to execute:

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:

Only if the Complete procedure has been executed at least once.

F1: to be pressed when the robot is on the point; continues procedure (Fig. 17.11)



02/0610



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:


F1: continues the procedure (Fig. 17.12)

F2: saves calculated values (Fig. 17.16 or remains Fig. 17.11)

F3: repeats procedure: (returns to Fig. 17.10)

F6: returns to main menu (Fig. 17.2).

See paragraph on Tool orientation calculation.


02/0610


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:



Accepted commands:

F1: to be pressed when orientation has been completed; continues procedure (Fig. 17.13)

F2: directs the Z_TOOL in relation to +X_BASE or -X_BASE

F3: directs the Z_TOOL in relation to +Y_BASE or -Y_BASE

F4: directs the Z_TOOL in relation to +Z_BASE or -Z_BASE


F1: continues the procedure (Fig. 17.14)

F2: saves calculated values (Fig. 17.16 or remains in Fig. 17.13)

F3: repeats the procedure; (returns to Fig. 17.12)



02/0610



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:



Accepted commands:

F1: to be pressed when orientation has been completed; continues procedure (Fig. 17.13)

F2: directs the X_TOOL in relation to +X_BASE

F3: directs the X_TOOL in relation to -X_BASE

F4: directs the X_TOOL in relation to +Y_BASE

F5: directs the X_TOOL in relation to -Y_BASE

F6: returns to main menu (Fig. 17.2 - Screen page 0.0).


02/0610


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

F1: returns to Fig. 17.6

F2: saves calculated values (Fig. 17.16 or remains in Fig. 17.15)

F3: repeats the procedure (returns to Fig. 17.14)


esc: to omit the insertion of each separate value


02/0610


that the master reference position is missing (check TO_SET.VAR).

If the answer is OK, the system returns to the screen page shown in Fig. 17.9.


Accepted commands:

The screen page in Fig. 17.19 displays whether the SAVE procedure for the calculated values has been omitted.


Accepted commands:

17.4.6 Tool Calculation with "4 points method" - Complete procedure

To access this procedure, press key F3 of screen page 1.2 in Fig. 17.6.

This procedure brings the TCP to a visible reference point within the robot working space, with at least three different orientations and acquires the relevant positions

F1: returns to Fig. 17.6


F1: repeats Save



02/0610


(see Fig. 17.20).

Fig. 17.20 - Points acquisition

1. acquisition point 32. acquisition point 23. acquisition point 14. reference

Follow these steps:

a. Move the TCP to the reference point

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

e. Execute steps c. and d. again to acquire point 3

f. If the TCP measurement is possible, the user is given an evaluation of the acquisition procedure accuracy (and not the tool measurement precision) with the possibility to accept the measurement supplied and continue with the orientation calculation (step j.) or to continue with the acquisition of points with the possibility to move the robot in Tool mode (step g.)

g. Move the TCP back to the reference point with a sufficiently different orientation as to the previous points

h. Teach the new point (max. 8 points )

i. Execute step f. again

j. End of points acquisition : it is possible to continue with the orientation calculation, repeat the calculation of X, Y and Z, return to main menu.

As from the acquisition of point 3, the tool calculation algorithm is sent, since if the acquired points are independently linear, the three X, Y and Z coordinates are obtained in output that permit the definition of the TCP.

As mentioned in the procedure description, together with the TCP measurement , the user is given an evaluation of the acquisition procedure accuracy (this assesses the standard deviation, acquired points dispersion index). The two evaluation classes may


02/0610


be : imprecise measure and good measure. If the measurement is imprecise it is necessary to continue with the acquisition of a new point, whereas the procedure is considered completed when the measurement is good. If the acquisition of the eighth point is reached without obtaining a good measurement of the tool, the procedure has to be repeated from the start.

Continuing with the description of the user interface, once the tool calculation environment is entered with the 4 points method, the following screen page is displayed:


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):

Fig. 17.22 - Screen page 1.19a

Accepted commands:

F1: continues to acquire a new point (Fig. 17.21)


02/0610


– If the calculation algorithm returns a tool good measurement the following screen page is shown (Fig. 17.23):

Fig. 17.23 - Screen page 1.19b

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!

Fig. 17.24 - Screen page 1.19c

Accepted commands:

17.4.6.1 Local Tool verification with "4 points method"

This is accessed by pressing F1 key (Fig. 17.7), Tool Verification.

F2:

accepts the calculated tool and continues according to the mode described in Fig. 17.11 (the calculation procedure for the Euler angles remains unchanged ), bearing in mind that the calculated tool is not precise!

F1: repeats the calculation (see Fig. 17.21)



02/0610


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:

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.

17.4.7 REMOTE TOOL Automatic Calculation

This can be accessed by pressing F2 key from the screen page in Fig. 17.4, i.e. from

F1: If the move is reached and the position is OK, press F1

F2:

If it is wished to force termination of the Move (either because the TCP has already been reached or because it is considered better to position the reference on the TCP with movements in Jog), press F2


Be sure that the movement is executed at the speed indicated on the Teach Pendant!


02/0610


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


17.4.7.1 Tools needed

17.4.7.1.1 Tool with known dimensions mounted on Robot Flange

A reference tool must be mounted on the flange that has known dimensions declared in the $TOOL system variable.The coordinates will be indicated as X_rif, Y_rif and Z_rif.

It is advised to use the TOOL MASTER or CALIBRATED TOOL that was used for the Tool automatic calculation (see paragraph 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.

17.4.7.2 General characteristics

In case of TOOL_RMT command (pressing F2 key) the procedure is the same as the Tool calculation (F1).

Whereas for the tool the reference is the robot BASE , for the remote tool it is necessary to define the X, Y and Z references of the tool fixed on the robot flange, indicated as Xrif, Yrif and Zrif.At the end of the procedure, before returning to the main menu(Fig. 17.2), the user is asked whether the remote tool is to be kept enabled (Fig. 17.26)


If F1 is pressed, the Remote Tool remains enabled, if F2 is pressed the start situation is resumed.

17.5 UFRAME automatic calculationThis environment is entered by pressing key F2 from the main menu of TO_SET (Fig. 17.2). In this environment a new reference system can be defined in relation to which the work positions will be taught. The precision of the calculation is the same as the robot, used as a measuring tool.


02/0610


Detailed information is given on these subjects:

– Needed Tools


– Procedure

17.5.1 Needed Tools

The following topics are described:

– Tool with known dimensions mounted on Robot Flange

– 3 Reference Points (ORIGIN, Xpos and XYpos)

17.5.1.1 Tool with known dimensions mounted on Robot Flange

A tool must be mounted on 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.

17.5.1.2 3 Reference Points (ORIGIN, Xpos and XYpos)

3 reference points have to be identified on the workpiece :

– ORIGIN: where the FRAME origin will be fixed;

– Xpos: X-frame direction and sense

– Xypos: Y-frame direction and sense

The direction and sense of the Z-frame are always considered outgoing upwards as to the XY-frame plane.

The $UFRAME is always calculated in relation to the robot environment that coincides with the origin of the robot base when $BASE=0


None of the robot positions on the 3 reference points are rigid: the operator can position the TCP on the references as preferred, according to requirements.

At the end it is possible to save the Frame calculation in the TU_FRAME table (see Fig. 17.33).

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:


02/0610



Another screen page is then shown (Fig. 17.28):


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:

F1: continues procedure (Fig. 17.29)

F2: changes the $TOOL values (Fig. 17.34)



02/0610



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:


Asks to move the tool TCP to the 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:

F1:to be pressed when the robot is on point; continues procedure (Fig. 17.30)


F1: to be pressed when the robot is on point; continues procedure (Fig. 17.31)



02/0610



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:

Fig. 17.32 - Screen 3.5

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)

F1:to be pressed when the robot is on point; continues procedure (Fig. 17.32 o Fig. 17.36)



02/0610


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:


Displays the $TOOL values currently declared (XYZ relocations and AER orientations) and allows their modification.

F1: returns to screen page in Fig. 17.28

F2: saves calculated values (Fig. 17.33 or Fig. 17.36)


TU_FRAME is available in the System Software CD, in the Configuration Tools directory.

<esc>: to omit the SAVE request. In this case the screen page will be displayed in (Fig. 17.35)


02/0610


Accepted commands:


Displayed if the SAVE procedure for the calculated values has been omitted .

Accepted commands:


Displayed if it is not possible to execute the $UFRAME calculation.

Check:

– robot calibration;

– the $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)

Accepted commands:

esc: to omit the insertion of each separate value




02/0610


17.5.4 REMOTE UFRAME automatic calculation

This environment is entered by pressing key F2 from the main menu of TO_SET(Fig. 17.2). If a remote tool is declared , the part mounted on the robot flange becomes the REMOTE UFRAME and has its own reference system. In this environment the new reference system can be defined in relation to which the work positions will be learnt. The precision of the calculation is the same as robot, used as measuring system.

Detailed information is given on these subjects:

– Needed Tools


– Procedure

17.5.4.1 Needed ToolsThe following topics are described:

– Tool with known dimensions mounted onto the Robot Flange

– 3 reference points (ORIGIN, Xpos and XYpos)

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.

17.5.4.1.2 3 reference points (ORIGIN, Xpos and XYpos)

3 reference points are to be identified on the workpiece :

– ORIGIN: where the FRAME origin is fixed;

– Xpos: determines the X-frame direction and sense

– Xypos: determines the Y-frame direction and sense

The direction and sense of the Z-frame are always considered outgoing upwards as to the XY-frame plane.

$UFRAME is always calculated in relation to the robot environment that coincides with the origin of the robot base when $BASE=0.

17.5.4.2 General characteristics

None of the robot positions on the 3 reference points are rigid: the operator can position the TCP on the references as preferred, according to requirements.

It is allowed to save the frame calculation result, in the UFRAME table, in Data Page.




02/0610


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:


Asks to take the tool TCP on the ORIGIN point.

The robot may be in any position: the operator can move the TCP to the ORIGIN point as preferred, according to requirements.

Accepted commands:

Be careful: the Remote Tool is enabled!


F2: changes the $TOOL values (Fig. 17.43)



02/0610



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:





F1:to be pressed when the robot is on position; continues procedure (Fig. 17.41 o Fig. 17.45)



02/0610



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.


F2: saves calculated values (Fig. 17.42 or screen page Fig. 17.46)


TU_FRAME is contained in the system software CD, in the Configuration Tools directory.


02/0610


Accepted commands:


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:

<esc>: to omit the SAVE request. In this case the screen page will be displayed in Fig. 17.44

<esc>: to omit the insertion of each separate value




02/0610



Displayed if it is not possible to execute the $UFRAME calculation.

Check:

– robot calculation;

– the $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).

Accepted commands:

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).




02/0610


17.6 BASE automatic calculation for POSITIONERS (optional)This environment is entered by pressing F3 from the TO_SET main menu (see Fig. 17.2 - Screen page 0.0). In this environment the reference system of a positioner can be defined in relation to the robot, to obtain the cooperative movement between robot and positioner.

The precision of the calculation is the same as for the robot, used as a measuring tool.

A detailed description is given below for:

– Tools required


17.6.1 Tools required

A detailed description is given for the following topics:

– Tool of known dimensions mounted on the robot flange

– 3 reference points (P1, P2, P3)

17.6.1.1 Tool of known dimensions mounted on the robot flange

It is necessary that a tool of known dimensions and declared in the $TOOL system variable has been mounted on the robot flange. It is best to use the Tool Master or Calibrated Tool (the same used for the TOOL automatic calculation (see TOOL automatic calculation)). As an alternative it is also possible to use a point identified on the work tool, that has a distance from the robot flange centre that is precise and known.

17.6.1.2 3 reference points (P1, P2, P3)

The 3 reference points are always present on the COMAU positioners.These may be threaded holes, to fasten the 150 mm. calibrated tool or references stamped on the positioner.


– The robot positions on the 3 points are not rigid: the operator can position the TCP on the references at will, according to requirements.

– The calculated values will be saved in UD:\SYS\ in the .C5G system file and thus can be recovered using Config. (F1) command, Load the configuration file(CLA), SETUP Page on the Teach Pendant.

– The positioner can be seen by the system either as an auxiliary axis or as ARM (in the case of double arm). In the first case the axis to which the positioner is associated must be defined.

– The calculated values will be automatically assigned to the following system variables:• For an auxiliary axis:

$ARM_DATA[narm].AUX_BASE[npositioner]• For arm:

$ARM_DATA[narm].BASE


02/0610



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:

F1: procedure cont. (Fig. 17.48)

F2: to change the values of $TOOL (Fig. 17.57)



F2: to change the values of the reference calibrated tool (Fig. 17.57)



02/0610



To select the type of positioner for the BASE calculation.AUX: positioner seen as an auxiliary axis; ARM: positioner seen as an ARM.

Accepted commands:


To insert the positioner ARM number (1-4). If the entered ARM number is not acknowledged by the system, the screen page of Fig. 17.59 is displayed; if it is acknowledged, the screen page of Fig. 17.52 is displayed.

Accepted commands:

F1: type of ARM; continue (Fig. 17.50)

F2: type of auxiliary axis; continue (Fig. 17.51)


<esc>: omits the insertion (returns to the screen page of Fig. 17.49)


02/0610



To insert the positioner number (1-4).

If the entered positioner number is not acknowledged by the system, the screen page of Fig. 17.60 is displayed; if it is acknowledged, the screen page of Fig. 17.52 is displayed.

Accepted commands:


Asks the operator to move the tool TCP to point P1.

The robot can assume any position: the operator can move the TCP to point P1 as desired, according to the requirements.

Accepted commands:

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

<esc>: omits the insertion (returns to the screen page of Fig. 17.49)

F1: to press when the robot is on position; continue (Fig. 17.53)



02/0610





Accepted commands:




Accepted commands:

F1: to press when the robot is on the point; cont. (Fig. 17.54)


F1: to press when the robot is on the point; cont.(Fig. 17.55 or Fig. 17.61)



02/0610



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:



F2: saves calculated values. Note: to perform the SAVE operation, it is necessary to be in PROG + DRIVES OFF; procedure continue (Fig. 17.56 or Fig. 17.62)



02/0610


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:



<esc>: permits the omission of each separate value insertion

<esc>: allows omitting each separate value insertion


02/0610



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:






02/0610



Displayed if it is not possible to perform the $BASE calculation.

Check:

– the robot calibration;

– the $TOOL values (they are to refer to the tool mounted on the flange);

– the declared values of the reference calibrated tool;

– the 3 reference points (check that the sequence required by TO_SET has been respected).

Accepted commands:


Displayed when a SAVE operation (from Fig. 17.55) has been requested but the C5Gis 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:






02/0610


17.7 Payload identification (optional function)

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.

This paragraph supplies information regarding

– Basic concepts regarding Payload identification

– Procedure for Payload identification

– Software to validate the payload (SMART Payload).

17.7.1 Basic concepts

As the correct declaration of the tool dimensions (variable $TOOL) is necessary to obtain the required precision in execution of movements in the Cartesian environment, in the same way it is equally necessary to correctly define the payload parameters that will have influence on the robot movements in terms of performance optimisation and safeguarding the components.

The determination of the payload characteristics takes place using the specific procedure.

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 :

Press F4 key in the screen page in Fig. 17.2, to access this procedure.

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.


02/0610


– $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.

This paragraph contains the following information:

– Requirements to modify Payload identification programs

– Activation and execution of the Payload identification procedure

17.7.2.1 Requirements to modify Payload identification programs

When changing Payload identification programs be sure to:

– Keep axis 3 in horizontal position

– have appropriate extension of the strokes of the axes involved.

The user can intervene, reducing the movement frequency of the individual axes, move axis 1 as desired and move axes 2 and 3 as necessary, but ALWAYS ensuring that axis

It may be that individually the values produced by the Payload identification procedure have a certain tolerance in relation to the actual values. In any case, the way the dynamic model is designed, the consistency of these values is important.

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).

The entire Payload Identification procedure is performed with the DYNAMIC MODEL DEACTIVATED automatically by the system.


02/0610


3 is horizontal to the floor.

Since any modifications made to movement programs could reduce the precision of the Identification procedure results, upon request Comau Robotica can supply an off-line instrument to validate the results. See par. 17.7.2.3 Software to validate the payload (SMART Payload) on page 239.

17.7.2.2 Activation and execution of the Payload identification procedure

a. If TO_SET program is to be installed again, follow par. 17.2 Activation on page 188description.

b. The User is requested to insert the Payload number:

Fig. 17.63 - LOAD number

c. Specify whether the tool is remote or not:

Fig. 17.64 - Remote or Local Tool

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)

Press F4 key from the screen page in Fig. 17.2, to access this procedure.


02/0610


e. keep the Enabling Device pressed on the Teach Pendant

f. press START key to move the robot to calibration position

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:

The procedure includes movements that involve axes 3, 4, 5 and 6.


02/0610


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.

h. this screen page is shown:

Run the verification program. If it has terminated correctly, choose TEST FINISHED (F1). If the robot is NJ4 series, a second test is suggested and therefore this point is executed again. Otherwise pass directly to point j.If the verification program has not terminated correctly, choose POSITION MODIFY (F2).

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:


02/0610


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

j. this screen page is shown.


02/0610


before starting to execute real Payload identification programs, it is advised to warm up the robot, making movements that involve the wrist and axis 3. If it is decided not to run an automatic warm-up, select NO (F2) and go to step k.; if it is decided to run the automatic warm-up, select YES (F1)

j.1 set the required speed

j.2 set the modal selector switch to AUTO

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

If HOLD is pressed, the procedure is interrupted and cannot be continued.


02/0610


j.5 select CONTINUE (F1)

k. this screen page is shown:

set GEN_OVR at 100% then choose CONFIRM YES (F1)

l. switch off the drives by pressing DRIVE OFF


02/0610


m. check that the modal selector switch is set to AUTO

n. switch on the drives pressing DRIVE ON and press START key

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

p. select CONTINUE (F1)


02/0610


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

r. switch off the drives, pressing DRIVE OFF

s. check that the modal selector switch is set to AUTO

t. switch on the drives pressing DRIVE ON and press START


02/0610


u. the execution of the second motion program starts (at normal speed). Wait until completion

v. switch off the drives, pressing DRIVE OFF.

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:

– TT_TOOL.VAR if the TOOL is LOCAL – TU_FRAME.VAR if the TOOL is REMOTE.

This terminates the procedure and the initial choice screen page returns (Fig. 17.4).

To exit choose RETURN TO MENU (F6).

17.7.2.3 Software to validate the payload (SMART Payload)Comau Robotics supplies, upon request, an off-line software tool called SMART Payload, that can check the correctness of the values calculated by the Payload identification procedure .

This tool checks that the obtained payload values are within the limits set by the static load curve of the specific robot.


02/0610

Interference Regions (optional feature)

18. INTERFERENCE REGIONS (OPTIONAL FEATURE)

18.1 IntroductionInterference 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.

18.2 Regions typesTwo kind of Regions are defined:

– Forbidden Regions • Cartesian Forbidden Regions• Joint Forbidden Regions

– Monitored Regions• Cartesian Monitored Regions• Joint Monitored Regions.

Each one of them can be either Cartesian, if defined by a volume with predefined geometrical shape, or Joint, if defined by robot axes allowed stroke intervals.

One more Region type depends on the permanence feature of the Region. In particular, for any Region type it is allowed to declare it to be Permanent, which means that the Region is memory resident, active and doesn’t depend on the being executed program. On the contrary, the non Permanent Region depends on the program in which it has been defined and it is automatically deactivated as soon as such a program is deactivated.

18.2.1 Cartesian Forbidden Regions

In these Regions the TCP (Tool Center Point) will never be allowed to enter. The algorithm takes charge of slowing down the Robot properly in advance, so that the velocity goes to zero on the Region boundary. The Robot is constantly monitored in any System state (both in AUTO and PROGRAM state) and the TCP velocity is modified depending on the distance from the Forbidden

240pr-0-0-gpr_13.fm

04/0711


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.

18.2.2 Cartesian Monitored Regions

Whenever the TCP either enters or exits from such Regions, a programmable boolean value is written to a logical output port, available to the User.

18.2.3 Joint Forbidden Regions

The Robot axes will NEVER be allowed to enter such Regions. The algorithm slows down the Robot properly in advance (taking care of each axis velocity component), so that the velocity goes to zero on the Region boundary. The Joint Forbidden Regions functioning principle is the stroke ends one, with some additional functions. The User is allowed to specify which joints are to be monitored to avoid reaching the Forbidden Regions, thus it is possible to define even just one joint to comply with some limitations. Particularly, it is possible to define an interval (e.g. [-20°, +50°]) inside which an axis motion must be restricted. The system takes care of restricting the axis motion to the positive and negative ends specified by the User.

18.2.4 Joint Monitored Regions

Whenever an axis either enters or exits from such Regions, a programmable boolean value is written to a logical output port, available to the User.

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.

18.3 Regions Shape and definition – Cartesian Regions shape and definition

– Joint Regions shape and definition.

18.3.1 Cartesian Regions shape and definition

There are four shapes for Cartesian Regions:

– Sphere

Such a logical port is associated to the Region by means of IR_SET built-in routine (detailed description in chap.BUILT-IN Routines List - PDL2 Programming Language Manual).

Such a logical port is associated to the Region by means of IR_SET built-in routine (detailed description in chap.BUILT-IN Routines List - PDL2 Programming Language Manual).

241pr-0-0-gpr_13.fm

04/0711


– 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.

Fig. 18.1 - Sphere

R - radius

18.3.1.2 Cylinder

By means of sequentially teaching points P1 and P2, the frame and the cylinder heightare 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.

242pr-0-0-gpr_13.fm

04/0711


Fig. 18.2 - Cylinder

H - height R - radius

18.3.1.3 Box

By means of sequentially teaching P1, P2, P3 points, frame and two dimensions (widthand 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.

Fig. 18.3 - Box

H - height W - width D - depth

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.

243pr-0-0-gpr_13.fm

04/0711


Fig. 18.4 - Plane

18.3.2 Joint Regions shape and definition

A Joint Region is a set of values, expressed either in degrees (rotational axis) or in millimeters (linear axis), of a whole Arm, delimitating the axes allowed strokes. The User can choose which axes to control.

Such strokes can be defined in two different ways:

– Specify the center of the allowed stroke, and the stroke tolerance within which the axis must move. The axes are positionned in the allowed stroke center. The tolerance is specified by means of the User Interfacee.

– Specify the allowed stroke ends. The axes are first positionned in the lowest end and then in the highest end of the allowed strokes.

Such Regions position and dimension definition is auto-taught. 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.

18.4 IR_LIB library to support Interference Regions creationBy means of this library, automatically loaded in memory at the Controller Unit Startup, the User can intuitively declare the wished cartesian and joint Interference Regions.

The previously described geometric shapes for Cartesian Regions, can be defined by means of PDL2 programs calling the following routines:

– IR_CreateSphere (ap_p1, ar_R, ai_num_arm, ai_t_idx)

– IR_CreateCylinder (ap_p1, ap_p2, ar_R, ai_num_arm, ai_t_idx)

– IR_CreateBox (ap_p1, ap_p2, ap_p3, ap_p4, ai_num_arm, ai_t_idx)

– IR_CreatePlane (ap_p1, ap_p2, ap_p3, ai_num_arm, ai_t_idx)

Furthermore, the following routine is given to declare Joint Regions:

– IR_CreateJoint (aj_neg_joint, aj_pos_joint, ai_num_arm, ai_mask, ai_t_idx)

Such routines are to be imported by the calling program either using the EXPORTED FROM clause:

244pr-0-0-gpr_13.fm

04/0711


or by means of the IMPORT statement:

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:

Previous code allows to create a monitored, non permanent, cylindrical (base - pnt0007P, height - pnt0008P, radius 200 mm) Interference Region.

The Region, defined as number 3 in $IR_TBL table, will assign the predefined value of OFF to the digital output bit 2 of $FMO[1], as soon as the TCP enters such a Region.

Example 2

In the following example a PDL2 program section is shown which creates a JointMonitored Region for axis 6 only.

ROUTINE IR_CreateSphere (ap_p1 : POSITION; ar_R : REAL; ai_num_arm ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL

ROUTINE IR_CreateCylinder (ap_p1, ap_p2 : POSITION; ar_R : REAL; ai_num_arm, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL

ROUTINE IR_CreateBox (ap_p1, ap_p2, ap_p3, ap_p4 : POSITION; ai_num_arm, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL

ROUTINE IR_CreatePlane (ap_p1, ap_p2, ap_p3 : POSITION; ai_num_arm, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL

ROUTINE IR_CreateJoint (aj_neg_joint, aj_pos_joint : JOINTPOS; ai_num_arm, ai_mask, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL

IMPORT ‘IR_DEF’

-- Cylinder definition: base=pnt0007P, height=pnt0008P, radius=200 mm,-- used for arm 1, Interference Region number 3

-- Creating Cartesian Region number 3IR_CreateCylinder(pnt0007P, pnt0008P, 200, 1, 3)

-- Associating Cartesian Region number 3 to digital output $FMO[1], bit 2, indicating that it is monitoredIR_SET($FMO[1], 2, 3, IR_PRESENCE, OFF)

-- Activating Cartesian Region number 3IR_SWITCH(ON, 3)

245pr-0-0-gpr_13.fm

04/0711


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.

ROUTINE IR_CreateJoint (aj_neg_joint, aj_pos_joint : JOINTPOS; ai_num_arm, ai_mask, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL

...............

...............

aj_neg_joint[6] := -60 -- axis 6 negative end aj_pos_joint[6] := 60 -- axis 6 positive end ai_arm := 1 -- arm number ai_mask := 0b00100000 -- axis 6 binary mask-- Creating Joint Region number 4 IR_CreateJoint(aj_neg_joint,aj_pos_joint,ai_arm,ai_mask,4) -- Associating Joint Region number 4 to digital output $FMO[1], bit 3, indicating that it is monitoredIR_SET($FMO[1], 3, 4, IR_PRESENCE, ON)

-- Activating Joint Region number 4 IR_SWITCH(ON, 4)

When a program is deactivated, which had executed IR_SWITCH(ON,...), the system automatically performs IR_SWITCH(OFF, ai_t_idx) for the Regions which had previously been activated by such a program.

246pr-0-0-gpr_13.fm

04/0711


18.5.1 Sample program for Cartesian Interference Regions

Here follows a PDL2 program sample which defines and uses some cartesian Interference Regions within a Robot motion program.

PROGRAM ir_cart PROG_ARM = 1VAR pnt0001J, pnt0002J, jnt0018J, jnt0019J , jnt0020J, jnt0021J, jnt0022J, jnt0023J : JOINTPOS FOR ARM[1] pnt0001P, pnt0002P, pnt0003P, pnt0004P, pnt0005P, pnt0006P, pnt0007P, pnt0013P, pnt0014P, pnt0015P, pnt0016P : POSITION

ROUTINE IR_CreateBox(ap_p1, ap_p2, ap_p3, ap_p4 : POSITION; ai_num_arm, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBALROUTINE IR_CreateSphere(ap_p1 : POSITION; ar_R : REAL; ai_num_arm, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBALROUTINE IR_CreateCylinder(ap_p1, ap_p2 : POSITION; ar_R : REAL; ai_num_arm, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBALROUTINE IR_CreatePlane(ap_p1, ap_p2, ap_p3 : POSITION; ai_num_arm, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBALROUTINE ToolFrame(ai_tool, ai_frame, ai_arm : INTEGER()) EXPORTED FROM TT_TOOL GLOBAL

BEGIN ToolFrame(3, 0) -- tool 3, frame 0

-- defining some Interference Regions -- Region 1 --> box IR_CreateBox(pnt0001P, pnt0002P, pnt0003P, pnt0004P, 1, 1) -- Region 5 --> boxIR_SET($FMO[1], 1, 5, IR_PRESENCE) --associating bit 1 of $FMO[1] to region 5 -- which then becomes a monitored region IR_CreateBox(pnt0013P, pnt0014P, pnt0015P, pnt0016P, 1, 5) -- Region 2 --> cylinder IR_CreateCylinder(pnt0005P, pnt0006P, 250, 1, 2) -- Region 3 --> sphere IR_SET($FMO[1], 2, 3, IR_PRESENCE)-- activating always present Interference Regions IR_SWITCH(ON, 1) -- activating region 1 IR_SWITCH(ON, 5) -- activating region 5 CYCLE MOVE TO pnt0001J IR_SWITCH(ON, 2) -- activating region 2 MOVEFLY TO pnt0002J ADVANCE MOVEFLY JOINT TO jnt0018J ADVANCE MOVE LINEAR TO jnt0019J IR_SWITCH(OFF, 2) -- deactivating region 2 MOVE LINEAR TO jnt0020J IR_SWITCH(ON, 3) -- activating region 3 MOVEFLY JOINT TO jnt0021J ADVANCE MOVE LINEAR TO jnt0022J IR_SWITCH(OFF, 3) -- deactivating region 3 MOVE LINEAR TO jnt0023J

END ir_cart

247pr-0-0-gpr_13.fm

04/0711


18.5.2 Sample program for a Joint Interference Region

Here follows a PDL2 program sample which defines and uses a Joint Interference Region within a Robot motion program.

PROGRAM ir_jnt PROG_ARM = 1VAR pnt0001J, pnt0002J, jnt0018J, jnt0019J , jnt0020J, jnt0021J, jnt0022J, jnt0023J : JOINTPOS FOR ARM[1] pnt0001P, pnt0002P, pnt0003P, pnt0004P, pnt0005P, pnt0006P, pnt0007P, pnt0013P, pnt0014P, pnt0015P, pnt0016P : POSITION

ROUTINE IR_CreateJoint(aj_neg_joint, aj_pos_joint : JOINTPOS; ai_num_arm, ai_mask, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL

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)

-- Activating Interference Region number 2 IR_SWITCH(ON, 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 jnt0023JEND ir_jnt

248pr-0-0-gpr_13.fm

04/0711

Axes Pursuit (optional feature)

19. AXES PURSUIT (OPTIONAL FEATURE)

19.1 IntroductionThe 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.

19.2 Axes PursuitThe Axes Pursuit optional functionality allows to define that one or more axes of a SLAVE Arm can pursue one or more axes of a MASTER Arm.

The pursuer axes (including the payload) must have the same dynamic features of the pursued axes, in order to assure a proper pursuit during the acceleration/deceleration phases and for the maximum speed of the pursuer axes. If not, it is not guaranteed a good pursuit of the MASTER Arm axis/axes by the SLAVE Arm axis/axes.

An example of axes pursuit application is the pursuit between two slides: one carrying a robot and the other one pursuing the translational motion of the robot, e.g. to carry the welding wire.

The system works both in automatic and in programming mode; in both cases, the functionality can be activated/deactivated at any time, to be able to guarantee the two (or more) axes independency.

In programming mode it is possible to select a modality, by means of $AX_PURSUIT_ENBL predefined variable, in which the ppursuit of all the SLAVE axes can be activated/deactivated on all the involved MASTER axes. In such a way, it is possible to move the involved axes both independently and with the axes pursuit functionality active.

In automatic mode it is possible to activate/deactivate the axes pursuit functionality during the work program execution, by means of $AX_PURSUIT_ENBL predefined variable.

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.

249pr-0-0-gpr_14.fm

03/0111


19.3 Error handling when Axes Pursuit functionality is active

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.

19.4 Configuring the software optionTo configure the Axes Pursuit software option, the involved variables are as follows:

– $AX_PURSUIT_ENBL - it can have TRUE/FALSE values, to enable/disable the axes pursuit option (both in programming and automatic mode). Example: $AX_PURSUIT_ENBL := TRUE enables the option.

– $AX_PURSUIT_ARM_MASTER - allows defining which Arm the pursued axis belongs to, i.e. which is the MASTER Arm. Example: $AX_PURSUIT_ARM_MASTER := 2 defines Arm 2 as the MASTER

– $AX_PURSUIT_LINKED - allows defining the pursuer axis which has to pursue the MASTER Arm axis. Example:$AX_PURSUIT_ARM_MASTER := 1 --indicates MASTER Arm is Arm 1$ARM_DATA[2].AX_PURSUIT_LINKED[3] := 7 --indicates axis 3 of --Arm 2 (SLAVE) --pursues axis 7 of --Arm 1 (MASTER)

19.4.1 Example of PDL2 statements for configuring the Axes Pursuit functionality

Some PDL2 statements follow which configure the Axes Pursuit functionality for a two

At the powerup of a System including the Axes Pursuit option, the functionality default is DISABLED. The Administrator profileis required to set to TRUE the $AX_PURSUIT_ENBL predefined variable, to enable it.

250pr-0-0-gpr_14.fm

03/0111


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

251pr-0-0-gpr_14.fm

03/0111

COMAU Robotics servicesRepair: [email protected]: [email protected] parts: [email protected] service: [email protected]

controller unit - fs.gongkong.comfs.gongkong.com/files/technicaldata/201207/... · comau robotics...

Documents