C5GPlus

Control Unit

MOTION PROGRAMMING
C5GPlus - R1C
Rel. 4.20.xxx

Robot movements in programming mode, eMotion

and standard motion control, optional features
(synchronous motion, cooperative motion, sensor
tracking, conveyor tracking, weaving, soft servo,
kinematic compensation, collision detection,
Interference Regions, axes pursuit), moving
through singularities, positioners and portals,
manual guidance, path learning, continuous
processes optimization

CR00758157_en-07/2021.03

Instruction Handbook
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 © 2008-2020 by COMAU - Date of publication 03/2021

 Comau Robotics Product Instruction

SUMMARY

SUMMARY

PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Symbols used in the manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Modification History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1. GENERAL SAFETY REQUIREMENTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...16

Intended use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Improper use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Essential safety requirements applied and fulfilled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Aspects of particular attention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2. SYSTEM OPERATING MODES AND STATES . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...25

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
System operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
System states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
HOLD status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
AUTO status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
PROGR status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
ALARM status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Stand-by function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

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

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Turn-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Turn-set on system calibration position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Turn-set on user calibration position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Turn-set for robot axes with multi-turn stroke. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
System calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
User calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4. ROBOT MOTION IN PROGRAMMING MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...36

1
Comau Robotics Product Instruction

SUMMARY

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Reference frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
System reference frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Manual motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Manual motion in WRIST_JNT mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Manual motion of a single arm system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Manual motion of auxiliary axes, slides and rotating columns . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Manual motion with Controller multi-arm configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Motion instruction in programming status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5. MOTION CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..43

eMotion general overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Frames of Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
System Frame of Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Base Reference System definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Flange Tooling definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
TCP Offset definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Calculating the Rotation Angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
FIRST METHOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
SECOND METHOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
User Reference System definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Trajectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Joint Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Cartesian Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Linear Interpolation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Circular Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Orientation Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Attitude Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Turn Flag and minimum path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
REPLAY (execution of a saved trajectory) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Moni of REPLAY type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Position Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
On Trajectory Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
On Position (ON POS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Example of On Pos and On Trajectory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Speed Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Cartesian Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Cartesian Speed Control Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Joint Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Manual Motion Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Acceleration and Deceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Acceleration/Deceleration Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Extra acceleration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Manual Motions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2
 Comau Robotics Product Instruction

SUMMARY

Motion termination (positioning accuracy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

COARSE and FINE Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
JNT_COARSE and JNT_FINE Termination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
NOSETTLE Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Trajectory Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Recovery Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Pending Motion Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Recovery Range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Recovery procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Process Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Automatic Process Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Continuous Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Trajectory Shape During Continuous Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Continuous Motion Modes (FLY) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Lookahead functionality (optional feature) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Available FLY types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Available FLY types summary table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Joint FLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Using $FLY_TYPE and $FLY_PER for the Joint FLY . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Cartesian FLY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Geometry and Speed Profile in the Cartesian FLY: FLY_NORM vs FLY_MULTI . . . . . .82
Events related to FLY movements with trajectory control (constant speed or specified
FLY_DIST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Setting the Cartesian FLY predefined variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Using $DFT_ADVANCE and $ADVANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Remote Tool System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Integrated Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Integrated Axis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Jogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Reference Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96

6. MOTION CONTROL WITHOUT EMOTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...99

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Frames of Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
System Frame of Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Base Reference System definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Flange Tooling definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
TCP Offset definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
Calculating the Rotation Angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
FIRST METHOD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
SECOND METHOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
User Reference System definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Trajectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Joint Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Cartesian Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Linear Interpolation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Circular Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107

3
Comau Robotics Product Instruction

SUMMARY

Orientation Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107

Attitude Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Turn Flag and minimum path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Position Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
On Trajectory Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
On Position (ON POS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Example of On Pos and On Trajectory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Speed Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Cartesian Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Cartesian Speed Control Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
Run-Time modifying the Linear Speed Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
Joint Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Manual Motion Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Acceleration and Deceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Acceleration/Deceleration Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Joint Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Cartesian Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Manual Motions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Motion termination (positioning accuracy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
COARSE and FINE Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
JNT_COARSE and JNT_FINE Termination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
NOSETTLE Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Trajectory Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Recovery Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Pending Motion Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Recovery Range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Recovery procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
Process Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Automatic Process Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Continuous Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Trajectory Shape During Continuous Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Continuous Motion Modes (FLY) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
FLY_NORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
FLY_CART (Controller Aided Resolved Trajectory) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Dynamic Machine Stress Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Keeping Constant Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Trajectory Control During FLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Debug of Fly Motions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
Variables used with FLY Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Remote Tool System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Integrated Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Integrated Axis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Jogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Reference Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137

7. SYNCHRONOUS MOTION (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . ..139

4
 Comau Robotics Product Instruction

SUMMARY

Synchronization with Auxiliary Axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Synchronized Arms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Motion limitations of the two Arms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Jogging Synchronized Arms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Teaching and Modifying Positions (REC/MOD) with Synchronized Arms . . . . . . . . . . . . . . 143
Loss of Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Run-time modifying the Linear Speed Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

8. COOPERATIVE MOTION (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . ...146

Cooperative Motion with Auxiliary Axes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Cooperative Arms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Multi-cooperative motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Jogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

9. SENSOR TRACKING (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . ...151

Principle of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Configuration on several arms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Sensor interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Integrated Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
External sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Sensor reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Sensor integral with the tool (TOOL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Sensor integral with the user reference system (USER) . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Sensor integral with the world reference system (WORLD). . . . . . . . . . . . . . . . . . . . . . . . . 156
Sensor integral with the weaving reference system (WEAVE) . . . . . . . . . . . . . . . . . . . . . . 156
Type of information acquired by the sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Correction actuation criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Relative and absolute deviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Actuation of deviation in time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Overall deviations control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Sensor tracking enable mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Sensor malfunctioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Robot stop in the case of sensor malfunctioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Redefinition of overall deviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Accumulative overall deviations management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Interrupted sensor tracking session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Suspended sensor tracking session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Resetting in spread condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Limitations in parameter changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Programming example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

5
Comau Robotics Product Instruction

SUMMARY

10. CONVEYOR TRACKING

(OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..170
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Working Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Process Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Tracking Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Motion Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Teaching Positions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Tracking Interruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Limitations during Conveyor Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Use of the Roto-translating Conveyor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Configuration parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

11. MOTION WITH WEAVING (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . ..182

Weaving Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Weaving Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Weaving Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Wave Shape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Weave Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Weave Amplification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Stopping Motions with Weaving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Programming Weaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Weaving without Arm motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Example - Using the weaving without Arm motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Weaving on multiarm systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

12. JOINT SOFT SERVO (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..200

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

13. FLOW MODULATE ALGORITHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..201

Basic concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Calculating the flow-speed function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Activating/deactivating the algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

14. PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING. . . . . . . . . . . . . . . . ..205

6
 Comau Robotics Product Instruction

SUMMARY

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Offset algorithm with Dynamic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Kinematic offset algorithm (optional feature) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Moving through axis 5 singularities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Using WRIST_JNT modality to go through singularities . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Using WRIST_JNT modality to go through singularities. . . . . . . . . . . . . . . . . . . . . . . . . . .209
Wrist Singularity Management (optional feature) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210
Manual motion (jog keys) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Robots without compensation (effect of the inverse kinematics) . . . . . . . . . . . . . . . . . . . . . . . 211
Inverse conversion of SMART NJ4 (non-spherical wrist) model . . . . . . . . . . . . . . . . . . . . . 211
Approximation in the orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
Move to a taught POSITION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212
Fly between MOVE LINEAR/CIRCULAR and MOVE JOINT . . . . . . . . . . . . . . . . . . . . . . .212
Axis 5 singularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212
Cartesian position out of range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214
TCP in the back of the robot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214
TCP behind axis 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
WCP close to axis 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217
Inverse conversion of SMART NJ models (spherical wrist only) . . . . . . . . . . . . . . . . . . . . . 218
Axis 5 singularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218
Programming rules for non-spherical wrist robots (SMART NJ4) . . . . . . . . . . . . . . . . . . . . . . 218
How to stay away from a singularity zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Changing the orientation of the points along the path . . . . . . . . . . . . . . . . . . . . . . . . . . . .219
Properly designing the work-cell layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
Modifying tool inserting a small angle between robot flange and tool flange . . . . . . . . . . .222
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

15. COLLISION DETECTION

(OPTIONAL FEATURE). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...226
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Basic concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Basic information about the algorithm working principles . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Preliminary operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Working modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Basic tools for the functionality usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
CD_SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
$COLL_ENBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
$A_ALONG_1D[12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
$COLL_EFFECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
$A_AREAL_1D[57] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Enabling/Disabling the Collision Detection functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Enabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Disabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Collision Detection working modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
COLLISION mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Modifying the sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232

7
Comau Robotics Product Instruction

SUMMARY

Severity of the collision error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232

SEARCH mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Modifying the sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
Severity of the collision error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
Changing the working mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
From COLLISION mode to SEARCH mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
From SEARCH mode to COLLISION mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
Operational tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Sample programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Enabling the Collision Detection functionality by means of a CONDITION . . . . . . . . . . . . . 236
Managing the ‘detected collision’ event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Workpiece searching and picking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

16. USE OF POSITIONERS MANAGED BY C5GPLUS . . . . . . . . . . . . . . . . . . . . . . . . ..239

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
General Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Axis rotation directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Convention for the mechanical positioning of points P1, P2 and P3 . . . . . . . . . . . . . . . . . . 240
Programming override value calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Positioners with 1 rotating axis type MP, PTDO, PTDV, TR3000/6000 . . . . . . . . . . . . . . . . . . 242
Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
PTORB - Positioner with 2 perpendicular axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Positioner with two tilting-rotating axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
Positioner with two axes in "L" arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Calibration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248
Positioners with 2 non perpendicular axes, type PTORB-alfa . . . . . . . . . . . . . . . . . . . . . . . . . 250
Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Integrated robot positioning axes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Integrated slide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253
Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254
Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254
Integrated rotating column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256
Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257
Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257
Three linear axes portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

8
 Comau Robotics Product Instruction

SUMMARY

Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259

Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259
Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259
Two linear axes Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261
Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262
Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262
Integrated trans-rotational Column. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Definition of the reference system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263
Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
Kinematic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264

17. INTERFERENCE REGIONS (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . ...266

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Regions types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Cartesian Forbidden and Allowed Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Cartesian Monitored Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Joint Forbidden Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Joint Monitored Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Cartesian Hybrid Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Regions Shape and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Cartesian Regions shape and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270
Cylinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270
Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270
Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271
Joint Regions shape and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
IR_LIB library to support Interference Regions creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Regions related to the WORLD reference frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Regions related to the currently active UFRAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Sample program for Cartesian Interference Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Sample program for a Joint Interference Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

18. AXES PURSUIT (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...278

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Axes Pursuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Error handling when Axes Pursuit functionality is active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Configuring the software option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Example of PDL2 statements for configuring the Axes Pursuit functionality . . . . . . . . . . . . 280

19. LOW RESOLUTION EULER ANGLES (OPTIONAL FEATURE) . . . . . . . . . . . . . . ...281

9
Comau Robotics Product Instruction

SUMMARY

20. PALLETIZING FUNCTIONALITY (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . ..282

Enabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Disabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Example of a Palletizing Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

21. ROBOT ABSOLUTE ACCURACY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..285

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Notes for a proper use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

22. MANUAL GUIDANCE (OPTIONAL FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..288

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Manual Guidance device (MG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Enabling Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Emergency stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292
User Buttons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292
no action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
custom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
path learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
translation/rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295
change sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295
Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Fieldbus devices configuration procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Force/Torque sensor setup procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Force/Torque sensor compensation procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Compensation status check procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Force/Torque sensor and corresponding NetBox installation procedure . . . . . . . . . . . . . . . 306
Use of the Manual Guidance system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
MG System Use procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Status of the MG functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Dedicated PDL2 routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
FC_SetComp routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
FC_SetGain routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
FC_SetCFPos routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
FC_SetComplianceLevel routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

23. PATH LEARNING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..317

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
PDL2 routines to handle MONI REPLAY type files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
mrri_start_moni_replay routine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
mrri_stop_moni_replay routine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

10
 Comau Robotics Product Instruction

SUMMARY

mrri_moni_replay_init routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

mrri_moni_replay_cnfg_io routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
mrru_moni_replay_dump_io routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

24. IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL

FEATURE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...323
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Installing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Creating the moni.log input file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Using IMPR optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Basic menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332
Advanced users menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333
Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Standard diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Trajectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335
Velocity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335
Velocity details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336
Auxiliary axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336
Auxiliary axes velocity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336
Advanced users diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337
Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337
Input Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337
Moni Input Velocity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337
Quaternion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .338
Quaternion Derivatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .338
Actions Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Comparing velocities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

25. END USER LICENSE AGREEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...341

11
Comau Robotics Product Instruction

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.

12
 Comau Robotics Product Instruction

PREFACE

Reference documents
This document refers to the C5GPlus Control Unit.
The complete set of manuals for the C5GPlus consists of:

Comau C5GPlus Control – Technical Specifications, Transport and

Unit Installation
– C5GPlus Control Unit Use.

These manuals are to be integrated with the following documents:

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.

13
Comau Robotics Product Instruction

PREFACE

Modification History
– In 01/2018.10 manual version, a new Chap.20. - Palletizing functionality (optional
feature) on page 282 has been created.
Such a topic was part of Chap.5. - Motion Control on page 43 and Chap.6. - Motion
control without eMotion on page 99 in the previous versions of the manual.
– In 02/2019.01 manual version, the following changings have been made:
• modified information related to Chap.17. - Interference Regions (optional
feature) on page 266, to align the chapter descriptions to the corresponding
software.
– In 03/2019.05 manual version, the following changings have been made:
• added description of the TIME and DISTANCE BEFORE HALFFLY new
motion conditions (par. 5.10.2.4.2 Events related to FLY movements with
trajectory control (constant speed or specified FLY_DIST) on page 85)
• added description for the REPLAY (execution of a saved trajectory)
functionality and the corresponding Moni of REPLAY type files handling
• created the new Chap.22. - Manual Guidance (optional feature) on page 288
• created the new Chap.23. - Path Learning on page 317.
– In 04/2019.07 manual version, Chap.14. - Presuppositions for SMART Robot
programming on page 205 has been updated to adjust the descriptions to match
the new kinematics conversion strategy.
– In 05/2019.10 manual version, par. 5.6 Acceleration and Deceleration on page 64
has been updated to provide details about $EMT_STRESS predefined variable.
– In 06/2020.09 manual version, the following changings have been made:
• Chap.7. - Synchronous Motion (optional feature) on page 139 - modified
• Chap.17. - Interference Regions (optional feature) on page 266 - modified
about Cartesian Hybrid Regions
– In 07/2021.03 manual version, the following changings have been made:
• added description about the optional Lookahead functionality. More in detail,
the following sections have been created and/or modified:
• Lookahead functionality (optional feature),
• Available FLY types
• Joint FLY
• Cartesian FLY
• Available FLY types summary table
• Using $FLY_TYPE and $FLY_PER for the Joint FLY,
• Geometry and Speed Profile in the Cartesian FLY: FLY_NORM vs
FLY_MULTI,
• Using $DFT_ADVANCE and $ADVANCE.
• Chap.24. - IMPR - Application for Continuous Processes optimization
(optional feature) on page 323.
• updated the software license agreement information, to the 2021 version.

14
Comau Robotics Product Instruction

15
Comau Robotics Product Instruction

GENERAL SAFETY REQUIREMENTS

1. GENERAL SAFETY REQUIREMENTS

This chapter deals with general specifications that apply to the whole Robot System.
Considering its importance, this chapter is referred to unconditionally in every instruction
handbook of the system.

This chapter contains the following topics:

– Intended use
– Improper use
– Essential safety requirements applied and fulfilled
– Operating modes
– Aspects of particular attention
– Responsibilities

1.1 Intended use

The Robot and the Control Unit (when present) represent a robotic system made in
compliance with EN ISO 10218-1. Its performance must be exploited in industrial or
comparable areas, subject to current regulations, also complementary to the
aforementioned standard.
Installation, use, maintenance and disposal of the robotic system must be carried out by
authorized and trained personnel.

1.2 Improper use

The robotic system or its parts must not be used in environments that do not comply with
the technical specifications indicated in the relative handbooks. The use in
non-compliant environments, different from those required, uses beyond the expected
performances can create risks both for people and for the Robot system or its parts.
A non-careful integration according to the laws and regulations in force can also incur
the integrator to legal and criminal complications.

1.3 Essential safety requirements applied and fulfilled

The robotic system composed of Control Unit and SMART5 Robot series considers as
applied and fulfilled the following Safety Fundamental Requirements, Annex I of
Machinery Directive 2006/42/EC: 1.1.3 – 1.1.5 – 1.2.1 – 1.2.2 – 1.2.3 – 1.2.4.3 – 1.2.5
– 1.2.6 – 1.3.2 – 1.3.4 – 1.3.8.1 – 1.5.1 – 1.5.2 – 1.5.4 – 1.5.6 – 1.5.8 – 1.5.9 – 1.5.10 –
1.5.11 – 1.5.13 – 1.6.3 – 1.6.4 – 1.6.5 – 1.7.1 – 1.7.1.1 – 1.7.2 – 1.7.4.

16
 Comau Robotics Product Instruction

GENERAL SAFETY REQUIREMENTS

1.4 Operating modes

Installation and Start-up

– The startup is only possible when the Robot and Control System has been correctly
and completely installed.
– The system installation and startup is exclusively the task of the authorised
personnel.
– For Robots with no collaborative functionality:
• the system installation and startup is only allowed exclusively inside a
Protected Zone of an adequate size to house the Robot and the equipment it
is outfitted with, without passing beyond the protection barriers. It is also
necessary to check that in normal Robot movement conditions there is no
collision with parts inside the Protected Zone ( e.g structural columns, power
supply lines, etc.) or with the barriers. If necessary, limit the Robot workspace
by means of mechanical stop buffers (see optional units);
• any fixed Robot control protections are to be located outside the Protected
Zone and in a point where there is a full view of the Robot movements;
• install the Control Unit outside the Protected Zone: the Control Unit should not
be used as part of the fence.
– 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 must be handled as described
in the relative Instruction Handbooks; if lifting is necessary, check that the eyebolts
are fixed correctly and use only adequate slings and equipment.
– Fix the Robot to mount holder, with all the provided bolts and pins, tightened to the
tightening torques given in the related Instruction Handbooks.
– 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.
– Check that the voltage value of the power mains is consistent with that indicated
on the nameplate of the Control Unit.
– Before electrically connect the Control Unit, check that the circuit breaker on the
power mains is locked in open position.
– The connection between the Control Unit and the power supply mains of the plant,
must be made through a cable of dimensions suitable for the power installed on the
Control Unit (for details refer to chapter “Power supply from the electric network:
features and connection” in the Control Unit Instruction Handbooks).
– Connect the ground cable (PE) then connect the power conductors to the main
switch.
– Connect the power supply cable, first connecting the ground cable to the circuit
breaker on the power mains line, after checking with a tester that the circuit breaker
terminals are not powered. It is recommended to connect the cable armor to the
ground.
– Connect the signals and power cables between the Control Unit and the Robot.

17
Comau Robotics Product Instruction

GENERAL SAFETY REQUIREMENTS

– Connect the Robot to the ground through the Control Unit or specific terminals,
according to the prearrangements present on Robot and/or Control Unit.
– Where provided, check that the Control Unit door/s is/are closed with the
appropriate key.
– A wrong connection of the connectors may cause permanent damage to the
Control Unit components.
– The Control Unit manages internally the main safety interlocks (gates, enabling
push-buttons, etc.). Connect the 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 (emergency stop, safety
fences etc.), i.e. the making of correct and safe circuits, is the responsibility of the
Robot and Control System integrator.

In the cell/line emergency stop circuit it is necessary to include the contacts of the
emergency stop push-buttons of the Control Unit available on the appropriate connector
(for details, refer to the electrical circuit diagrams and the specific Instruction Handbooks
according to the Unit Control model). The push-buttons are not interlocked inside the
emergency stop circuit of the Control Unit.

– The safety of the system cannot be guaranteed in case of interlocks erroneous,

incomplete or missing execution.
– The Robot emergency stop in AUTO/REMOTE mode is set in a controlled way
(IEC 60204-1, stop of category 1 or category 2*); it is also possible to set the stop
in category 0 by changing the related setting within the control logic of the Control
Unit safety aspects.
* the stop in category 2 is only possible for Robots with collaborative functionality

Setting the emergency stop in category 0 can result in mechanical damages to the tools
and loss of load if they are not properly designed.

– When preparing protection barriers (when required), especially for light curtains
and access doors, take into consideration the Robot stopping times and distances
according to the stop category (according to IEC 60204-1) and the weight of the
Robot.

The stop circuit timer is normally set to 1.5 seconds. This parameter can be changed if
heavy-duty implements (e.g. rotary tables, positioners, etc.) are matched with the Robot.
The stop circuit timer can be modified by changing its setting within the control logic of
the Control Unit safety aspects. For further details, refer to the paragraph “Safety stop
circuit timer” in the Control Unit Instruction Handbooks.

– Check that the environmental and operating conditions do not exceed the limits
specified in the specific Instruction Handbooks.
– The calibration operations must be carried out with utmost attention, as indicated
in the Instruction Handbooks of the specific product, and must be concluded by
checking the correct position of the machine.
– To load or update the system software (for example after boards replacing), use
only the original software handed over by COMAU. Scrupulously follow the system
software loading procedure described in the Instruction Handbooks supplied with

18
 Comau Robotics Product Instruction

GENERAL SAFETY REQUIREMENTS

the specific product. After loading, always make some Robot motion tests at low
speed remaining outside the Robot action radius.
– Check that the barriers of the Protected Zone (when present) are correctly
positioned.

Functioning in Programming mode

– The Robot is only to be programmed by the authorised personnel.
– Before proceeding with programming, the operator, remaining at the end of the
Protected Zone / Collaborative Zone, must:
• make sure that all the necessary protective guards and safety devices are
present and in working conditions;
• make sure that the Teach Pendant is functioning correctly (reduced speed,
enabling device, emergency stop device, etc.);
• check the Robotic system (Robot and Control Unit) to make sure that there
are no potentially dangerous anomalous conditions and that no person is
present in the Protected Zone / Collaborative Zone.
– As far as possible, the programming should be controlled from outside the
Protected Zone / Collaborative Zone.
– During the programming phases, only the operator with the Teach Pendant is
allowed inside the Protected Zone / Collaborative Zone.
– For Robots without collaborative functionality, if the presence of a second operator
is required in the workspace when checking the program, these people must have
their enabling device interlocked with the safety devices.
– Activation of the motors (DRIVE ON) must always be controlled from a position
outside the Robot area of action, after having verified that there is nobody in the
area concerned. The Drive On operation is considered complete when the relevant
machine status indication is shown.
– During programming the operator must remain at a distance from the Robot such
as to allow him to avoid any anomalous movements of the machine, and in any
case in a position to avoid possible risks of restraint between the Robot and parts
of the structure (columns, barrier, etc.), or between moving parts of the Robot itself,
including parts which, due to gravity, could perform movements downwards,
upwards or laterally (in the case of mounting on an inclined plane).
– The test of a programmed cycle at working speed with the operator inside the
Protected Zone / Collaborative Zone, in some situations where a close visual check
is necessary, must be activated after a complete test cycle at low speed has been
carried out. The test must be controlled from a safe distance.
– Special attention is to be paid when programming using the Teach Pendant: in this
situation, although all the hardware and software safety devices are active, the
Robot movement depends on the operator.
– During the execution of a new program or a varied sequence of instructions, make
sure that the movement of the Robot takes place along the intended path.
– Check while remaining out of the Robot action area and test the cycle at low speed.

Functioning in Auto / Remote Mode

– The activation of the automatic operation (AUTO and REMOTE statuses) is only
allowed with the Robotic system (Robot and Control Unit) integrated in a special
area with sufficient features to meet the needs of Protected Zone / Collaborative

19
Comau Robotics Product Instruction

GENERAL SAFETY REQUIREMENTS

Zone (depending on the Robot type) as prescribed by the Safety Regulations in

force in the country where the installation is carried out.
– Before activating the automatic operation, the operator must check:
• the Protected Zone / Collaborative Zone to ensure that there are no potentially
dangerous anomalous conditions;
• that the Robot and Control System is not in a state of maintenance or repair
and that there are no potentially dangerous abnormal conditions;
• that the protection barriers (when present) are correctly positioned;
• that there is nobody inside the Protected Zone / Collaborative Zone;
• that the Control Unit doors are closed and locked with the appropriate key;
• that the safety devices are in working conditions;
– Special attention is to be paid when selecting the remote mode, in which the line
PLC can perform automatic operations of motors power up and program starting.

Functioning in Collaborative Mode

– The Comau collaborative Robots require an appropriate assessment of the risk of
the area in which they are integrated, combining the performances already
available in the collaborative solutions with additional safety devices.

The integrator is responsible for the correct integration of the collaborative Robot in the
complete cell/machine.

– The integrator shall consider at least the following aspects:

• the tool connected to the Robot, must be equipped with a solution compatible
with the collaborative mode of the Robot;
• the impact force of the Robot against the person, proportional to the
movement speed of the Robot itself;
• the Collaborative Zone, which must be sufficiently large, without edges or
structural parts that can block the operator without an escape route, possibly
trapped between the skin and a static structural element of the cell / machine;
• the stopping distance and time of the Robot, which must include a reasonable
distance to avoid crushing (see details in “Robot Technical Specifications”
handbook, paragraph “Robot stop modes and space” and “Sensorized skin
on AURA Collaborative Robot”* handbook, “paragraph Technical features”);
* only available in case of AURA Collaborative Robot

Robot axes brake release (where required)

– The movement of the Robot axes is possible by means of suitable control devices
(integrated, where provided, on Robot base, or available as optional devices
-brake releasing module-) and adequate lifting means. Such devices only enable
the brake deactivation of each axis. In this case, all the system safety devices
(including the emergency stop and the enabling push-button) are disabled; also the
Robot axes can move upwards or downwards because of the forces generated by
the balancing system or by gravity.

Before using manual brake releasing devices, it is recommended to sling the Robot, or
hook it to an overhead traveling crane.

– The brake releasing operation can generate crash risks caused by:

20
 Comau Robotics Product Instruction

GENERAL SAFETY REQUIREMENTS

• an incorrect reset after the brake release

• resumption of movement after an interruption of an incomplete MOVE (whose
typical function of trajectory recovery can generate unpredictable paths);
• subsequent resumption of the automatic cycle (similarly to what has been
described above, relating to the resumption of a not completed MOVE).
– Avoid moving the Robot in positions that are distant from the ones required for the
motion restarting; alternatively disable the outstanding MOVE programmes and/or
instructions.
– The procedure for the correct use of the brake releasing devices (integrated on
Robot base and/or optional brake releasing module) is shown in the “Maintenance”
section of the Instruction Handbooks of the specific Robot.

Maintenance and Repair

– The Robot (where required) is supplied with lubricants that do not contain any
harmful to health substances; however, in some cases, repeated and prolonged
exposure to the product may cause skin irritation, or if swallowed, sickness.
First Aid Measures. In case of contact with the eyes or skin: rinse the affected
areas with plenty of water; in case irritation persists, seek medical advice.
If swallowed, do not induce vomiting or administer anything by mouth; consult a
doctor as soon as possible.
– Maintenance, troubleshooting and repair operations are only to be carried out by
authorised personnel.
– When carrying out maintenance and repair operations, the specific warning sign
stating the maintenance status must be placed on the control panel of the Control
Unit, until the end of the operation, even if it should be temporarily suspended.
– Maintenance and replacement operations of the components or Control Unit must
be carried out (where provided and necessary) with the main switch in open
position and locked with a safety padlock.
– Even if the Control Unit is not powered (main switch open), there may be
interconnected voltages deriving from connection to peripheral units or external
power sources (e.g. 24 Vdc input/output). Power off the external sources when
operating on involved system parts.
– Removal of panels, protection shields, grids, etc. is only allowed with the main
switch open and padlocked (where provided and necessary).
– Faulty components are to be replaced with others having the same Part No., or
equivalent components defined by COMAU.

Where required, the replaced safety components must be configured with the same
parameters as those removed.

– Troubleshooting and maintenance activities:

• must be performed, as far as possible, outside the Protected Zone /
Collaborative Zone;
• on Control Units they must as far as possible be performed in the absence of
power;
• on the Robot must be performed with power supply deactivated (DRIVE
OFF).

21
Comau Robotics Product Instruction

GENERAL SAFETY REQUIREMENTS

– If necessary, during troubleshooting, intervene with the Control Unit powered; all
the precautions specified by Safety Standards must be observed when operating
in presence of dangerous voltages.
– At the end of the maintenance and troubleshooting operations, all the deactivated
safety devices must be reset (panels, protection shields, interlocks, etc.).
– The maintenance, repair and troubleshooting intervention must be completed by
verifying the correct operation of the Robotic system (Robot and Control Unit) and
all safety devices performed outside the Protected Zone / Collaborative Zone.
– During the software loading phases (for example after replacement of electronic
boards) use only the original software handed over by COMAU. Scrupulously
follow the system software loading procedure described in the specific Instruction
Handbooks; after loading, always run a test cycle, remaining outside the Protected
Zone.
– The disassembly of Robot components (e.g. motors, balancing cylinders, etc.) may
cause uncontrolled movements of the axes in different directions: before starting a
disassembly procedure, refer to the warning plates affixed on the Robot and to the
supplied Instruction Handbooks.
– On Robots equipped with balancing springs, it is forbidden to remove the protection
cover of the springs.
– Where fitted, always restore the protective casing if previously installed.

Decommissioning and Dismantling

– The decommissioning and removal of the Robot and Control System is allowed
only to Authorized Personnel.
– Move the Robot in transport position and mount the axes blocking brackets (when
required) referring to the plate affixed to the Robot and to the Instruction
Handbooks of the Robot itself.
– Before proceeding with decommissioning it is mandatory, depending on the type of
Control Unit:
• on the Control Unit with power cable wired directly to the terminals of the main
switch:
• turn off the mains voltage at the Control Unit input, by disconnecting the
circuit breaker on the power mains and locking it in open position;
• check with a suitable instrument that the terminals are disconnected;
• disconnect the power supply cable from the circuit breaker on the power
mains, first disconnecting the power conductors and then the ground
conductor;
• Disconnect the power supply cable from the Control Unit and remove it.
• on Control Units equipped with a pre-assembled power cable, with a
“socket-plug” system:
• disconnect the power supply cable.
– First disconnect the connection cables between the Robot and the Control Unit,
then the earth cable.
– If installed, disconnect the pneumatic system from the air supply and blow off the
residual air.
– Check that the Robot is properly balanced and if necessary sling it correctly, then
remove the screws that fix the Robot to the supporting surface.

22
 Comau Robotics Product Instruction

GENERAL SAFETY REQUIREMENTS

– Remove the Robot and the Control Unit from the workspace, taking all the
requirements indicated in the products Instruction Handbooks; if lifting is
necessary, check the eyebolts proper fixing and use only suitable slings and
equipment.

The disposal operations must be carried out in compliance with the legislation in force
in the country where the Robotic system is installed; dispose of the batteries, oils and
other chemical liquids in an environmentally correct way and in accordance with the
regulations in force transferring them to specific waste collection centres.

– Consign the Robot and the Control Unit to a centre responsible for the dismantling
and disposal.

23
Comau Robotics Product Instruction

GENERAL SAFETY REQUIREMENTS

1.5 Aspects of particular attention

The documentation of the robotic system required a subdivision of the contents into one
or more Instruction Handbooks. For this reason, the understanding of the functionalities
and the necessary attention to the requirements may require consultation of the entire
applicable documentation, always listed in the first pages of each handbook.

1.6 Responsibilities
The integrator is responsible for the correct integration of the robotic system or its parts
in accordance with the applicable legislation.
Comau is not responsible for any improper use of the robotic system or its parts.

24
 Comau Robotics Product Instruction

SYSTEM OPERATING MODES AND STATES

2. SYSTEM OPERATING MODES AND STATES

2.1 Foreword
This chapter describes the following:
– System operating modes
– System states
– Stand-by function

2.2 System operating modes

The C5GPlus Control Unit can operate in three different modes that can be selected
through the modal selector switch on the Teach Pendant:
– programming (modal selector switch in T1 position),

– local automatic (modal selector switch in LOCAL position) and

– remote automatic (modal selector switch in REMOTE position).

Local automatic mode 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 modal selector switch must be set to LOCAL.
Active TOOL, BASE and FRAME cannot be changed when working in LOCAL.
The Remote automatic mode (REMOTE) is the same as Automatic local mode
(LOCAL), but the commands (for example START) are sent from a remote device (e.g.
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
movements, 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).

25
Comau Robotics Product Instruction

SYSTEM OPERATING MODES AND STATES

When the status selector switch is set on position T1, the programs can be developed
using editor environment and the spots can be taken from the Teach Pendant moving
the robot manually with the motion keys; the programs can be set up using the debug
tools of the system. In programming mode, the execution of a move instruction requires
that the operator presses the START key and the enable device on the Teach Pendant.
When the status selector switch has been set to 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 LOCAL position, touch R5 key (Teach Pendant right
menu - it means DRIVE ON when in LOCAL state), to power ON the drives; to
switch them OFF and activate brakes on all axes controlled by the Control Unit,
touch R5 key 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 states

Mainly, 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 HOLD
status, 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 (modal selector switch positioned on LOCAL or REMOTE).
Active TOOL, BASE and FRAME cannot be changed when working in LOCAL 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.

26
 Comau Robotics Product Instruction

SYSTEM OPERATING MODES AND STATES

If the controlled stop function class 1 (EN 60204-1) is active, the power cut-out (opening
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 WinCRC 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 change
3. HOLD or DRIVES OFF or selector switch change
4. 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

27
Comau Robotics Product Instruction

SYSTEM OPERATING MODES AND STATES

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
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 modal selector switch must be set to LOCAL
or REMOTE. Active TOOL, BASE and FRAME cannot be changed when working in
LOCAL 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, switch on the
drives and press HOLD button again. To continue the mootion programs execution,
press START button (or send START signal from remote), making sure that the drives
are powered (DRIVE ON).

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

28
 Comau Robotics Product Instruction

SYSTEM OPERATING MODES AND STATES

2.4 Stand-by function

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

Deactivating the funciton, by setting $TUNE[27] to 0, must be performed in DRIVE OFF

state, or after a transition DRIVE ON --> OFF.
To make it permanent, save the system configuration by issuing Setup page - System -
Configure - Save command.

The Stand-by function is automatically deactivated at the first request to start movement
again (START, RESUME) from the system.
The system Stand-by status is displayed in the status bar of the Teach Pendant. To
display the state of a single arm, read this status on the Status sub-page, the Motion
Page on the Teach Pendant.

The safety precautions are to be scrupulously observed regarding this operating

condition of the Control Unit.

29
Comau Robotics Product Instruction

SYSTEM OPERATING MODES AND STATES

30
 Comau Robotics Product Instruction

TURN-SET AND CALIBRATION - BASIC CONCEPTS

3. TURN-SET AND CALIBRATION - BASIC

CONCEPTS

3.1 Foreword
The purpose of this chapter is to describe the basic concepts and the terminology for the
management of robot axes position information. The description of the operating
procedures is contained in the chapter TURN-SET AND CALIBRATION
- OPERATING PROCEDURES, that specifically regards the robot used.
This chapter contains the basic information on the following topics:
– used Terminology
– 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.

31
Comau Robotics Product Instruction

TURN-SET AND CALIBRATION - BASIC CONCEPTS

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
(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-set
The purpose of the turn-set is to update the number of transducer turns only,
should it occur that the when switched on again, the Control Unit has lost this
value.
The operation consists in bringing the axis involved to the calibration position, using the
locating notches, and giving the required command. No special equipment is needed,
because the only value initialised is the number of turns of the transducer.
The turn-set operation is required when
– there has been axis movement with the control off (for example when the error
59411 - 08 Ax <num_ax> Arm <num_arm> movement after shut-down) is
displayed.
– events take place that cause the loss of the number of turns only, and therefore do
not require the execution of the calibration procedure. On the Teach Pendant
status window or on the PV video the text Ar:TURN is displayed.
According to whether the turn-set is executed with the robot in system calibration
position or in user calibration position, we shall have:
– Turn-set on system calibration position
– Turn-set on user calibration position
– Turn-set for robot axes with multi-turn stroke

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

32
 Comau Robotics Product Instruction

TURN-SET AND CALIBRATION - BASIC CONCEPTS

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

33
Comau Robotics Product Instruction

TURN-SET AND CALIBRATION - BASIC CONCEPTS

3.4 Calibration
The purpose of the calibration procedure is to establish the position of a robot axis
referring it to an ideal robot. This makes it possible to initialise the values of the robot
axes and to make the position variables used in the robot programs universal.
During the calibration procedure, when the desired axis is in the calibration position, two
values are stored:
– the deviation, inside a transducer turn, between the value of the actual position and
that of the axis nominal position,
– the number of transducer turns.
The notches on the individual axes make it possible to execute future turn-set operations
on a robot that has already been installed.

Remember that executing the calibration operation (on the Teach Pendant, Setup page,
Calib subpage, Calib 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.

The recovery of the calibration (executed by COMAU), if necessary, is to be executed

when first putting the robot into operation.

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.

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

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.

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

34
 Comau Robotics Product Instruction

TURN-SET AND CALIBRATION - BASIC CONCEPTS

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.

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

SAVING CALIBRATION CONSTANTS

1. NVRAM - retentive memory
2. UD:\SYS in .C5G file
3. UD:\SYS in the calibration ASCII file ($<SYS_ID>_CAL<num_arm>.PDL

35
Comau Robotics Product Instruction

ROBOT MOTION IN PROGRAMMING MODE

4. ROBOT MOTION IN PROGRAMMING MODE

4.1 Introduction
In this chapter, reference will be made to the Teach Pendant as the device to control the
robot motion in programming status (status selector switch in position T1).

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

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 frames

A 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 frames

The Controller has three system variables ($BASE, $TOOL and $UFRAME) that permit

36
 Comau Robotics Product Instruction

ROBOT MOTION IN PROGRAMMING MODE

the description of the main co-ordinate conversions. Before starting to explain these
conversions, it is necessary to define some reference frames.

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

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

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

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

1. Flange frame
2. Tool frame
3. Recorded position
4. User frame
5. Base frame
6. World frame

Let’s now imagine a pen fitted on the flange of the robot that has to write the word
COMAU on the table. The $BASE conversion defines the point where the robot base is

37
Comau Robotics Product Instruction

ROBOT MOTION IN PROGRAMMING MODE

located, the $TOOL movement indicates the pen and the $UFRAME movement
indicates the position of the table.

4.4 Manual motion

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

38
 Comau Robotics Product Instruction

ROBOT MOTION IN PROGRAMMING MODE

Before moving in Cartesian mode (Tool, Uframe, Base) the correct definition should be
checked of the reference systems, especially the declaration of the tool frame through
the $TOOL variable. A wrong description of the tool causes errors in learning the points
and does not keep the TCP position unchanged during orientation movements. A good
method to check the correctness of $TOOL is to check that the TCP remains fixed while
changing the orientation of the tool.

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 mode

In 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, Basic
sub-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 system

To 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 columns
The auxiliary axes can be added to an Arm in order to move different types of

39
Comau Robotics Product Instruction

ROBOT MOTION IN PROGRAMMING MODE

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 key associated to the axis.
However, if the auxiliary axis moves a slide, a column or a built-in gripper, it can be
moved also in Cartesian modes (BASE, TOOL and UFRAME) using the same keys as
for JOINT mode.
Jogging in cartesian mode, allows to move the integrated axis without moving the TCP
(thus, the robot joints can move and follow the auxiliary axis/axes motion, in order not to
move the TCP from its initial position).

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

4.8 Manual motion with Controller multi-arm

configuration
In 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.6. - Motion control without eMotion on page 99.

4.9 Motion instruction in programming status

To program robot movements requires a certain knowledge of the C5GPlus 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.

40
 Comau Robotics Product Instruction

ROBOT MOTION IN PROGRAMMING MODE

The type of path may be joints, linear or circular and is described by the predefined
constants JOINT, LINEAR and CIRCULAR respectively (see the Chap.6. - Motion
control without eMotion on page 99 for further details). If the type of trajectory is not
indicated, the value defined in the $MOVE_TYPE system variable is valid, that is usually
set at JOINT by the system.
The destination points are typically learnt inside a program, but they can also be
assigned directly in the instruction line of EXECUTE. Two ways to assign the destination
point that are most useful for installation and maintenance are given below. A Cartesian
point can be assigned by the built-in POS that allows, as parameters, the three
co-ordinates x, y and z where the TCP is to be taken, three angles for tool orientation
and a configuration string. All the positions of this type are called POSITION and are
always referred to the reference systems; the configuration string can usually be left
empty. The following is a valid position that defines a point at 100 mm from the user
reference in direction z: POS (0,0,100,0,0,0,’’). For further information see the Chap.6.
- Motion control without eMotion on page 99 and the PDL2 Programming Language
manual. A destination point can also define the position to be reached by each arm axis
(including auxiliary axes). To do so, write the values separated by a comma (in the
correct order) and enclose the complete declaration in a brace. A missing value leaves
the position of the corresponding axis unchanged. The following is a joint type position,
that requires axis 1 to move 10 degrees from the zero position, leaves axis 2 stationary,
takes axis 3 to -30 degrees and leaves the wrist unchanged: {10, ,-30}.
Some examples follow for valid movement instructions (for further information see the
PDL2 Programming Language Manual).

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

41
Comau Robotics Product Instruction

ROBOT MOTION IN PROGRAMMING MODE

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

Before executing a movement, check the correct definition of the reference

systems, especially the declarations of the tool reference and the user reference
($TOOL, $BASE and $UFRAME). These declarations can only be ignored in the case
of joint movements on joint positions, such as
MOVE JOINT TO $CAL_SYS or
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 position, nor will it execute a correct linear or circular
path. As far as the description of the user frame ($UFRAME) it is important to check that,
at the the motion execution moment, this is identical to that which was active when the
position was taught. Otherwise the positioning will be different than the tought one.
It is anyway allowed to move through the same trajectories with different $UFRAME
values, because this functionality is essential for some applications that specifically
require shifting the whole program inside the work space (e.g. palletizing applications).
It is also needed to always check the proper definition of the used payload as far as
mass, centre of gravity and inertia. Such data can be automatically calculated by the
Controller, given a Tool (also a Tool plus a part), by means of the Automatic Payload
identification (optional feature) program, available in Setup page, Motion - Payload.
Such a verification checks that the recorded load data correspond to the currently in use
$TOOL_MASS, $TOOL_CNTR and $TOOL_INERTIA[1..6] variables.

42
 Comau Robotics Product Instruction

MOTION CONTROL

5. MOTION CONTROL

5.1 eMotion general overview

This chapter contains the description of the C5GPlus Control Unit and R1C Control Unit
motion environment with eMotion Trajectory Control.
Neither the manual motion (Teach Pendant jog keys) which is described in Chap.4. -
Robot motion in Programming mode on page 36, nor the options that are dealt with
further on in other chapters of this manual, are included in the current chapter.
Information is supplied about the following topics:
– Frames of Reference and coordinates transformation
– Trajectory
– Position Checking
– Speed Control
– Acceleration and Deceleration
– Motion termination (positioning accuracy)
– Trajectory Recovery
– Process Resume
– Continuous Motion
– Remote Tool System;
– Integrated Movement.
Current chapter contains many references to predefined variables and instructions of
PDL2 language. For further information, refer to PDL2 Programming Language
Manual.

43
Comau Robotics Product Instruction

MOTION CONTROL

5.2 Frames of Reference

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

5.2.1 System Frame of Reference

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

World Frame The factory plant frame of reference with respect to which all
machines are positioned
Base Frame The frame located on the robot base
User Frame The frame located on the workpiece
Flange Frame The frame located on the robot flange
TCP Frame The frame located on the tool top

The $TOOL variable describes the position of the TCP frame with respect to the flange
frame; the $BASE coordinate transformation describes the position of the base frame
with respect to the world frame; the $UFRAME transformation describes the position of
the workpiece with respect to the world. The POS transformation represents the taught
point P that will be reached by the TCP during the execution of the program. Note that
all the taught POSITIONs are defined with respect to the user frame of reference
(defined by $UFRAME).
To better understand, suppose that the corner of the room is the world frame, and a
robot is located beside a table as shown in the following picture Fig. 5.1 - System
Frames of Reference and Coordinates Transformation on page 45.

44
 Comau Robotics Product Instruction

MOTION CONTROL

Fig. 5.1 - System Frames of Reference and Coordinates Transformation

1 - Flange frame 2 - Tool frame 3 - Recorded position

4 - 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:
– 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 Reference System definition

$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.
$BASE value can be left to zero, anyway it is needed to properly set it up in case of
Cooperative Motion (optional feature).
In case of any axes group configured as a positioner, both if they are auxiliary axes and
axes being part of an individual ARM, a tool is available on the Teach Pendant, Setup
page, Motion - Frames environment, allowing the positioner BASE guided calculation;

45
Comau Robotics Product Instruction

MOTION CONTROL

please refer to par. 12.5 BASE automatic calculation for positioners on page 618 in
C5GPlus Control Unit Use manual for detailed information.

5.2.3 Flange Tooling definition

Cartesian motions (straight lines for example) are defined for the TCP (tool center 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:
– 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.

WARNING
It is very important to specify the payload related to the tool mounted onto the flange, in
order to allow the eMotion algorithm to properly work.
The predefined variables which define the tool payload are as follows:
– $TOOL_MASS
– $TOOL_CNTR
– $TOOL_INERTIA
and must be properly configured.
For any information about them, refer to Predefined Variables List chapter in PDL2
Programming Language manual.

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, ‘ ‘)

46
 Comau Robotics Product Instruction

MOTION CONTROL

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

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;

47
Comau Robotics Product Instruction

MOTION CONTROL

– 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

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

48
 Comau Robotics Product Instruction

MOTION CONTROL

Example C
Tool z axis (u) is at 90 degrees with respect to the flange z
axis in the direction -y.
Rotation angles are (-90, 90, 180).

Example D
Tool z axis (u) is at 90 degrees with respect to the flange z
axis in the direction x.
Rotation angles are (0,90,180).

Example E
Tool z axis (u) is at 90 degrees with respect to the flange
z axis in the direction -x.
Rotation angles are (180, 90, 180).

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

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

49
Comau Robotics Product Instruction

MOTION CONTROL

5.2.3.3 User Reference System 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 off-line
programming.
To properly compute $UFRAME value, POS_FRAME built-in can be used as follows
(the program should be executed within a programming environment):

PROGRAM setframe
VAR corner, x, xy : POSITION
BEGIN
$UFRAME := POS(0,0,0,0,0,0,’’)
$TOOL := ... -- properly defined
-- Jog the TCP onto 3 points on the workpiece and teach
-- corner POSITION, x and xy POSITIONs pressing the MOD key
-- on the TP.
-- Then execute the following statement.
$UFRAME := POS_FRAME(corner, x, xy)
END setframe
As an alternative, a tool is available on the Teach Pendant, Setup page, Motion - Frames
environment, allowing the UFRAME guided calculation; please refer to par. 12.4
UFRAME automatic calculation on page 609 in C5GPlus Control Unit Use manual for
detailed information.

50
 Comau Robotics Product Instruction

MOTION CONTROL

5.3 Trajectory
It represents an Arm motion from an initial position to a final position.
The motion trajectory between two taught positions is generated by interpolating various
sets of variables from their initial values at the start position to their final values at the
destination position. The predefined variable $MOVE_TYPE indicates the type of
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.
The following topics about the Trajectory are described in the next sections:
– Joint Interpolation
– Cartesian Interpolation
– REPLAY (execution of a saved trajectory).

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 Cartesian Interpolation

In case of Cartesian Interpolation, $MOVE_TYPE can be either LINEAR or CIRCULAR.
Below, in the current paragraph, the following topics are described:
– Linear Interpolation
– Circular Interpolation
– Orientation Evolution
– Attitude Flags
– Turn Flag and minimum path.

5.3.2.1 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,

51
Comau Robotics Product Instruction

MOTION CONTROL

WRIST_JNT.
For further information refer to par. 5.3.2.3 Orientation Evolution on page 52.

5.3.2.2 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 required
attitude evolution type.

5.3.2.3 Orientation Evolution

The tool orientation during linear and circular movements evolves from the initial
position to the final position according to the modality indicated by $ORNT_TYPE
variable. Allowed values for this specific program variable are as follows:
– RS_WORLD (two-angles related to the world frame)
– RS_WORLD (two angles related to the world frame)
The orientation evolution is done by linearly interpolating the values of two angles,
tool sliding angle and tool spin angle. The tool sliding angle is the angle around the
common perpendicular between the beginning approach vector and the final
approach vector. The tool spin angle is the angle around the approach vector, from
the start 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.
– RS_TRAJ (two angles related to the trajectory)
Orientation interpolation is done in the same way than RS_WORLD but the sliding
and spin angles are referred to the trajectory. This is particularly useful during
circular trajectory having a center angle grater than 180 degrees when the tool
orientation must be kept constant referred to the trajectory. During linear motions
the orientation evolution is the same than RS_WORLD.
– SL_WORLD, SL_TRAJ
Respectively, similar to RS_WORLD and RS_TRAJ; the only difference is that they
guarantee the evolution along the minimum angular distance.
– WRIST_JNT (wrist joint)
The orientation interpolation is done by using a combination of both joint and linear
interpolation. This allows 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 repeatable. For example, using either
EUL_WORLD or RS_WORLD, if the beginning and ending orientations are the
same, the tool orientation remains fixed during while moving. Using WRIS_JNT
orientation interpolation this is not guaranteed. However, thanks to this orientation
control, smoother motion can be obtained near wrist singularities.

52
 Comau Robotics Product Instruction

MOTION CONTROL

5.3.2.4 Attitude Flags

During Cartesian trajectories (LINEAR and CIRCULAR) the attitude flags of the starting
and final points of a movement must match, otherwise the movement will not be
executed. Attitude flags mean the S, E and W parts of a Cartesian position (see PDL2
Programming Language Manual for further details).
– S flag (see next figure) indicates that the WCP (Wrist Center Point) is currently in
the area behind the plane passing through axis 1 and parallel to axis 2. The behind
area is the opposite space to the one including axis 2;

– E flag (next figure) indicates that the WCP (Wrist Center Point) is currently in the
area behind the plane including the 2nd link (i.e. generally including axes 2 and 3);

– W flag (see next figure) indicates that the value of axis 5 is negative.

53
Comau Robotics Product Instruction

MOTION CONTROL

The only exception is when passing through a singularity point, in which the W flag is
reversed by the system software.
It is, however, allowed to move even if the flags do not match: set $CNFG_CARE
predefined variable to FALSE so that the flag of the final point is assumed to be the one
of the starting point.
This setting is mainly used when mixing movements that use JOINTPOS type variables
and POSITION type variables whose values have been directly set from 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 setting $CNFG_CARE variable to FALSE.

5.3.2.5 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-turn movements, i.e. they can rotate by more than 360
degrees ($STRK_END_P[axis] - $STRK_END_N[axis] > 360) (for further details see the
PDL2 Programming Language Manual).
A Cartesian trajectory (LINEAR or CIRCULAR) generally follows the shortest path for
the joints so the configuration string of the reached final point may differ from the one
specified in the motion instruction. If so, the system will perform the movement in any
case, unless $TURN_CARE predefined variable is set to TRUE; in such a case, an error
message will indicate the difference in the number of turns.
POSITION type variables that were taught using a certain $UFRAME may have a
different number of turns when $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

54
 Comau Robotics Product Instruction

MOTION CONTROL

turn flag in P1 configuration string and therefore, in order to avoid an error in MOVE
LINEAR 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,
performed on points declared as POSITIONs, sets a path that follows the joints
evolution, without taking into consideration the shortest or longest route. To follow the
shortest route (<180 degrees), set $JNT_MTURN variable to FALSE.
Note that $JNT_MTURN variable is ineffective in joint movements on points declared as
JOINTPOS.

NOTE THAT in the following situations

– Spot Welding application with ServoGun,
– any sensor/mechanism performing real-time modification of POSITIONs
(e.g. vision systems for robot guiding, SBCU type sensors for TCP modification,
etc.),
it is STRONGLY RECOMMENDED to insert the following statement at the beginning of
the User PDL2 Program:
$jnt_mturn := FALSE

5.3.3 REPLAY (execution of a saved trajectory)

A movement of REPLAY type is the replay of a previously recorded trajectory saved into
a moni file of REPLAY type.
The statement to be used is

MOVE FROM start_pos REPLAY ‘moni_replay.log’

Refer to PDL2 Programming Language manual - par. 4.1.3.9 MOVE FROM for any
further details.

The following features cannot be used in the MOVE FROM...REPLAY environment

– LINEAR or CIRCULAR motion types
– movements with FLY ADVANCE clause
– use of $TERM_TYPE.
The following constraints must be complied with, to be able to execute such a motion
statement type:
– the moni replay file is Valid (value returned by RPL_GET_DATA built-in routine -
refer to PDL2 Programming Language manual - chap. Built-in routines list for
further details)
– the current robot model and the one on which the trajectory was recorded, are the
same
– the currently active frames and the active ones during the registration are the same
– the moni replay file is not corrupted.
The resulting movement is composed by two phases (figure below):

55
Comau Robotics Product Instruction

MOTION CONTROL

– (1) approach phase to the replay start position (MOVE FROM start_pos), using
a Joint movement
– (2) REPLAY phase i.e. execution of the previously registered and saved trajectory
(MOVE FROM start_pos REPLAY ‘moni_replay.log’).
The current value of $RPL_SPD_OVR predefined variable is used in the second
phase, allowing to modify the replay speed override. Any runtime changings to
$RPL_SPD_OVR predefined variable, during replay movements, has no effects.
Both in phase 1 (approach to the start position) and in phase to (trajectory replay) the
other motion override parameters are used too and they can be modified at runtime,
during motion.
If in the moni replay file the start and end velocities are not zero in the recorded
trajectory, the velocity profile will be modified at the registration beginning and end, so
that a clean start and end of the motion is guaranteed.
Any recorded movements passing close to singularities or showing anomalies, could
generate some "Move Replay not obtainable" errors or, if the anomalies are within
tolerances allowing them to be executed, can be replayed until the end but without any
guarantees of good quality for the movement.
It is the user’s care to evaluate the quality of the recorded movement and to execute a
new registration of the wished trajectory, in case the manufacturing requirements are
not satisfied.

5.3.3.1 Moni of REPLAY type

moni replay is a file with a special structure, including the registration of a more or less
complex robotic trajectory.
It is provided of a header including the following information:
– Major SW Version
– Minor SW Version
– Build Number
– moni Version
– Total amount of acquired samples
– Year
– Month
– Day

56
 Comau Robotics Product Instruction

MOTION CONTROL

– Hour of the acquisition beginning

– Minutes of the acquisition beginning
– Seconds of the acquisition beginning
– Hour of the acquisition end
– Minutes of the acquisition end
– Seconds of the acquisition end
– Velocity at the acquisition beginning (in mm/sec)
– Velocity at the acquisition end (in mm/sec)
– Acquisition maximum velocity (in mm/sec)
– Acquisition starting position
– Acquisition end position
– Active $BASE during the acquisition
– Active $TOOL during the acquisition
– Active $UFRAME during the acquisition
– Model of the Robot used for the registration
– Integrity checksum.

All information included in the moni file header can be read from within a program using
RPL_GET_DATA and RPL_GET_POS built-ins (refer to PDL2 Programming
Language manual - chap. Built-in routines list for further details).

During the registration, the robot cartesian position, together with the attitude flags, and
any Inputs whose registration has been required, are acquired.
To perform a moni replay registration the following tools can be used:
– Path Learning (par. 23. Path Learning on page 317)
– Routines of the MoniReplay_lib (par. 23.2 PDL2 routines to handle MONI
REPLAY type files on page 318).
At a moni replay registration beginning on a real robot, the registration is paused until
the system is put to DRIVE-ON and the velocity is not zero, or one of the registered
inputs does not change status.
During the registration
– if the velocity is zero, the cartesian positions would be registered anyway, in order
to guarantee the pause times duration
– if the system switches to DRIVE-OFF the registration is interrupted
– if BASE, TOOL and UFRAME references are modified, the registration is
interrupted and invalidated.

57
Comau Robotics Product Instruction

MOTION CONTROL

5.4 Position Checking

There 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
in millimeters in relation to the flange ($ARM_DATA[arm].OT_TOL_DIST) and the
threshold in degrees in relation to the flange orientation
($ARM_DATA[arm].OT_TOL_ORNT). In case of a very long tool (for instance, 1 meter
in the tool 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
cause 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_DIST 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.
Anyway, 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:

58
 Comau Robotics Product Instruction

MOTION CONTROL

MOVE TO $CRNT_DATA[arm].OT_JNT
or
MOVE 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 following
Tab. 5.1 - On Pos and On Trajectory on page 60.
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 interrupting the execution of a NON motion instruction of a program open in an

editing environment, $CRNT_DATA[arm].OT_COARSE flag will still be set to TRUE
even if the interrupted statement is between two FLY movements. If the user then moves
the cursor to a specific statement from which going on with the program execution,
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 is up to the user in charge of operating and
controlling the cell.

For further details related to the $OT_xxx system variables and the ON_TRAJ_SET
built-in routine, please refer to 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 involved.
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 PDL2 Programming Language Manual.

59
Comau Robotics Product Instruction

MOTION CONTROL

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:

Tab. 5.1 - On Pos and On Trajectory

On Trajectory On Pos with JOINTPOS On Pos with POSITION
($OP_JNT) ($OP_POS)
Value of: Value of: Value of:
$CRNT_DATA[ ].OT_COARSE $ON_POS_TBL[ ].OP_REACHED $ON_POS_TBL[ ].OP_REACHED
Initial condition TRUE TRUE TRUE
Movement of robot FALSE FALSE FALSE
axis in joint mode
Movement of FALSE FALSE FALSE
integrated auxiliary
axis in joint mode
Movement of FALSE FALSE TRUE
non-integrated
auxiliary axis in joint
mode
Movement in FALSE FALSE FALSE
Cartesian mode with
reference to X, Y, Z
and/or E1, E2, E3
Movement in FALSE FALSE TRUE
Cartesian mode of
integrated auxiliary
axis
Deactivation of FALSE TRUE TRUE
movement program

60
 Comau Robotics Product Instruction

MOTION CONTROL

5.5 Speed Control

Predefined variables are used to control the maximum or constant speed of a motion,
some of which are system-wide, some are program-specific, and some are arm-specific.
Two kinds of speed controls are used:
– absolute speed values, measured in speed units such as radians per second or
meters per second;
– override values (percentages) that control the speed values planned by the
system.
Not only speed can be controlled by the user, but also acceleration and deceleration;
override values for acceleration and deceleration are described in par. 5.6 Acceleration
and Deceleration on page 64 in current chapter.

5.5.1 Speed Overrides

The speed overrides (percentage speed values) that apply to all motions are as follows:
– $GEN_OVR allows the operator to simultaneously change 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.
$GEN_OVR is an INTEGER type variable
It is common to the whole system and can be changed from the Teach Pendant.
The PDL2 programs can only read it .
– $ARM_OVR allows acceleration, speed, and deceleration of a specific arm to be
modified. Since it affects acceleration, speed, and deceleration in a coordinated
way, trajectory shapes are generally maintained when this variable is modified
(except for differences in servo following errors at different values of override).
$ARM_OVR is an INTEGER field of the system-wide matrix of elements,
$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 74 in
current chapter.
– $ARM_SPD_OVR allows the speed of a specific arm to be modified. 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 74 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 allows speed of all motions issued from a specific program to
be modified by the program. Acceleration and deceleration are not affected.

61
Comau Robotics Product Instruction

MOTION CONTROL

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 74
section 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

The speed of a specific motion corresponding to an arm is automatically computed in
order to take the best advantage of the machine performances.

5.5.2.1 Cartesian Speed Control Options

The process of determining which component will control the Cartesian speed is called
preplanning and it is performed immediately before the actual motion execution (i.e.
before each MOVE). The preplanner can be forced to use a specific motion component
by means of $SPD_EMT predefined variable. It is a program-specific variable (each
program can have its own value) that can be assigned the following predefined
constants:
– SPD_EMAX is the default value. Speed is automatically calculated in order to take
the maximum advantage in the robot performances.
– SPD_LIN moves the TCP according to the requested $LIN_SPD, forcing the
rotation component to move in coordinate way.
$LIN_SPD is a REAL field of $ARM_DATA structure array.
If $SPD_EMT value is not meaningful for the current trajectory type, the default
SPD_EMAX value is assumed.
Changes to $SPD_EMT and $LIN_SPD only take effect at the beginning of the next
movement. Changes do not affect the arm current motion.

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

62
 Comau Robotics Product Instruction

MOTION CONTROL

a field of $ARM_DATA[] global predefined structures array.

Thus there is a value for each axis for each arm.
The speed override for each joint is determined by $JNT_OVR, which allows
acceleration, speed, and deceleration to be modified together by a program.
It is a field of $ARM_DATA and it is an INTEGER structures array.
There is an override value for each axis of each arm. The default value is 100.
Irrespective of the current payload, if the being covered path is enough, at least one joint
will reach its motor maximum speed. All the other joints will move at lower speeds than
the corresponding maximum one, so that all of them can move from start position and
reach end position in synchronized mode.
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_EMT 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.

63
Comau Robotics Product Instruction

MOTION CONTROL

5.6 Acceleration and Deceleration

Acceleration and deceleration are composed by three phases: an increasing jerk phase,
followed by a constant acceleration phase (which could also not be present), followed
by another decreasing jerk phase.
See Fig. 5.3 - Speed and acceleration profiles on page 64.

Fig. 5.3 - Speed and acceleration profiles

For a joint interpolated motion, the time related to the joint that takes the longest to
accelerate/decelerate to its final speed is picked up to be used for all joints in order to
coordinate acceleration/deceleration values.
The maximum values of acceleration and deceleration for each movement are
calculated in order to take the maximum advantage of at least the maximum torque of
one joint. The jerk phases are determined to obtain the motion best quality.
If possibly the robot shows some vibrations, the user could set the $EMT_STRESS
predefined variable to a value less than the default (100). This would allow decreasing
the dynamic stress to which the robot is subject during motion, with a resulting reduction
of its performance in terms of cycle time, much more obvious when such a value is
farther than the default one. For further details refer to PDL2 Programming Language
manual, par. $EMT_STRESS: eMotion stress.

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 61,
$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 allows 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;

64
 Comau Robotics Product Instruction

MOTION CONTROL

– $PROG_DEC_OVR allows 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 allows acceleration of a specific arm to be modified. It is an
INTEGER field of the array, $ARM_DATA, with one field for each arm. The default
value is 100;
– $ARM_DEC_OVR allows deceleration of a specific arm to be modified. It is an
INTEGER field of the array, $ARM_DATA, with one field for each arm. The default
value is 100.
The equations for motion override for acceleration and deceleration are:
total acceleration override[arm] =
$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
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.

Quick STOP
The code option is CR17926224.
Upon pressing the Emergency Stop Button, this option causes the deceleration time to
be reduced with respect to the standard deceleration time, with a greater stress for
mechanical components.

5.6.2 Extra acceleration

This functionality is currently available for R1C Control Units ONLY, and for RACER and
REBEL robot models.
For further details about the robot models, please refer to the corresponding Technical
Specifications manual.

During the standard usage, the acceleration default setting is chosen as the best value
in order to optimize performances and vibrations during the positioning phase.
In case of high accelerations are required to reduce the cycle time, the acceleration
value can be increased by means of $EMT_INCR predefined variable.
If an acceleration value greater than the default is used, the robot could be affected by
vibrations, current saturations (or overload alarms) and overheating during contiuous
working.
Basically, trajectories are always kept (except in case of servo following errors) when
$EMT_INCR value is modified.
$EMT_INCR predefined variable is of INTEGER type, is a field of $ARM_DATA (default
value = 1) and has a range of 1.. 5.

65
Comau Robotics Product Instruction

MOTION CONTROL

Such values can be used to set the eMotion trajectory control algorithm to operate until
the 120% and have the following meaning:
– 1 - 100%
– 2 - 105%
– 3 - 110%
– 4 - 115%
– 5 - 120%
They can be also modified by means of the TP5 Teach Pendant user interface, from
within the Setup page, accessing to Motion - eMtInc environment and acting on the
displayed gauge (as shown in the following figures).

After selecting the wished value, touch Apply key to make the modification operational.
Touch OK key to exit from the environment.
The use of values greater than 1 for $EMT_INCR is just suggested for strictly necessary
situations.

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

66
 Comau Robotics Product Instruction

MOTION CONTROL

5.7 Motion termination (positioning accuracy)

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

67
Comau Robotics Product Instruction

MOTION CONTROL

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.

68
 Comau Robotics Product Instruction

MOTION CONTROL

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.

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
$TOL_JNT_COARSE[ ] predefined variable array. The short range reset takes place by
means of a move in joints interpolation that is entirely transparent to the user. That is,
when START button is pressed to resume a motion, a short range recovery motion will
be inserted immediately before the original motion is resumed. In many cases, this reset
move is not even perceived by the operator.
If the distance between the current position and the nominal position is major to a certain
limit (short range) the resumption of motion takes place according to the modes defined
by the predefined variable $RCVR_TYPE value set. The possible values of this
predefined variable are shown in the following table:

0 Bring the arm to the interrupted trajectory position, by the joint interpolation.
1 Bring the arm to the movement start position that was interrupted by the joint interpolation.
2 Bring the arm to the interrupted movement destination position using the joint interpolation.
3 Do not reset, generate an error message.
4 If the interrupted movement was Cartesian, restore the interrupted trajectory by a straight-line
movement. Otherwise use joint interpolation .
5 If the interrupted movement was Cartesian, bring the arm back to the start position of the interrupted
movement by a straight-line interpolation. Otherwise use joint interpolation .
6 If the interrupted movement was Cartesian, bring the arm to the interrupted movement destination
position by a straight-line interpolation. Otherwise use joint interpolation .
7-8 reserved

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.

69
Comau Robotics Product Instruction

MOTION CONTROL

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 Recovery procedure

If the System executes the recovery procedure, by issuing the corresponding messages
“Trajectory recovery in progress” and “Recovery position reached”, it is needed to
double press the START button.
On the contrary, if no messages are issued, just one pressure is required for the START
button.

70
 Comau Robotics Product Instruction

MOTION CONTROL

5.9 Process Resume

The 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 on page 72) or upon exhaustion of the
movement preceding the one in progress (Fig. 5.5 - Return Movements - example B on
page 72 and Fig. 5.6 - Return Movements - example C on page 72).

Fig. 5.4 - Return Movements - example A

Simplest situation.
1. Programmed Fly position, between two movements 2. First movement - fly termination
3. Second movement - fly beginning 4. Second movement - fly termination
5. Stop position 6. Motion direction
7. First movement – fly beginning

71
Comau Robotics Product Instruction

MOTION CONTROL

Fig. 5.5 - Return Movements - example B

$RCVR_DIST programmed value is greater than the maximum recoverable one

1. Maximum recoverable distance
2. Stop position

Fig. 5.6 - Return Movements - example C

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

1. Stop position
2. 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

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.

72
 Comau Robotics Product Instruction

MOTION CONTROL

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 on page 73).

Fig. 5.8 - Example in case of $RCVR_DIST modification

1. Stop position of the return movement 2. First value of $RCVR_DIST=20 mm

3. Return movement interruption: $RCVR_DIST is read again
4. $RCVR_DIST=30 mm after the modification 5. 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.

1. motion direction 2. trajectory

3. calculated return movement 4. $RCVR_DIST
5. decelerate distance 6. motion stop command
7. actual motion stop position

73
Comau Robotics Product Instruction

MOTION CONTROL

5.10 Continuous Motion

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

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

1. Motion start towards c Motion end towards b 1 - 2 segment = connection in fly

CAUTION
$TOOL predefined variable cannot be modified during cartesian fly movement (neither
liner nor circular).
If this happens, the following error would occur:
37130 "$TOOL changed during fly"

5.10.1 Trajectory Shape During Continuous Motion

Fig. 5.9 - Example of continuous motion in case of linear movement on page 74 shows
a rounded corner during the transition (fly) between the motion from a to b and the
motion from b to c. The shape and amount of such rounding is a function of the user
settings ($FLY_PER, $FLY_DIST), the speed of the two motions, the values used for
acceleration and deceleration, the axis control algorythm of the arm, the 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

74
 Comau Robotics Product Instruction

MOTION CONTROL

to change only speed, and trajectory shape is unimportant during fly.

5.10.2 Continuous Motion Modes (FLY)

The FLY motion configuration, depending on whether joint or cartesian, is made by
setting the following predefined variables:
– $SPD_EMT
– $FLY_DIST
– $FLY_PER
– $FLY_TYPE
– $LIN_SPD

Furthermore, in order to enable the execution of some FLY types, the Lookahead
functionality (optional feature) is available which allows to increase the Lookahead level,
acting on the following predefined variables:
– $ADVANCE
– $DFT_ADVANCE.

A detailed description of such an option is provided below for the following topics:
– Lookahead functionality (optional feature)
– Available FLY types
– Joint FLY
– Cartesian FLY
– Using $DFT_ADVANCE and $ADVANCE.

5.10.2.1 Lookahead functionality (optional feature)

Lookahead software option

The option code is CR17926228.

This optional functionality, which can be purchased for eMotion only, starting from
4.20.xxx system software version, in the presence of the ADVANCE clause, allows the
Interpreter to take into consideration the subsequent fly motion statements, up to 7, in
order to improve the system performances.
Improving the system performances means:
– reducing the cycle time, in case of FLY between Joint trajectories, thanks to a
motion geometry consisting of more marked connections and reduction of the
space covered by the robot
– optimizing the speed profiles, in case of FLY between Cartesian trajectories,
without modifying the connections geometry, helping to keep constant speeds (if
the available motors torque limits allow it), sometimes at the expence of the cycle
time. This kind of improvement is suitable for processes requiring to keep a

75
Comau Robotics Product Instruction

MOTION CONTROL

specified process velocity and it is suggested to use it in case of programs with a

defined velocity.
When the optional Lookahead functionality is present and active, it is needed to take
into account its effects on the programs interpretation. As a matter of fact it could be
needed an additional care in synchronizing motion instructions with non motion ones, in
PDL2 programs.

For any further information, refer to the PDL2 programming language manual:
– par. 4.1 Motion instructions interpretation and execution,
– par. 4.2.4.1 ADVANCE Clause,
– par. 4.2.6.2 Timing and Synchronization considerations.

Starting from 4.20.xxx system software version, two predefined variables are available
to activate the Lookahead option (if purchased), which affect the Interpreter operation.
– $ADVANCE
– $DFT_ADVANCE,
to be suitably setup, in order to specify how many subsequent FLY motion statements
the Interpreter must take into account, as described in par. 5.10.2.5 Using
$DFT_ADVANCE and $ADVANCE on page 87.

5.10.2.2 Available FLY types

The FLY connections can be classified by types of trajectories to be connected.
Basically, we speak about Joint FLY when the two connected trajectories are of both
JOINT type and Cartesian FLY when the two connected trajectories are of either
LINEAR or CIRCULAR type.

It is strongly discouraged to connect in FLY trajectories of different types

(JOINT-CARTESIAN or CARTESIAN-JOINT) since they could give rise to unpredictable
behaviours.

Depending on the motion statements to be connected and on whether the Lookahead

option is present, different FLY types can be set ($FLY_TPE).

5.10.2.2.1 Available FLY types summary table

The current section is referred to the Lookahead option only.

The following table, referred to the Lookahead option, shows the available FLY types
depending on the set lookahead level ($ADVANCE value).
– $ADVANCE = 1 enables the execution of FLY_NORM only, both Joint and
Cartesian
– $ADVANCE = 2 enables the execution of FLY_NORM, both Joint and Cartesian,
and also of Joint FLY_PLUS.

76
 Comau Robotics Product Instruction

MOTION CONTROL

– $ADVANCE values between 3 and 6 are not recommended since they give the
same capabilities of $ADVANCE = 2, without adding any improvements;
furthermore, increasing the gap between the motion cursor and the execution
cursor, they make the synchronism between motion and non motion statements
more difficult (for any further details refer to par. 5.10.2.5 Using $DFT_ADVANCE
and $ADVANCE on page 87)
– $ADVANCE = 7 enables the execution of FLY_NORM, both Joint and Cartesian,
Joint FLY_PLUS, and also FLY_MULTI, both Joint and Cartesian.

The Cartesian FLY_PLUS does not exist and the corresponding not allowed
MOVE_TYPE and FLY_TYPE combination, generates a MOVEFLY_NOT_AVAILABLE
error.
In some software versions also the Cartesian FLY_MULTI could generate the
MOVEFLY_NOT_AVAILABLE error. Call Comau for any version upgrading or enabling.
In order to further configurate the Joint FLY, $FLY_PER predefined variable can be
used.
Detailed descriptions follow in the dedicated sections: par. 5.10.2.3 Joint FLY on
page 77 and par. 5.10.2.4 Cartesian FLY on page 81.

5.10.2.3 Joint FLY

Joint FLY represents the connection segment between two consecutive motion
statements with $MOVE_TYPE = JOINT.

77
Comau Robotics Product Instruction

MOTION CONTROL

In case of JOINT FLY with eMotion control, always assume that

$SPD_EMT = SPD_EMAX.

It can be of the following types:

– FLY_NORM
– FLY_PLUS (with Lookahead option only)
– FLY_MULTI(with Lookahead option only)
With the Lookahed option, the Joint FLY motion configuration (see also Available FLY
types summary table) is made by setting the following predefined variables:
– $FLY_TYPE
– $FLY_PER
– $ADVANCE (to activate the Lookahead functionality)
– $DFT_ADVANCE (to activate the Lookahead functionality).
There are three Joint FLY connection types, selectable by means of the $FLY_TYPE
predefined variable.
The Interpreter must be able to look at least 1 motion statement ahead, for the same
arm, to plan a FLY connection segment, before the end of the current movement. The
use of the ADVANCE clause is mandatory to generate a FLY movement.

Refer to the following paragraphs, for any further information:

– par. 4.1 Motion instructions interpretation and execution,
– par. 4.2.4.1 ADVANCE Clause,
– par. 4.2.6.2 Timing and Synchronization considerations
in PDL2 Programming Language manual.

Starting from 4.20.xxx system software version, an option is available which allows the
Interpreter capability of “looking ahead” to be improved: it can be configured, as wished
by the user, from the subsequent motion statement until the “n” subsequent ones, where
“n” is the value the $ADVANCE predefined variable is set to.
Such an OPTIONAL capability is referred to as Lookahead functionality and is
described in par. 5.10.2.1 Lookahead functionality (optional feature) on page 75.

The following topic is described below:

– Using $FLY_TYPE and $FLY_PER for the Joint FLY.

5.10.2.3.1 Using $FLY_TYPE and $FLY_PER for the Joint FLY

The $FLY_TYPE predefined variable specifies which control algorithm should be used
for the continuous motion. Basically, such an algorithm affects the velocity and the
trajectory shape during the continuous motion, and also the amount of stress applied to
the arm and the component or tool connected to it.
Starting from 4.20.xxx system software version, if the Lookahead functionality (optional
feature) is present, the control algorithm also allows to plan a more or less evident joint
connection trajectory and to modify the final destination of each individual motion
statement.

78
 Comau Robotics Product Instruction

MOTION CONTROL

The $FLY_TYPE predefined variable specifies the wished connection type, in Joint FLY.
The available values are:
– FLY_NORM
– FLY_PLUS - available with Lookahead option only, starting from 4.20.xxx system
software version
– FLY_MULTI- available with Lookahead option only, starting from 4.20.xxx system
software version.

In the above cases, the connection shape is also affected by the value of $FLY_PER
predefined variable.
$FLY_PER specifies which is the overlap percentage to be used for the fly movements.

FLY_NORM
When $FLY_TYPE is set to FLY_NORM, the MOVEFLY statement causes the
deceleration of the current movement to overlap on the acceleration of the subsequent
one.
$FLY_PER predefined variable (the only variable affecting FLY_NORM type) can be
used to reduce the fly time, moving the trajectory closer to the taught intermediate
position.
In such a case, the fly starts as soon as the deceleration begins, plus a time of 100%
minus the percentage specified by $FLY_PER.
For example, if $FLY_PER is 100, the fly segment starts at the beginning of the current
movement deceleration. If $FLY_PER is 75, the fly segment only starts as soon as the
25% of the deceleration has been performed (the remaining 75% is joined to the
subsequent movement).
Basically, the motion velocity during fly is not constant.
FLY_NORM is the default value for $FLY_TYPE.

FLY_PLUS

This value of $FLY_TYPE, since 4.20.xxx system software version, is only available
with Lookahead option, for any situations with $ADVANCE >= 2.

79
Comau Robotics Product Instruction

MOTION CONTROL

It provides higher performances than FLY_NORM value, since it allows the Interpolator
to execute in advance the calculations for more than one motion statements, so being
able to plan a more evident joint connection.

The value of $FLY_PER predefined variable, as in the previous FLY_NORM case,

represents the overlap/cut percentage of the involved movements, with the following
meanings (the listed colours refer to the figure above):
– 0 (magenta) - no overlap, so no fly
– 100 (yellow) - maximum allowed overlap/cut
– values between 1 and 99 (blue) - allows to modify the overlap between the two fly
movements, affecting the trajectory during the connection segment. FLY_PER can
also be used in the WITH clause, thus affecting an individual connection segment
only, independently from the fly of the same motion chain.

FLY_MULTI

This value of $FLY_TYPE, since 4.20.xxx system software version, is only available
with Lookahead option, for any situations with $ADVANCE = 7.

It allows modifying the end point of each individual motion statement belonging to the fly
chain, according to the subsequent points taken into consideration by the Interpreter
through the Lookahead option.

This fly type allows “stretching” the trajectory in the intermediate points of the fly, as
shown in the example in the figure above.

80
 Comau Robotics Product Instruction

MOTION CONTROL

The value of $FLY_PER predefined value represents the variance percentage from the
end point of each individual motion statement belonging to the fly chain.
The maximum variance is calculated taking into account all the fly chain looked-ahead
points. $FLY_PER acts point by point in independent way, with the following meanings
(the listed colours refer to the figure below):
– 0 (magenta) - keeps the original point
– 100 (yellow) - indicates the maximum allowed distancing from the original point
– values between 1 and 99 (blue) - allows modifying the distancing between the
original and the maximum distancing of the chain points, taken once each.

5.10.2.4 Cartesian FLY

Cartesian FLY represents connections between motion statements with
$MOVE_TYPE=LINEAR and/or $MOVE_TYPE=CIRCULAR
Cartesian FLY can be of the following types:
– FLY_NORM
– FLY_MULTI (with Lookahead option only).
The Cartesian FLY motion configuration is made by setting up the following predefined
variables:
– $FLY_TYPE
– $SPD_EMT
– $LIN_SPD
– $FLY_DIST
– $ADVANCE (with Lookahead option only)
– $DFT_ADVANCE (with Lookahead option only)

Refer to the following paragraphs, for any further information:

– par. 4.1 Motion instructions interpretation and execution,
– par. 4.2.4.1 ADVANCE Clause,
– par. 4.2.6.2 Timing and Synchronization considerations
in PDL2 Programming Language manual.

81
Comau Robotics Product Instruction

MOTION CONTROL

Starting from 4.20.xxx system software version, an option is available which allows the
Interpreter capability of “looking ahead” to be improved: it can be configured, as wished
by the user, from the subsequent motion statement until the “n” subsequent ones, where
“n” is the value the $ADVANCE predefined variable is set to.
Such an OPTIONAL capability is referred to as Lookahead functionality and is
described in par. 5.10.2.1 Lookahead functionality (optional feature) on page 75.

A detailed description is provided for the following topics:

– Geometry and Speed Profile in the Cartesian FLY: FLY_NORM vs FLY_MULTI
– Events related to FLY movements with trajectory control (constant speed or
specified FLY_DIST)
– Setting the Cartesian FLY predefined variables.

5.10.2.4.1 Geometry and Speed Profile in the Cartesian FLY: FLY_NORM vs

FLY_MULTI

The FLY_MULTI value of $FLY_TYPE is only available with the Lookahead functionality
(optional feature).

The connection between two cartesian movements is made by dealing with two issues:
– creating a geometric connection
– defining a speed profile allowing to pass from a movement and the subsequent one
without stopping the robot, i.e. without reaching a null velocity.
The two Cartesian FLY available with eMotion, deal with the geometric connection
creation by using the same philosophy and then give rise to congruent trajectories from
the cartesian point of view.

Parametrizing the connection from the geometric pont of view

The Cartesian connection can be parametrized by using
– $FLY_DIST

$FLY_DIST
This predefined variable allows specifying the distance (mm) between the taught
intermediate position and a position on the bisector of the angle included between the
two trajectories ($FLY_DIST is represented by d in Fig. 5.10).
If $FLY_DIST > 0, the robot exactly moves to the distance selected by B position, at the
expence of keeping the setup speed (distance has priority over speed).
If $FLY_DIST value is too high with respect to the trajectory, the fly connection is
executed at the maximum allowed distance.
If $FLY_DIST = -1, the FLY connection is executed at the maximum allowed distance.
The maximum allowed distance is restricted by the length of the two motion segments
to be connected, but also by some features of the used velocity profile.
Therefore the maximum allowed distance for FLY_NORM and FLY_MULTI (with
Lookahead option only) types, could be different.

82
 Comau Robotics Product Instruction

MOTION CONTROL

The congruence of the Cartesian trajectories is not guaranteed anyway and must be
checked, since it is sometimes constrained and limited in different ways by the used
velocity profile.

Fig. 5.10 - FLY movements - example

The table of par. 5.10.2.4.3 Setting the Cartesian FLY predefined variables on page 86
summarizes what described above.

NOTE
If the setup velocities are too high compared with the robot movement, the system
automatically calculates the maximum allowed one for the connection segment and the
best position to start the speed variation. Please refer to par. 5.10.2.4.2 Events related
to FLY movements with trajectory control (constant speed or specified FLY_DIST) on
page 85 for further details.

Parametrizing the velocity profile of the FLY connection

The velocity profile of the Cartesian connection can be parametrized by using:
– $FLY_TYPE
– $LIN_SPD
– $SPD_EMT.

$FLY_TYPE
This predefined variable can assume the following values:
– FLY_NORM - first of all the single MOVE speed profiles are planned as
point-to-point movements and then the speed profile of the connection is
calculated creating a gradual transition between the maximum speeds of the two
movements.
– FLY_MULTI (only available with active Lookahead option) - it is useful in case of
programs with defined speed.
Thanks to the Lookahead of the subsequent movements, it is able to
• calculate the connection geometry in advance and not constrained by the
point-to-point MOVE speed profile
• evaluate the maximum allowed speed at the end of each segment
• plan the individual segments speed profiles (MOVE –FLY –MOVE – FLY -
etc) in sequence and in order to optimize keeping a constant speed.

$LIN_SPD
In case of $SPD_EMT:=SPD_LIN, this predefined variable represents the speed (m/s)

83
Comau Robotics Product Instruction

MOTION CONTROL

related to the individual MOVE statement.

If the two MOVEs composing the FLY have the same $LIN_SPD value, the connection
segment (if possible) is executed keeping the same speed.
If the two MOVEs composing the FLY have different $LIN_SPD values, the connection
segment (if possible) is executed gradually varying the speed from the one of the first
MOVE, to the one of the second MOVE.

$SPD_EMT
This predefined variable can assume the following values: SPD_EMAX and SPD_LIN.
The table of par. 5.10.2.4.3 Setting the Cartesian FLY predefined variables on page 86
summarizes what described above.

NOTE
If the setup velocities are too high compared with the robot movement, the system
automatically calculates the maximum allowed one for the connection segment and the
best position to start the speed variation. Please refer to par. 5.10.2.4.2 Events related
to FLY movements with trajectory control (constant speed or specified FLY_DIST) on
page 85 for further details.

In the following figures, just in the case of Lookahead option, FLY_NORM and
FLY_MULTI are compared in the same program, in order to point out differences.
The program executes some MOVE statements at a controlled speed of 0.4 m/sec.

In the above diagram, the speed profile of the MOVE statements executed
point-to-point, is displayed in yellow. Note that some of them, too short, don’t have
space enough to reach the speed set by the user.
The speed profile of the MOVE statements executed in FLY NORM, is displayed in blue.
Note that the resulting speed profile is the union of the maximum speeds of the individual
motion segments, with unavoidable speed wholes in correspondence with the MOVE
statements whose maximum speed does not reach the one set by the user.
In the following diagram, the speed profile of the same MOVE statements executed in
FLY_MULTI, is displayed in purple. Such a fly type is able to successfully keep a

84
 Comau Robotics Product Instruction

MOTION CONTROL

constant speed.

The speed wholes, during movements at constant process speed, are not always
caused by too short movements in the FLY sequence.
Sometimes they are caused by reached mechanical limits, motor torque limits, joints
maximum speed limits, strokend or kinematic singularity proximity In such a situations,
it is suggested to modify the program, choosing adifferent position for the work part to
be manipulated by the robot in an easier way.

5.10.2.4.2 Events related to FLY movements with trajectory control (constant speed
or specified FLY_DIST)
In trajectory control FLY, for eMotion control systems, the exact moments in which AT
START and AT END conditions trigger are not depending on the fly segment length.
Moreover, they are different from one MOVE to another, in a non-predictable way (see
next figure, on the left).

On the other side, for joints movements FLY, the moments in which the two described
above conditions trigger are not different for eMotion control, compared to the standard
control. They still are strictly connected to the beginning and end of the FLY segment
(see previous figure, on the right).

85
Comau Robotics Product Instruction

MOTION CONTROL

A condition is available allowing to exactly select any points of the fly segment. The user
can specify any percentage integer value between 0% and 100%:
WHEN PERCENT int_expr AFTER STARTFLY
where, for example (see next figure)
int_expr = 1 --> FLY segment beginning
int_expr = 100 --> FLY segment end.

or
int_expr = 50 --> halfway of the FLY segment

As already stated, in trajectory control FLY, for eMotion control systems, upon a speed
change between the two MOVE statements, the speed variation takes place at the
beginning of the connecting segment between the two movements, thus NOT at the
point corresponding to AT START event, but at the one corresponding to
PERCENT 1 AFTER STARTFLY
event.

Two more conditions are available allowing to select a FLY position measured in relation
to the closest point to the programmed one. The identified point is not related to the
target position, but rather to the actual one.
Such conditions are:
– WHEN TIME vi_time BEFORE HALFFLY
allows generating an event at the specified vi_time time before reaching the closest
point to the programmed one belonging to the FLY segment.
– WHEN DISTANCE vi_dist BEFORE HALFFLY
allows generating an event at the specified vi_dist distance before reaching the
closest point to the programmed one belonging to the FLY segment.

5.10.2.4.3 Setting the Cartesian FLY predefined variables

Speed $FLY_DIST
Constraints $SPD_EMT $LIN_SPD
option (MOVEFLY only)

Maximum None -1 --
SPD_EMAX
speed Distance >0 (mm) --
Constant Constant speed only (*) -1 linear speed
SPD_LIN
speed Distance and then constant speed (**) >0 (mm) (m/s)

86
 Comau Robotics Product Instruction

MOTION CONTROL

(*) Speed has priority over distance

(**) Distance has priority over speed.

5.10.2.5 Using $DFT_ADVANCE and $ADVANCE

$DFT_ADVANCE and $ADVANCE predefined variables are only available with

Lookahead functionality (optional feature), starting from 4.20.xxx system software
version.
The current section only applies to systems with Lookahead option.

$DFT_ADVANCE is defined at system level and indicates the total amount of fly motion
statements that will be taken into account by the Interpreter. The allowed values are:
– 1 - default value
– 2
– 7
$ADVANCE is defined at program level. At the program start, it is initialized to
$DFT_ADVANCE current value but it could even be modified during the program
execution.
The following situations may occur:
– $ADVANCE = 1
– $ADVANCE = 2
– $ADVANCE = 7.

87
Comau Robotics Product Instruction

MOTION CONTROL

$ADVANCE = 1

The only available FLY_TYPE with such a setting, is FLY_NORM. The Interpreter
behaviour is the standard one: the presence of the ADVANCE clause, causes the
Interpreter to look ahead 1 MOVE statement.
In IDE Page, the user is allowed to view the situation (figure above) by means of the
EXECUTION CURSOR which points to the last MOVE statement taken into account by
the Interpreter.
The following MOVEs are then contained in the Interpolator execution memory,
depending on the situations:
– 1 MOVE (i.e. the current MOVE only; no ADVANCE clause, so no FLY)
– 2 MOVE (FLY)
– 3 MOVE (FLY during the connection segment).
Furthermore, View motions of program command (figure above), available in the IDE
Page, allows the user to view full information about all the motion instructions taken into
consideration by the Interpreter for the FLY.

88
 Comau Robotics Product Instruction

MOTION CONTROL

$ADVANCE = 2

The available FLY_TYPEs with such a setting, are FLY_NORM and FLY_PLUS (Joint
FLY only).
The presence of the ADVANCE clause, causes the Interpreter to look ahead 2 MOVE
statements.

CAUTION
The NON motion statements are executed in advance, compared to the situation of
$ADVANCE = 1.
It is then strongly recommended to carefully handle the synchronization situations
between motion and non-motion instructions.

In IDE Page, the user is allowed to view the situation (figure above) by means of the
EXECUTION CURSOR which points to the last MOVE statement taken into account by
the Interpreter.
The following MOVEs are then contained in the Interpolator execution memory,
depending on the situations:
– 1 MOVE (i.e. the current MOVE only; no ADVANCE clause, so no FLY)
– 3 MOVE (FLY)
– 4 MOVE (FLY during the connection segment).
Furthermore, as already described for $ADVANCE = 1, View motions of program
command (figure above) allows the user to view full information about all the motion
instructions taken into consideration by the Interpreter for the FLY.

89
Comau Robotics Product Instruction

MOTION CONTROL

$ADVANCE = 7

All the FLY TYPEs are available with this setting: FLY_NORM, FLY_PLUS (Joint FLY
only) and FLY_MULTI.
The presence of the ADVANCE clause, causes the Interpreter to look ahead 7 MOVE
statements.

CAUTION
The NON motion statements are executed in advance, compared to the situation of
$ADVANCE = 1.
It is then strongly recommended to carefully handle the synchronization situations
between motion and non-motion instructions.

In IDE Page, the user is allowed to view the situation (figure above) by means of the
EXECUTION CURSOR which points to the last MOVE statement taken into account by
the Interpreter.
The following MOVEs are then contained in the Interpolator execution memory,
depending on the situations:
– 1 MOVE (i.e. the current MOVE only; no ADVANCE clause, so no FLY)
– 8 MOVE (FLY)
– 9 MOVE (FLY during the connection segment).
Furthermore, as already described for $ADVANCE = 1 and $ADVANCE = 2, View
motions of program command (figure above) allows the user to view full information
about all the motion instructions taken into consideration by the Interpreter for the FLY.

Effects on the already existing programs

As already stated, it is needed to carefully handle the synchronization between motion
and non-motion instructions execution, when using the full Lookahead option
functionality ($ADVANCE > 1).

90
 Comau Robotics Product Instruction

MOTION CONTROL

More in details, it is recommended to check timings when using instructions such as

– HOLD
– WRITE
– handling I/O ports
– times acquisition
– etc.
The use of CONDITIONs could be helpful to implement such synchronizations, as
shown in the Example below.

For any further detailed information, refer to par.4.1 Motion instructions interpretation
and execution and par 4.2.6.2 Timing and Synchronization considerations, in PDL2
Programming Language manual.

As far as the multiarm systems, it could be needed to increase the value of $NUM_MB
predefined variable which represents the maximum amount of motion instructions taken
into account at the same time.
Such an increase, if too high, could affect the system capability of completely executing
the power failure recovery procedure; it is then suggested to increase it just to be able
to properly execute the program, without any exaggeration.

Example
PROGRAM p_Jstar PROG_ARM = 1

VAR
vp_cal_user, p11 : POSITION
vj_cal_user : JOINTPOS
vr_scale : REAL
ray : REAL
ray2 : REAL
si_i : INTEGER
p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p12 : POSITION

ROUTINE ru_print(si_num : INTEGER)

BEGIN
WRITE LUN_CRT ('print inside condition AT END MOVEFLY TO p', si_num, ' time ', $TIMER[1],
NL)
END ru_print

BEGIN
-- adjustment to more robots
$UFRAME := POS(0)
$UFRAME.X := $ARM_DATA[$PROG_ARM].AX_LEN[3] * 1.25
$UFRAME.Z := $ARM_DATA[$PROG_ARM].AX_LEN[1] + $ARM_DATA[$PROG_ARM].AX_LEN[2] /
($ARM_DATA[$PROG_ARM].AX_LEN[2] / 3)
$UFRAME.R := $ARM_DATA[1].CAL_USER[1] * -1
$TOOL := POS(0, 0, 200, 0, 0, 0)
$BASE := POS(0)
ray := 200
ray2 := ray / 4

vj_cal_user := $ARM_DATA[1].CAL_USER
vj_cal_user[5] := 90
JNTP_TO_POS(vj_cal_user, vp_cal_user)

91
Comau Robotics Product Instruction

MOTION CONTROL

CONDITION[1] :
WHEN AT END DO
HOLD
ENDCONDITION
CONDITION[5] :
WHEN AT END DO
ru_print(5)
ENDCONDITION

CONDITION[12] :
WHEN AT END DO
ru_print(12)
ENDCONDITION

p1 := POS(ray * COS(360 / 12 * 1), ray * SIN(360 / 12 * 1), 0, 0, 180, 0)

p2 := POS(ray2 * COS(360 / 12 * 2), ray2 * SIN(360 / 12 * 2), 0, 0, 180, 0)
p3 := POS(ray * COS(360 / 12 * 3), ray * SIN(360 / 12 * 3), 0, 0, 180, 0)
p4 := POS(ray2 * COS(360 / 12 * 4), ray2 * SIN(360 / 12 * 4), 0, 0, 180, 0)
p5 := POS(ray * COS(360 / 12 * 5), ray * SIN(360 / 12 * 5), 0, 0, 180, 0)
p6 := POS(ray2 * COS(360 / 12 * 6), ray2 * SIN(360 / 12 * 6), 0, 0, 180, 0)
p7 := POS(ray * COS(360 / 12 * 7), ray * SIN(360 / 12 * 7), 0, 0, 180, 0)
p8 := POS(ray2 * COS(360 / 12 * 8), ray2 * SIN(360 / 12 * 8), 0, 0, 180, 0)
p9 := POS(ray * COS(360 / 12 * 9), ray * SIN(360 / 12 * 9), 0, 0, 180, 0)
p10 := POS(ray2 * COS(360 / 12 * 10), ray2 * SIN(360 / 12 * 10), 0, 0, 180, 0)
p11 := POS(ray * COS(360 / 12 * 11), ray * SIN(360 / 12 * 11), 0, 0, 180, 0)
p12 := POS(ray2 * COS(360 / 12 * 12), ray2 * SIN(360 / 12 * 12), 0, 0, 180, 0)
CYCLE
$ADVANCE := 7
$FLY_TYPE := FLY_MULTI

$FLY_DIST := -1
$TIMER[1] := 0
MOVE JOINT TO vp_cal_user -- cal_user is the start position
FOR si_i := 1 TO 100 DO
MOVEFLY JOINT TO p1 ADVANCE WITH CONDITION[1]
WRITE LUN_CRT ('Print after MOVEFLY TO P1 ', $TIMER[1], NL)
MOVEFLY JOINT TO p2 ADVANCE
MOVEFLY JOINT TO p3 ADVANCE
MOVEFLY JOINT TO p4 ADVANCE
MOVEFLY JOINT TO p5 ADVANCE WITH CONDITION[5]
WRITE LUN_CRT ('Print after MOVEFLY TO P5 ', $TIMER[1], NL)
MOVEFLY JOINT TO p6 ADVANCE
MOVEFLY JOINT TO p7 ADVANCE
MOVEFLY JOINT TO p8 ADVANCE
MOVEFLY JOINT TO p9 ADVANCE
MOVEFLY JOINT TO p10 ADVANCE
MOVEFLY JOINT TO p11 ADVANCE
MOVEFLY JOINT TO p12 ADVANCE WITH CONDITION[12]
WRITE LUN_CRT ('Print after MOVEFLY TO P12 ', $TIMER[1], NL)
ENDFOR
MOVE JOINT TO p1
MOVE JOINT TO vp_cal_user

IF $CYCLE = 5 THEN
DEACTIVATE
ENDIF
END p_Jstar

92
 Comau Robotics Product Instruction

MOTION CONTROL

Output from the sample program execution

p_Jstar activated. Press START in AUTO

Print after MOVEFLY TO P1 10053
Print after MOVEFLY TO P5 10056
14:59:39.138 28717/02 HOLD from PDL2 statement
Print inside condition At END MOVEFLY TO p5 time 31421
Print after MOVEFLY TO P12 31426
Print after MOVEFLY TO P1 31830
Print after MOVEFLY TO P5 33722
print inside condition At END MOVEFLY TO p12 time 34557
14:59:50.896 28717/02 HOLD from PDL2 statement

Note that:
– the execution cursor is 7 motion statements ahead (or $ADVANCE current value)
compared to the motion cursor (the WRITE statement is not part of the 7
statements ahead, because the total amount of statements specified by
$ADVANCE only includes motion statements)
– all the non-motion statements included between the motion cursor and the
execution cursor, have already been executed (the WRITE statement in line 86 too,
even if the motion statement in line 85 has not been processed yet)
– all the motion statements included between the two cursors, are loaded into
memory and displayed in the page by means of IDE -> Details -> View motions
of program command (figure above, on the right)
– routine ru_print(5), inserted in CONDITION[5], is executed when Motion Event AT
END triggers for MOVEFLY TO P5 statement; TIMER[1] value is displayed in order
to point out the time difference between the two yellow highlighted lines
– the HOLD statement too, inserted in CONDITION[1], is executed when Motion
Event AT END triggers for MOVEFLY TO P1; if it had been inserted between the
lines, like the WRITE statement, it would have been processed before, not
synchronized with the execution of the previous movement, but rather at the
Interpreter execution cursor passage.

93
Comau Robotics Product Instruction

MOTION CONTROL

5.11 Remote Tool System

Remote 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
Configure-Save command in the Teach Pendant Setup page.
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.11 - Remote Tool System on page 94).

Fig. 5.11 - Remote Tool System

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

In the 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.

94
 Comau Robotics Product Instruction

MOTION CONTROL

5.12 Integrated Movement

When 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 Reference 2. Robot Base 3. User Reference 4. World Reference

5.. Side View 6. Top View 7. Column rotation 8. Rotating Column
9. Column Base Reference 9. Robot Base 10. User Reference 11. World reference
12. Rotating Column 13. Column rotation 14. Slide

5.12.1 Integrated Axis

A robot can be mounted on an auxiliary axis in order to extend the work envelope. The
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.

95
Comau Robotics Product Instruction

MOTION CONTROL

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.

For the configuration parameters, see

Chap.16. - Use of Positioners managed by C5GPlus on page 239.

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

Fig. 5.12 - Base Reference System – integrated axes

1 - Rotating Arm Radius (R) 2 - Right-hand rotation of the Column

3 - Column Height (H) 4 - Left-hand rotation of the Column

5.12.1.3 Restrictions
Integrated movement of the slide/column and robot is possible in the following
conditions:

96
 Comau Robotics Product Instruction

MOTION CONTROL

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

97
Comau Robotics Product Instruction

MOTION CONTROL

98
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

6. MOTION CONTROL WITHOUT EMOTION

6.1 Overview
This chapter contains the description of the C5GPlus Control Unit motion environment,
WITHOUT eMotion Trajectory Control.
Neither the manual motion (Teach Pendant jog keys) which is described in Chap.4. -
Robot motion in Programming mode on page 36, nor the options that are dealt with
further on in other chapters of this manual, are included in the current chapter.
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 (positioning accuracy)
– Process Resume
– Continuous Motion
– Remote Tool System;
– Integrated Movement.
Current chapter contains many references to predefined variables and instructions of
PDL2 language. For further information, refer to PDL2 Programming Language
Manual.

6.2 Frames of Reference

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

99
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

6.2.1 System Frame of Reference

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

World Frame The factory plant frame of reference with respect to which all
machines are positioned
Base Frame The frame located on the robot base
User Frame The frame located on the workpiece
Flange Frame The frame located on the robot flange
TCP Frame The frame located on the tool top

The $TOOL variable describes the position of the TCP frame with respect to the flange
frame; the $BASE coordinate transformation describes the position of the base frame
with respect to the world frame; the $UFRAME transformation describes the position of
the workpiece with respect to the world. The POS transformation represents the taught
point P that will be reached by the TCP during the execution of the program. Note that
all the taught POSITIONs are defined with respect to the user frame of reference
(defined by $UFRAME).
To better understand, suppose that the corner of the room is the world frame, and a
robot is located beside a table as shown in the following picture Fig. 6.1 - System
Frames of Reference and Coordinates Transformation on page 100.

Fig. 6.1 - System Frames of Reference and Coordinates Transformation

1 - Flange frame 2 - Tool frame 3 - Recorded position

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

100
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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

6.2.2 Base Reference System definition

$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.
$BASE value can be left to zero, anyway it is needed to properly set it up in case of
Cooperative Motion (optional feature).
In case of any axes group configured as a positioner, both if they are auxiliary axes and
axes being part of an individual ARM, a tool is available on the Teach Pendant, Setup
page, Motion - Frames environment, allowing the positioner BASE guided calculation;
please refer to par. 12.5 BASE automatic calculation for positioners on page 618 in
C5GPlus Control Unit Use manual for detailed information.

6.2.3 Flange Tooling definition

Cartesian motions (straight lines for example) are defined for the TCP (tool center 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:
– 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.

101
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

6.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. 6.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. 6.2 - Known position

6.2.3.2 Calculating the Rotation Angles

Rotation values are independent from offset values and must be calculated after the

102
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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.

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

103
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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

104
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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

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

6.2.3.3 User Reference System 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 off-line
programming.
To properly compute $UFRAME value, POS_FRAME built-in can be used as follows
(the program should be executed within a programming environment):

PROGRAM setframe
VAR corner, x, xy : POSITION
BEGIN
$UFRAME := POS(0,0,0,0,0,0,’’)
$TOOL := ... -- properly defined
-- Jog the TCP onto 3 points on the workpiece and teach
-- corner POSITION, x and xy POSITIONs pressing the MOD key
-- on the TP.
-- Then execute the following statement.
$UFRAME := POS_FRAME(corner, x, xy)
END setframe
As an alternative, a tool is available on the Teach Pendant, Setup page, Motion - Frames
environment, allowing the UFRAME guided calculation; please refer to par. 12.4
UFRAME automatic calculation on page 609 in C5GPlus Control Unit Use manual for
detailed information.

105
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

6.3 Trajectory
It represents an Arm motion from an initial position to a final position.
The motion trajectory between two taught positions is generated by interpolating various
sets of variables from their initial values at the start position to their final values at the
destination position. The predefined variable $MOVE_TYPE indicates the type of
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.

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

6.3.2 Cartesian Interpolation

In case of Cartesian Interpolation, $MOVE_TYPE can be either LINEAR or CIRCULAR.
Below, in the current paragraph, the following topics are described:
– Linear Interpolation
– Circular Interpolation
– Orientation Evolution
– Attitude Flags
– Turn Flag and minimum path.

6.3.2.1 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 par. 6.3.2.3 Orientation Evolution on page 107.

106
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

6.3.2.2 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 required
attitude evolution type.

6.3.2.3 Orientation Evolution

The tool orientation during linear and circular movements evolves from the initial
position to the final position according to the modality indicated by $ORNT_TYPE
variable. Allowed values for this specific program variable are as follows:
– RS_WORLD (two angles related to the world frame)
The orientation evolution is done by linearly interpolating the values of two angles,
tool sliding angle and tool spin angle. The tool sliding angle is the angle around the
common perpendicular between the beginning approach vector and the final
approach vector. The tool spin angle is the angle around the approach vector, from
the start 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.
– RS_TRAJ (two angles related to the trajectory)
Orientation interpolation is done in the same way than RS_WORLD but the sliding
and spin angles are referred to the trajectory. This is particularly useful during
circular trajectory having a center angle grater than 180 degrees when the tool
orientation must be kept constant referred to the trajectory. During linear motions
the orientation evolution is the same than RS_WORLD.
– EUL_WORLD (three angles)
The orientation interpolation is done by linearly interpolating the values of the three
Euler rotation angles, E1, E2, and E3.
– WRIST_JNT (wrist joint)
The orientation interpolation is done by using a combination of both joint and linear
interpolation. This allows 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 repeatable. For example, using either
EUL_WORLD or RS_WORLD, if the beginning and ending orientations are the
same, the tool orientation remains fixed during while moving. Using WRIS_JNT
orientation interpolation this is not guaranteed. However, thanks to this orientation
control, smoother motion can be obtained near wrist singularities.

6.3.2.4 Attitude Flags

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

107
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

– S flag (see next figure) indicates that the WCP (Wrist Center Point) is currently in
the area behind the plane passing through axis 1 and parallel to axis 2. The behind
area is the opposite space to the one including axis 2;

– E flag (next figure) indicates that the WCP (Wrist Center Point) is currently in the
area behind the plane including the 2nd link (i.e. generally including axes 2 and 3);

– W flag (see next figure) indicates that the value of axis 5 is negative.

108
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

The only exception is when passing through a singularity point, in which the W flag is
reversed by the system software.
It is, however, allowed to move even if the flags do not match: set $CNFG_CARE
predefined variable to FALSE so that the flag of the final point is assumed to be the one
of the starting point.
This setting is mainly used when mixing movements that use JOINTPOS type variables
and POSITION type variables whose values have been directly set from 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 setting $CNFG_CARE variable to FALSE.

6.3.2.5 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-turn movements, i.e. they can rotate by more than 360
degrees ($STRK_END_P[axis] - $STRK_END_N[axis] > 360) (for further details see the
PDL2 Programming Language Manual).
A Cartesian trajectory (LINEAR or CIRCULAR) generally follows the shortest path for
the joints so the configuration string of the reached final point may differ from the one
specified in the motion instruction. If so, the system will perform the movement in any
case, unless $TURN_CARE predefined variable is set to TRUE; in such a case, an error
message will indicate the difference in the number of turns.
POSITION type variables that were taught using a certain $UFRAME may have a
different number of turns when $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

109
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

turn flag in P1 configuration string and therefore, in order to avoid an error in MOVE
LINEAR 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,
performed on points declared as POSITIONs, sets a path that follows the joints
evolution, without taking into consideration the shortest or longest route. To follow the
shortest route (<180 degrees), set $JNT_MTURN variable to FALSE.
Note that $JNT_MTURN variable is ineffective in joint movements on points declared as
JOINTPOS.

NOTE THAT in the following situations

– Spot Welding application with ServoGun,
– any sensor/mechanism performing real-time modification of POSITIONs
(e.g. vision systems for robot guiding, SBCU type sensors for TCP modification,
etc.),
it is STRONGLY RECOMMENDED to insert the following statement at the beginning of
the User PDL2 Program:
$jnt_mturn := FALSE

6.4 Position Checking

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

6.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
in millimeters in relation to the flange ($ARM_DATA[arm].OT_TOL_DIST) and the
threshold in degrees in relation to the flange orientation
($ARM_DATA[arm].OT_TOL_ORNT). In case of a very long tool (for instance, 1 meter
in the tool 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
cause 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_DIST is used.
If the arm includes integrated auxiliary axes, in case of jog movements in joint mode, all

110
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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.
Anyway, 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_JNT
or
MOVE 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 following
Tab. 6.1 - On Pos and On Trajectory on page 112.
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 interrupting the execution of a NON motion instruction of a program open in an

editing environment, $CRNT_DATA[arm].OT_COARSE flag will still be set to TRUE
even if the interrupted statement is between two FLY movements. If the user then moves
the cursor to a specific statement from which going on with the program execution,
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 is up to the user in charge of operating and
controlling the cell.

For further details related to the $OT_xxx system variables and the ON_TRAJ_SET
built-in routine, please refer to PDL2 Programming Language Manual.

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

111
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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

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

Tab. 6.1 - On Pos and On Trajectory

On Trajectory On Pos with JOINTPOS On Pos with POSITION
($OP_JNT) ($OP_POS)
Value of: Value of: Value of:
$CRNT_DATA[ ].OT_COARSE $ON_POS_TBL[ ].OP_REACHED $ON_POS_TBL[ ].OP_REACHED
Initial condition TRUE TRUE TRUE
Movement of robot FALSE FALSE FALSE
axis in joint mode
Movement of FALSE FALSE FALSE
integrated auxiliary
axis in joint mode
Movement of FALSE FALSE TRUE
non-integrated
auxiliary axis in joint
mode

112
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

Tab. 6.1 - On Pos and On Trajectory (Continued)

Movement in FALSE FALSE FALSE
Cartesian mode with
reference to X, Y, Z
and/or E1, E2, E3
Movement in FALSE FALSE TRUE
Cartesian mode of
integrated auxiliary
axis
Deactivation of FALSE TRUE TRUE
movement program

6.5 Speed Control

Predefined variables are used to control the maximum or constant speed of a motion,
some of which are system-wide, some are program-specific, and some are arm-specific.
Two kinds of speed controls are used:
– absolute speed values, measured in speed units such as radians per second or
meters per second;
– override values (percentages) that control the speed values planned by the
system.
Not only speed can be controlled by the user, but also acceleration and deceleration;
override values for acceleration and deceleration are described in par. 6.6 Acceleration
and Deceleration on page 118 in current chapter.

6.5.1 Speed Overrides

The speed overrides (percentage speed values) that apply to all motions are as follows:
– $GEN_OVR allows the operator to simultaneously change 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.
$GEN_OVR is an INTEGER type variable
It is common to the whole system and can be changed from the Teach Pendant.
The PDL2 programs can only read it .
$ARM_OVR allows acceleration, speed, and deceleration of a specific arm to be
modified. Since it affects acceleration, speed, and deceleration in a coordinated
way, trajectory shapes are generally maintained when this variable is modified
(except for differences in servo following errors at different values of override).
$ARM_OVR is an INTEGER field of the system-wide matrix of elements,
$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. 6.10.1 Trajectory Shape During Continuous Motion on page 128
in current chapter.

113
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

– $ARM_SPD_OVR allows the speed of a specific arm to be modified. 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. 6.10.1 Trajectory Shape During Continuous Motion on page 128
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. 6.10.1 Trajectory Shape During Continuous Motion on
page 128 section 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.

6.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.
– $LIN_SPD_LIM determines the linear speed limit. 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;

114
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

– 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 motion component 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. 6.5.1 Speed Overrides on page 113 for a definition of “total speed override”).

6.5.2.1 Cartesian Speed Control Options

The process of determining which component will control the Cartesian speed is called
preplanning and and it is performed immediately before the actual motion execution (i.e.
before each MOVE). The preplanner can be forced to use a specific motion component
by means of $SPD_OPT predefined variable. 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 a
speed of maximum stress (SMS) determined by the preplanner.
– 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,
$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).

115
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

– 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.
Se il valore della $SPD_OPT non ha alcun significato riferito all’attuale tipo di traiettoria,
viene assunto per default il valore SPD_CONST. Ad esempio,
$SPD_OPT=SPD_SECOND non ha alcun significato se $ORNT_TYPE=RS_WORLD,
quindi verrà utilizzata SPD_CONST.
Le modifiche a $SPD_OPT, $LIN_SPD e $ROT_SPD diverranno effettive solo all’inizio
del movimento successivo. Le modifiche non hanno alcun effetto sul movimento attuale
dell’arm.

If $SPD_OPT value is not meaningful for the current trajectory type, the default
SPD_CONST value 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 effect at the beginning
of the next movement. Changes do not affect the arm current motion.

A functionality is available, in special conditions, allowing to Run-Time modify the

speed (see next paragraph Run-Time modifying the Linear Speed Override)

116
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

6.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:
– the movement is CARTESIAN
– 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 set to the motion, and indicates, as a
percentage, the new speed to be used since the current motion.
The default value is 100: this means that the movement is performed at a maximum
speed, i.e. the $LIN_SPD. The maximum value $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.

For run-time linear speed variations during synchronized motions, please see Chap.7. -
Synchronous Motion (optional feature) on page 139 in current manual.

6.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 $ARM_DATA[] global predefined structures array.
Thus there is a value for each axis for each arm.
The speed override for each joint is determined by $JNT_OVR, which allows
acceleration, speed, and deceleration to be modified together by a program.
It is a field of $ARM_DATA and it is an INTEGER structures array.
There is an override value for each axis of each arm. The default values is 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.

117
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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.

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

6.6 Acceleration and Deceleration

Acceleration and deceleration in C5GPlus Control Unit are composed by three phases:
an increasing jerk phase, followed by a constant acceleration phase (which could also
not be present), followed by another decreasing jerk phase.
See Fig. 6.3 - Speed and acceleration profiles on page 118.

Fig. 6.3 - Speed and acceleration profiles

1. speed
2. acceleration

Currently, C5GPlus 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
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;

118
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

– $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 in
order to coordinate acceleration/deceleration values.
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.

6.6.1 Acceleration/Deceleration Overrides

As with speed, acceleration and deceleration also have overrides.
As already explained in par. 6.5.1 Speed Overrides on page 113,
$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 allows 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 allows 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 allows 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 allows 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] =
$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*

119
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

$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, 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.

Quick E-STOP
The code option is CR17926224.
Upon pressing the Emergency Stop Button, this option causes the deceleration time to
be reduced with respect to the standard deceleration time, with a greater stress for
mechanical components.

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

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

120
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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

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

6.7 Motion termination (positioning accuracy)

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

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

121
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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

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

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

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

122
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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.

6.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
a predefined variable array of joint tolerances, $TOL_JNT[]. The short range reset takes
place by means of a move in joints interpolation that is entirely transparent to the user.
That is, when START button is pressed to resume a motion, a short range recovery
motion will be inserted immediately before the original motion is resumed. In many
cases, this reset move is not even perceived by the operator.
If the distance between the current position and the nominal position is major to a certain
limit (short range) the resumption of motion takes place according to the modes defined
by the predefined variable $RCVR_TYPE value set. The possible values of this
predefined variable are shown in the following table:

0 Bring the arm to the interrupted trajectory position, by the joint interpolation.
1 Bring the arm to the movement start position that was interrupted by the joint interpolation.
2 Bring the arm to the interrupted movement destination position using the joint interpolation.
3 Do not reset, generate an error message.
4 If the interrupted movement was Cartesian, restore the interrupted trajectory by a straight-line
movement. Otherwise use joint interpolation .
5 If the interrupted movement was Cartesian, bring the arm back to the start position of the interrupted
movement by a straight-line interpolation. Otherwise use joint interpolation .
6 If the interrupted movement was Cartesian, bring the arm to the interrupted movement destination
position by a straight-line interpolation. Otherwise use joint interpolation .
7-8 reserved

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.

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

6.8.1.2 Recovery Range

In Programming mode the same strategy is used as for the Automatic status. If the

123
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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.

6.8.1.3 Recovery procedure

If the System executes the recovery procedure, by issuing the corresponding messages
“Trajectory recovery in progress” and “Recovery position reached”, it is needed to
double press the START button.
On the contrary, if no messages are issued, just one pressure is required for the START
button.

6.9 Process Resume

The 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. 6.7 - Return Movements - example D on page 126) or upon exhaustion of the
movement preceding the one in progress (Fig. 6.5 - Return Movements - example B on
page 125 and Fig. 6.6 - Return Movements - example C on page 125).

124
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

Fig. 6.4 - Return Movements - example A

Simplest situation.
1. Programmed Fly position, between two movements 2. First movement - fly termination
3. Second movement - fly beginning 4. Second movement - fly termination
5. Stop position 6. Motion direction
7. First movement – fly beginning

Fig. 6.5 - Return Movements - example B

$RCVR_DIST programmed value is greater than the maximum recoverable one

1. Maximum recoverable distance
2. Stop position

Fig. 6.6 - Return Movements - example C

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

1. Stop position 2. Maximum recoverable distance

125
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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

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. 6.8 - Example in case of $RCVR_DIST modification on page 126).

Fig. 6.8 - Example in case of $RCVR_DIST modification

1. Stop position of the return movement 2. First value of $RCVR_DIST=20 mm

3. Return movement interruption: $RCVR_DIST is read again
4. $RCVR_DIST=30 mm after the modification 5. 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

126
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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

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

1. motion direction 2. trajectory 3. calculated return movement

4. $RCVR_DIST 5. decelerate distance 6. motion stop command
7. actual motion stop position

6.10 Continuous Motion

The 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 statement, the arm will not stop at the first
destination: it will move from the starting position to the final position of the second
movement, without stopping on the common position of the two movements.

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

1. Motion start towards c 2. Motion end towards b Segment 1-2 : FLY connection segment

127
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

In this modality, i.e. without eMotion Trajectory Control, it is strongly discouraged to

connect Joint and Cartesian trajectories in FLY.

CAUTION
$TOOL predefined variable cannot be modified during cartesian fly movement (neither
liner nor circular).
If this happens, the following error would occur:
37130 "$TOOL changed during fly"

6.10.1 Trajectory Shape During Continuous Motion

Fig. 6.9 - Example of continuous motion in case of linear movement on page 127 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.

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

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

128
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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
be achieved by using FLY_CART (see below).

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

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

129
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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. 6.10 for a graphical display of such situations.

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

6.10.2.2.2 Keeping Constant Speed

As already described, FLY_CART allows the TCP speed to be kept 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.

130
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

6.10.2.2.3 Trajectory Control During FLY

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.

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

• 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. 6.11 - FLY Movements

The above picture (Fig. 6.11 - FLY Movements on page 131) shows an example of the
use of these system settings. With $FLY_DIST set equal to 20 mm, the following results

131
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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.

6.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_cart
CONST
arm_num = 1
cond_num = 1
ROUTINE print_debug
BEGIN
WRITE ($CRNT_DATA[arm_num].FLY_DBUG, NL)
END print_debug
BEGIN
$CRNT_DATA[arm_num].FLY_DBUG := 0
CONDITION[cond_num] NODISABLE :
WHEN AT END DO
print_debug
ENDCONDITION
-- initialization
ENABLE CONDITION[cond_num]
-- move statements
END mov_cart

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

132
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

Tab. 6.2 - FLY_DBUG field codes for $CRNT_DATA variable (Continued)

Code Description
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.

6.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
– $FLY_TRAJ values: FLY_AUTO, FLY_TOL, FLY_PASS, FLY_FROM

133
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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

$FLY_AUTO.

134
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

6.11 Remote Tool System

Remote 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
Configure command in the Teach Pendant Setup page.
Note that, with remote tool enabled, the workpiece frame is now defined with respect to
the robot flange by means of $UFRAME, whereas $TOOL represents the position of the
remote TCP with respect to the world frame (Fig. 6.12 - Remote Tool System on
page 135).

Fig. 6.12 - Remote Tool System

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

In the 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.

135
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

6.12 Integrated Movement

When 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 Reference 2. Robot Base 3. User Reference 4. World Reference

5.. Side View 6. Top View 7. Column rotation 8. Rotating Column
9. Column Base Reference 9. Robot Base 10. User Reference 11. World reference
12. Rotating Column 13. Column rotation 14. Slide

6.12.1 Integrated Axis

A robot can be mounted on an auxiliary axis in order to extend the work envelope. The
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

136
 Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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.

For the configuration parameters, see

Chap.16. - Use of Positioners managed by C5GPlus on page 239.

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

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

Fig. 6.13 - Base Reference System – integrated axes

1 - Rotating Arm Radius (R) 2 - Right-hand rotation of the Column

3 - Column Height (H) 4 - Left-hand rotation of the Column

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

137
Comau Robotics Product Instruction

MOTION CONTROL WITHOUT EMOTION

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

138
 Comau Robotics Product Instruction

SYNCHRONOUS MOTION (OPTIONAL FEATURE)

7. SYNCHRONOUS MOTION (OPTIONAL

FEATURE)

Synchronized Arms
The option code is CR17926204.

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.

139
Comau Robotics Product Instruction

SYNCHRONOUS MOTION (OPTIONAL FEATURE)

7.1 Synchronization with Auxiliary Axes

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

140
 Comau Robotics Product Instruction

SYNCHRONOUS MOTION (OPTIONAL FEATURE)

7.2 Synchronized Arms

This feature is not supported by systems with eMotion Trajectory Control.

The user is notified by means of a suitable message.

– Motion limitations of the two Arms

– Jogging Synchronized Arms
– Teaching and Modifying Positions (REC/MOD) with Synchronized Arms
– Loss of Synchronization
– Run-time modifying the Linear Speed Override.
The 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 workcell with two arms carrying a single
workpiece. In addition this feature is necessary for cooperative motion (see par. 8.1
Cooperative Motion with Auxiliary Axes on page 147).
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

the MASTER Arm is ARM[2] and the SERVER Arm is ARM[1].

s

If a SYNCMOVE is executed with enabled cooperative movement between Arms (either

ARM_COOP or ARM_MCOOP), the Arms order is important and it is not equivalent: the
MASTER Arm must be the WORKER Arm, whereas the SERVER Arm must be the
POSITIONER Arm; note that the POSITIONER Arm is either the actual positioner Arm
(in case of ARM_COOP) or the owning Arm of the auxiliary axes which act as positioner
in case of ARM_MCOOP.
Please refer to par. 8.3 Multi-cooperative motion on page 149 for further details about
Arm Positioner and Arm Worker concepts.

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

141
Comau Robotics Product Instruction

SYNCHRONOUS MOTION (OPTIONAL FEATURE)

$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 example
VAR P1, P2 : POSITION
BEGIN
-- the main arm is arm 1, the synchronised arm
-- is arm 2
MOVE ARM[1] TO p1 SYNCMOVE ARM[2] TO p2
MOVE TO p1 SYNCMOVE ARM[2] to p2
-- $PROG_ARM moves on p1
MOVE ARM[1] TO p1 SYNCMOVE TO p2
-- ERROR: $SYNC_ARM is not initialised
$SYNC_ARM := 2 -- $SYNC_ARM is initialised
MOVE ARM[1] TO p1 SYNCMOVE TO p2
-- $SYNC_ARM (arm 2) moves on p2
MOVE TO p1 SYNCMOVE TO p2
-- $PROG_ARM and $SYNC_ARMEND are used, example
The ADVANCE clause is applied to the entire MOVE... SYNCMOVE. To perform a fly it
is necessary to specify the FLY clause on the main move and insert ADVANCE before
SYNCMOVE:

MOVEFLY TO p1 ADVANCE,
SYNCMOVEFLY ARM[2] TO p2,
ENDMOVE
If an ADVANCE is inserted after p2, the translator sees a warning message and
automatically corrects instruction.

7.2.1 Motion limitations of the two Arms

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

MASTER Arm trajectory $SPD_OPT value Limiting arm

Arm with more restrictive

Joints or Cartesian SPD_JNT or SPD_CONST
parameters
different to SPD_JNT and to
Cartesian MASTER Arm
SPD_CONST

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

142
 Comau Robotics Product Instruction

SYNCHRONOUS MOTION (OPTIONAL FEATURE)

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

7.2.2 Jogging Synchronized Arms

In 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 C5GPlus Control Unit Use - Chap.5. - TP5 Teach Pendant on page 52 - Right
Menu.

7.2.3 Teaching and Modifying Positions (REC/MOD) with

Synchronized Arms
Enabling and disabling SYNCMOVE teaching are selected through IDE Page, REC key.
For any further information about SYNCMOVE teaching, please refer to par. 5.12.3.6.1
REC setup on page 166.
Tab. 7.1 - Teach examples (REC key) on page 143 shows some teach examples.

Tab. 7.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"

For further information, please refer to C5GPlus Control Unit Use manual, IDE Page
chapter.

7.2.4 Loss of Synchronization

The 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

143
Comau Robotics Product Instruction

SYNCHRONOUS MOTION (OPTIONAL FEATURE)

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

7.2.5 Run-time modifying the Linear Speed Override

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

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

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:

144
 Comau Robotics Product Instruction

SYNCHRONOUS MOTION (OPTIONAL FEATURE)

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

145
Comau Robotics Product Instruction

COOPERATIVE MOTION (OPTIONAL FEATURE)

8. COOPERATIVE MOTION (OPTIONAL

FEATURE)

Cooperative Motion
The option code is CR17926200.

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. 8.1
- System frames with auxiliary axes cooperative motion on page 147 and Fig. 8.2 - User
frame with auxiliary axes cooperative motion on page 148). 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.

146
 Comau Robotics Product Instruction

COOPERATIVE MOTION (OPTIONAL FEATURE)

8.1 Cooperative Motion with Auxiliary Axes

If 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.
To enable and disable cooperative motion, the following built-in procedure is available:

AUX_COOP(flag, joint_aux <, arm_num>)

Flag is a boolean parameter. It can be set to ON or OFF, respectively to enable/disable
the cooperative motion.
joint_aux parameter is the number of the last axis composing a positioner.
arm_num parameter is the arm on which the 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 cooperative motion with the first

-- positioner
AUX_COOP(ON, 8) -- disables previous cooperative motion and
-- enables cooperative motion with the second
-- positioner
AUX_COOP(OFF) -- disables cooperative motion

Fig. 8.1 - System frames with auxiliary axes cooperative motion

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

147
Comau Robotics Product Instruction

COOPERATIVE MOTION (OPTIONAL FEATURE)

Fig. 8.2 - User frame with auxiliary axes cooperative motion

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

8.2 Cooperative Arms

The cooperative motion between two arms of the same work cell controlled by the
C5GPlus can 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 <<, positioner_arm <<, working_arm>>>>)

flag is a boolean parameter which can be set to ON or OFF, respectively to enable and
disable the cooperative motion.
positioner_arm parameter is optional and specifies the positioner arm. If the positioner
arm is not specified, the value of $SYNC_ARM predefined variable is assumed.
working_arm parameter is optional and specifies the working arm. If the working arm is
not specified, the value of $PROG_ARM predefined variable is assumed.
Cooperation can be performed independently from the arms synchronization by simply
enabling it and moving the positioner and the working arms. However from the
programming point of view, synchronization is suggested.

Fig. 8.3 - System frames with cooperative Arms

1. 1 - Working Arm 2 - Positioner Arm

148
 Comau Robotics Product Instruction

COOPERATIVE MOTION (OPTIONAL FEATURE)

Fig. 8.3 - System frames with cooperative Arms on page 148 shows the different
reference frames for the two arms definition. The positioner (arm 2) moves its TCP
(defined by $ARM_DATA[2].TOOL) referred to its user frame
($ARM_DATA[2].UFRAME), while the working arm TCP ($ARM_DATA[1].TOOL)
moves referred to a reference frame used by the positioner TCP (by means of
$ARM_DATA[1].UFRAME).

8.3 Multi-cooperative motion

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.
For further information, please refer to PDL2 Programming Language manual,
chap.BUILT-IN Routines List.

Fig. 8.4 - System frames with multi-cooperation

1. Working Arm
2. Positioner Arm

149
Comau Robotics Product Instruction

COOPERATIVE MOTION (OPTIONAL FEATURE)

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

This optional functionality needs the following software option: Cooperative Motion - see
Chap. Appendix - Software Options on page 665 in C5GPlus Control Unit Use manual.

8.4 Jogging
Cooperative motion provides easy programming for while jogging the positioner arm, the
working one follows the positioner in order to keep constant the torch position (location
and orientation) with respect to the workpiece. This feature simplifies the programming
of complex trajectories, saving time and reducing the number of points that must be
taught.
The cooperation during jog must be enabled with the ARM_COOP (for cooperative
arms), AUX_COOP (for auxiliary axes cooperation) and ARM_COOP (for
multi-cooperation) built-in procedures. They can be executed by a program, or by the
Teach Pendant in IDE Page, command Program - Immediate execution or in Service
Page, command System - Execute.

150
 Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

9. SENSOR TRACKING (OPTIONAL FEATURE)

Sensor Tracking Motion

The option code is CR17926205.

The Sensor Tracking environment allows real-time adjustments 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 C5GPlus, 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 C5GPlus 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

9.1 Principle of operation

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

151
Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

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
that is different to that programmed. Let us suppose that the program consists of a joints
move on a start position, followed by two linear moves linked in fly and a final joints move
to reach a position out of range.
The program could be the following:

PROGRAM sensor
VAR
p1, p2, p3, p4 : POSITION
BEGIN
$SPD_OPT:=SPD_LIN--To check the linear speed
$LIN_SPD:=0.1 --Linear speed in m/s
MOVE JOINT TO p1
MOVEFLY LINEAR TO p2 ADVANCE
MOVE LINEAR TO p3
MOVE JOINT TO p4
END sensor
If the sensor is enabled along the Cartesian path from p1 to p3, the effect could be as
shown in Fig. 9.1 - Programmed trajectory and sensors control on page 152 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. 9.1 - Programmed trajectory and sensors control

1. Starting point
2. Arrival point
3. Programmed trajectory
4. Trajectory controlled by sensor

152
 Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

9.2 Configuration on several arms

C5GPlus 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. 9.1 - System variables for Sensor Tracking
on page 153; ; 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 Configure - Save, Setup page on the TP, they are saved in
'file.C5GPlus' with their current value Tab. 9.2 - Built-In for Sensor Tracking on
page 153 summarizes the built-ins for sensors management.

Tab. 9.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. 9.2 - Built-In for Sensor Tracking

SENSOR_SET_DATA ( err_track <,arm_num> )
SENSOR_GET_DATA ( sens_read <,flag <,arm_num>> )
SENSOR_GET_OFST ( ofst_tot <,arm_num> )
SENSOR_TRK ( bool <,arm_num> )
Where:
– errp_track, sens_read, ofst_tot are ARRAY[6] OF
REAL
– flag is an INTEGER value in read
– arm_num is INTEGER type

9.3 Sensor interface

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

153
Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

9.3.1 Integrated Sensors

Some sensors are pre-set for integration into the Control Unit hardware. These devices
are integrated sensors if the communication between sensor and Control Unit 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.
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. 9.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_num>> )

This copies the six components of the array coming from the sensor into 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 of zero. The optional flag parameter is set to 1 if the data is new i.e. it has
never been read by a previous SENSOR_GET_DATA built-in routine. Otherwise it is set
to 0. The optional arm_num parameter selects the data relating to an arm that is not the
default one.

9.3.2 External sensors

External sensors are those which are not integrated in the Control Unit Hardware.
Examples of this type of sensors are:
– simple stroke-end switches or binary proximity sensors that give a single digital
datum (they change the signal when the measured distance 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 Unit by a communication line managed by a
PDL2 program. The two-three dimension video cameras may belong to this
category since they usually have a dedicated controller, that performs calculations
needed to interpret the image, and a communication line to receive commands and
transmit information.
The main feature of such sensors is that information reading is performed by a PDL2
program (usually NOHOLD), dedicated to the sensor.
$SENSOR_TYPE values, reserved to this type of sensor are between 5 and 12 (see
Tab. 9.3 - Correction_Speed = Factor*Reference_Speed on page 160). The following
built-in routine is provided in order to send the correction request to the motion
environment:

SENSOR_SET_DATA ( err_track <, arm_num> )

154
 Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

err_track parameter is the required corrections array, whose the first three elements
correspond to translations in X, Y and Z directions, whereas the others are rotations
around such axes.
Unused err_track components should anyway be initialized to zero.
arm_num optional parameter allows sending corrections to a different arm than the
default one. Note that SENSOR_GET_DATA Built-In routine, described in the previous
section, can also be used with this sensors type. In this case, sens_read parameter will
contain the same data as sent by means of SENSOR_SET_DATA.

9.4 Sensor reference system

The sensors measure the deviations in relation to a reference system that depends on
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 .

9.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. 9.3 - Correction_Speed
= Factor*Reference_Speed on page 160).
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. 9.2 - Tool frame conversion on page 155).

Fig. 9.2 - Tool frame conversion

1 - Flange 2 - Tool
3 - Sensor 4 - Sensor frame
5 - TCP frame

155
Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

9.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. 9.3 - Correction_Speed = Factor*Reference_Speed on page 160).
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. 9.3 - User frame
conversion on page 156).

Fig. 9.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.

9.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. 9.3 - Correction_Speed = Factor*Reference_Speed on
page 160).

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

156
 Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

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. 9.3
- Correction_Speed = Factor*Reference_Speed on page 160).

9.5 Type of information acquired by the sensor

The 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
C5GPlus automatically converts the data read by the sensor (for example ampere,
Newton, etc.) to corrections in millimetres through the $SENSOR_CNVRSN system
variable. This is 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).

9.6 Correction actuation criteria

There 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

9.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. 9.4 - Absolute
deviations on page 158). The term RELATIVE deviations means a correction that is

157
Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

made with reference to the current robot position, i.e. without taking into consideration
the error already accumulated during previous sensor readings (Fig. 9.5 - Relative
deviation on page 158).

Fig. 9.4 - Absolute deviations

1. Programmed trajectory 2. Trajectory controlled by sensor

3. Correction required = +3 mm 4. Required = +1 mm
5. Required = -2 mm 6. Final deviation = 0 mm
7. Required = 0 mm

Fig. 9.5 - Relative deviation

1. Programmed trajectory 2. Trajectory controlled by sensor

3. Correction required = +3 mm 4. Required = +1 mm
5. Required = -2 mm 6. Final deviation = 0 mm
7. Required = 0 mm

For integrated sensors the choice between the two modes (absolute or relative)
depends on the type of sensor, and it is managed by system software. For external
sensors there is a possibility to choose by means of the $SENSOR_TYPE system
variable: the values from 5 to 9 enable the relative mode functioning, whereas from 9 to
12 enable absolute mode (Tab. 9.3 - Correction_Speed = Factor*Reference_Speed on
page 160).
– 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. 9.4 - Absolute
deviations on page 158);

158
 Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

– 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. 9.5
- Relative deviation on page 158).

9.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;
– 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. 9.6 - Effects of $SENSOR_TIME (with
relative corrections) on page 159 illustrates the effect of the two different criteria.

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

1. Programmed trajectory 2. Trajectory controlled by sensor

159
Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

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
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. 9.3 - Correction_Speed = Factor*Reference_Speed on page 160 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 .

Tab. 9.3 - Correction_Speed = Factor*Reference_Speed

$SENSOR_GAIN[ i ] Factor
0 0.0
10 0.11
20 0.25
30 0.43
40 0.67
50 1.0
60 1.5
70 2.3
80 4.0
90 9.0
100 infinite

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. 9.7 - Effects of $SENSOR_GAIN on page 161). To avoid all types of limitation the
corresponding $SENSOR_GAIN value can be set at 100%.

160
 Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

Fig. 9.7 - Effects of $SENSOR_GAIN

1. Programmed trajectory 2. Trajectory controlled by sensor

3. Maximum speed 4. Time increase

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.

9.6.3 Overall deviations control

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

SENSOR_GET_OFST ( ofst_tot <, arm_num> )

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_num parameter can be used to read the data of an arm that is not the default one.
This deviation array 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.

9.7 Sensor tracking enable mode

The 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. 9.9 Accumulative
overall deviations management on page 165”).
The standard enable mode of sensor tracking permits the application of corrections read

161
Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

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.
C5GPlus 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 C5GPlus in compliance with safety requirements. In
particular 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_TRK ( bool <, arm_num> )

The execution of the SENSOR_TRK(TRUE) instruction selects a certain option so that,
enabling the sensor tracking by means of $SENSOR_ENBL variable, the arm is in an
extended mode that allows tracking even without a programmed motion.
arm_num optional 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 tracking without a programmed motion is depends on the

value of $SENSOR_ENBL (however, it is not necessary to call
SENSOR_TRK(TRUE) again, 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 Execute command of Service Page - System on the TP, nor
by SYS_CALL of EXECUTE command;

c. the service disabling through SENSOR_TRK(FALSE) can be executed only from

the same program that enabled it;

162
 Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

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. 9.9 Accumulative overall deviations
management on page 165).

9.8 Sensor malfunctioning

There 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
– Redefinition of overall deviations

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

9.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. 9.8 - Effect of $RCVR_TYPE = 7 on
page 164 shows the procedure.

163
Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

Fig. 9.8 - Effect of $RCVR_TYPE = 7

1. Programmed trajectory 2. Trajectory controlled by sensor

3. Trajectory after a sensor failure 4. Optimal trajectory
5. HOLD caused by an error message

Not only the translation deviations (first three components) are redefined, but also those
of geometry variations, therefore, if it is wished to resume the move with the same
geometry as when the stoppage took place, this must not be changed during the jog
session.
The $RCVR_TYPE=8 mode is useful in such cases and permits the move to be
resumed returning exactly on the programmed trajectory resetting the deviations
accumulated by the sensor; in this mode the C5GPlus plans a trajectory that recovers
the current position to correspond to the programmed trajectory and resume the
interrupted move.
After recovery, the deviations will be reset. Fig. 9.9 - Effect of $RCVR_TYPE = 8 on
page 164 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. 9.9 - Effect of $RCVR_TYPE = 8

1. Programmed trajectory 2. Trajectory controlled by sensor

3. Recovery trajectory 4. HOLD caused by an error message

164
 Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

9.9 Accumulative overall deviations management

In the par. 9.1 Principle of operation on page 151 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

9.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. 9.10 - Interrupted sensor
tracking session on page 165 with Fig. 9.1 - Programmed trajectory and sensors control
on page 152; the 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. 9.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. 9.1 - Programmed
trajectory and sensors control on page 152 can be noted notwithstanding that the fly and

165
Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

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

9.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. 9.11 - Suspended sensor tracking session on page 166
illustrates this operation.

Fig. 9.11 - Suspended sensor tracking session

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

9.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. 9.10 - Interrupted sensor tracking session on
page 165); 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. 9.12 - RESETTING
SPREAD during a Move on page 167.

166
 Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

Fig. 9.12 - RESETTING SPREAD during a Move

1. Programmed trajectory 2. Trajectory controlled by sensor 3. OFFSET RESET without interrupt

Tab. 9.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

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

167
Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

– 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. 9.9.1 Interrupted sensor tracking session on page 165).
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. 9.9.1 Interrupted sensor
tracking session on page 165).

9.10 Programming example

Below the program already given in the par. 9.1 Principle of operation on page 151 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 get_corr(corr_y,corr_z:REAL)
BEGIN
-- routine body
END get_corr

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 CONDITION[1]
END send_corr

BEGIN
CONDITION[1] :
WHEN $TIMER[1] > 500 DO
send_corr --Corrections sent every 500 ms
ENDCONDITION

168
 Comau Robotics Product Instruction

SENSOR TRACKING (OPTIONAL FEATURE)

corr[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

169
Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

10. CONVEYOR TRACKING

(OPTIONAL FEATURE)

Conveyor Tracking
The option code is CR17926206.

The Conveyor Tracking environment allows the user to write simple programs for
reaching positions defined on a moving conveyor: the C5GPlus Controller automatically
compensates the istantaneous position of the conveyor.
In order to compute the instantaneous position of a conveyor, its motor has to be
equipped with a position transducer connected to C5GPlus Controller Unit.
Up to four conveyors can be handled. When the tracking is enabled, only cartesian
movements can be executed.
The following tracking is available:
– Cartesian Tracking - in this case the of cartesian tracking the robot is fixed and
the conveyor tracking is done using a dynamic conveyor frame (truck frame) that
will be shifted according to the position of the truck. In this way, it is possible to track
trucks mounted on traversing or rotating conveyors involving, in the first case linear
Cartesian tracking and, in the second, circular Cartesian tracking. They are no
restrictions regarding the placement and orientation of the conveyor. Since the
robot is fixed and the workpiece moves, the workspace is reduced (the robot can
work on the part for a very short time) so that the cartesian tracking is
recommended for pick and place applications.
This chapter describes the following subjects :
– Configuration
– Working Principle
– Process Monitoring
– Tracking Window
– Motion Statements
– Teaching Positions
– Tracking Interruption
– Limitations during Conveyor Tracking
– Use of the Roto-translating Conveyor

10.1 Configuration
Use IO_CNFG program (C5GPlus Control Unit Use manual - par. 11.1.2.1.5 System
on page 518), to configure conveyor tracking and define any associated kit to the
conveyor itself.
Then, enter the Conveyor subpage within Setup page on the Teach Pendant, to set the
basic parameters (par. 5.17.2.5 Conveyor on page 255) in C5GPlus Control Unit Use

170
 Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

manual).
System variables to configure the conveyor tracking are fields of $TRK_TBL data
structure which is an array of basic structures to handle the tracking functionalities.
To configure the hardware link of the conveyor to C5GPlus Controller, the following
variables are available:
– $TRK_TBL[nTbl].TT_APPL_ID identifies the being configured application type
(conveyor = 2):
$TRK_TBL[nTbl].TT_APPL_ID := 2
– $TRK_TBL[nTbl].TT_PORT_TYPE[1] identifies the input port type which has been
connected to the position transducer (it is a FMI port, identified by number 27):
$TRK_TBL[nTbl].TT_PORT_TYPE[1] := 27
– $TRK_TBL[nTbl].TT_PORT_IDX[1] identifies the configured port index, for reading
the position transducer. In case of predefined kit, such an index is automatically
assigned by the system. In case of user kit, the user should specify an already
mapped FMI index.
– In the case in which the position transducer is an encoder, the transducer sin/cos
pulse number must be specified by means of the following statement:
$TRK_TBL[nTbl].TT_I_PRMS[1] := 0 -- if resolver
$TRK_TBL[nTbl].TT_I_PRMS[1] := 1024 -- if encoder
– As far as the transmission rate, the following statement must be used:
$TRK_TBL[nTbl].TT_R_PRMS[1] := <tx_rate_value>
its unit of measure is [mm/motor turns] for cartesian linear tracking, cartesian
rototranslating tracking, whereas it is [motor turns/table turns] for rotating
conveyors.
– The being configured conveyor type must be specified by means of the following
statement:
$TRK_TBL[nTbl].TT_I_PRMS[2] := <conv_cnfg_value>
where <conv_cnfg_value> can be as follows:
• 0: linear cartesian tracking;
• 1: circular cartesian tracking;
• 3: rototranslating cartesian tracking (Robot Control on a bending-press).
– In case of either circular or rotranslating conveyor, the conveyor radius is also to
be specified, which can be run-time modified, by means of the following statement:
$TRK_TBL[nTbl].TT_R_PRMS[2] := <conveyor_radius>
– More than one Arm can be configured on the same Control Unit and not
necessarily they all neither are intended to track a conveyor nor it is right to use
them for tracking; a bit mask must then be configured indicating to the C5GPlus
which are the enabled Arms for tracking, by means of the following statement:
$TRK_TBL[nTbl].TT_ARM_MASK := <arm_mask>
Only the Arms which are included in the bit mask, will be enabled for tracking; an
error message will occur for the other ones, if and when there is an attempt to
activate the conveyor.
– For a good robot conveyor tracking, the reference frame must be defined on the
conveyor base:
$TRK_TBL[nTbl].TT_FRAMES[1] := <base1>
$TRK_TBL[nTbl].TT_FRAMES[2] := <base2>
$TRK_TBL[nTbl].TT_FRAMES[3] := <base3>
There are 3 reference values for the conveyor, with the following use:

171
Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

1. <base1> is used for all the different conveyor types except the rototranslating
one for which such a reference frame is only used during the press linear
tracking;
2. <base2> is used to upwards track the press during the press-bending
movement;
3. <base3> is used to downwards track the press during the press-bending
movement.
To discriminate between the three <baseX>, in case of rototranslating conveyor, it
is needed to set the following run-time modifiable variable, before activating
tracking:
$TRK_TBL[nTbl].TT_I_PRMS[3] := <modality>
Where the allowed values for such a variable are as follows:
• 0: press linear tracking;
• 1: rototranslation upwards tracking;
• 2: rototranslation downwards tracking.
It must be measured when the truck is either in the zero position (see later) or in a
known position. Some criteria must be complied in choosing the reference origin
position and the axes direction, which are slightly different for either linear, circular
or rototranslating tracking. See also par. 10.9 Use of the Roto-translating Conveyor
on page 179.
In case of linear conveyors, the base reference X axis must be aligned to the
positive direction of the conveyor; the X-Y plane must coincide with the plane of the
truck and the origin must be positioned at the point in which a sensor detects
passing of the truck.
In case of circular conveyors, the X axis must be tangential to the rotating table; the
Y axis must be in radial direction in relation to the table and oriented towards the
center of rotation; the position of the Z axis comes from the first two axes according
to the right-hand rule and faces up if the rotating table turns anticlockwise and
down otherwise. In circular case, the reference system origin must be at a known
distance from the center of rotation and does not precisely coincide with this; this
distance represents the table radius and must be assigned to
$TRK_TBL[nTbl].TT_R_PRMS[2]
(in case of rototranslating Conveyor, see par. 10.9 Use of the Roto-translating
Conveyor on page 179). The circumference passing through the table base
reference origin plays an important role in managing rotations: all distances and
speeds are measured in relation to this base circumference.
– The maximum allowed value for robot acceleration and speed can be configured
during the tracking phases, by means of the following statements:
$TRK_TBL[nTbl].TT_R_PRMS[3] := <speed_limit>
$TRK_TBL[nTbl].TT_R_PRMS[4] := <acceleration_limit>
– Furthermore, two tracking windows can be defined by means of the following
statements:
$TRK_TBL[nTbl].TT_R_PRMS[5] := <first_value>
$TRK_TBL[nTbl].TT_R_PRMS[6] := <second_value>
Where first_value indicates the conveyor quote from which the robot must start
tracking, whereas second_value indicates the quote beyond which no tracking can
be performed by the robot.
– A virtual encoder can be configured, i.e. to activate the conveyor on an input port
by setting the following variable:

172
 Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

$TRK_TBL[nTbl].TT_R_PRMS[17] := <conversion_factor>
Such a variable, if not zero, activates tracking by means of an input port, even
without any hardware conveyor and represents the conversion factor from the input
port unit of measure and the conveyor unit of measure (without taking the
tx_rate_value into account, which should anyway be indicated).

10.2 Working Principle

The conveyor is not controlled by C5GPlus Controller but only monitored by reading the
position of the position transducer, connected to the motor of the conveyor and linked
with the servo board of C5GPlus Controller. The position transducer value is stored in
the following variable
$CRNT_DATA[arm_num].CONV_ENC[nTbl]
every interpolation tick.
At a certain distance from the working area, a sensor (e.g. a photocell) must be installed
to detect the passage of the conveyor-truck. This is the zero position and when the truck
goes through it, the calibration (zeroing) of the conveyor position is needed, by means
of the CONV_TRACK built-in (see PDL2 Programming Language manual - chap.11
BUILT-IN Routines List), which can also be called from within Motion Page on the
Teach Pendant (par. 5.9.6 Conveyor Tracking (optional feature) on page 120) in
C5GPlus Control Unit Use manual.

Fig. 10.1 - Reference Frames for circular tracking

1. User Frame 2. Conveyor Base Frame

3. User Frame 4. Slide Frame
5. Sensor 6. User Frame

At every interpolator tick, the system calculates the truck current position and updates

173
Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

the frame reference system shifting it along X+ of the distance indicated by

$CRNT_DATA[arm_num].CONV_SHIFT[nTbl]
Such a distance is in millimeters. When tracking is active, the User frame (indicated by
$UFRAME) is referred to the truck frame, so that all the POSITIONs are referred to the
moving workpiece (see Fig. 10.1 - Reference Frames for circular tracking on page 173).

10.3 Process Monitoring

For the conveyor monitoring, some arrays are used in $CRNT_DATA:
– Number of the active conveyor on the Arm (0=none)
$CRNT_DATA[arm_num].CONV_ACT
– Conveyor encoder position in turns
$CRNT_DATA[arm_num].CONV_ENC[nTbl]
– Bend angle of the rototranslating conveyor, in radians
$CRNT_DATA[arm_num].CONV_BEND_ANGLE[nTbl]
This allows monitoring of all the configured conveyors by all the arms which are enabled
to work with the conveyor; such a monitoring will always result active, regardless of the
conveyor state.
Since $CRNT_DATA[arm_num].CONV_ENC[nTbl] is an INTEGER variable, it can be
inserted more effectively than $CRNT_DATA[arm_num].CONV_SHIFT[nTbl] in a
CONDITION to guarantee maximum efficiency.

Note that the Control Unit considers the slide speed to be null if its motion is reversed.

10.4 Tracking Window

For further information, please refer to par. 5.17.2.5.1 Tracking Table editing procedure
on page 257, in the Setup page of the Teach Pendant, C5GPlus Control Unit Use
manual.
The tracking window is a region that defines where the robot is enabled to track the
workpiece.
The tracking window has a start limit and an end limit, defined by the following system
variables
$TRK_TBL[nTbl].TT_R_PRMS[5] and
$TRK_TBL[nTbl].TT_R_PRMS[6].
$TRK_TBL[nTbl].TT_R_PRMS[5] contains the start limit from the origin of the conveyor
base frame (where the sensor is placed), whereas $TRK_TBL[nTbl].TT_R_PRMS[6]
contains the final limit distance (in case of rotating table, such distances are read along
the base circumference).
When tracking is active, no motion will begin until the origin of the truck frame is inside
the tracking window. If the robot attempts to move to a position when the truck has not
reached the window yet, the Controller waits until the part enters the window, which
means until $CRNT_DATA[n].CONV_SHIFT[nTbl] is greater than

174
 Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

$TRK_TBL[nTbl].TT_R_PRMS[5].
If the robot attempts to move when the truck is already out of the window
($CRNT_DATA[n].CONV_SHIFT[nTbl] > $TRK_TBL[nTbl].TT_R_PRMS[6]), an error is
issued by the Control Unit. The tracking window is usually defined during the
configuration phase, moving the robot to the two limits.

10.5 Motion Statements

The conveyor configuration does not depend on the arm, i.e. only a group of arms will
be indicated as being enabled to track the conveyor. This means that several arms can
work on the same conveyor both at the same time and consecutively, upon the required
application and the user programs.
It is then needed to activate and deactivate the conveyor in association to a specified
arm. To execute such an association, the following built-in routine is available:
CONV_TRACK(cmd, nTbl, <arm_num>, <dist>)
where the parameters have the following meaning:
– cmd - conveyor command assuming one of the following values:
• -1 initialize (CONV_INIT)
• 0 deactivate (CONV_OFF)
• 1 initialize and activate (CONV_INIT_ON)
• 2 activate (CONV_ON)
– nTbl - number of the configured table for the conveyor;
– arm_num - number of the arm for doing the conveyor tracking; it is an optional
parameter; if missing, the used value is the prog_arm;
– dist - distance between the sensor and the being tracked object, at the time in
which the conveyor initialization is requested; the default value is 0
If, before such a built-in is called, some configuration parameters are modified, it
updates the data in order to perform a good tracking.
Such a built-in routine execution, depending on the assigned value to cmd parameter,
activates/deactivates tracking without putting to zero the the conveyor encoder quote if
CONV_ON command is issued.
CONV_INIT_ON command puts to zero the conveyor quote and immediately activates
the conveyor; on the contrary, CONV_INIT command puts to zero the conveyor quote
without activating it. To deactivate it, CONV_OFF command is to be used.
If on the arm a conveyor tracking operation is already active, the built-in routine returns
an error when the user attempts to either initialize or activate a new conveyor.
A sample program follows to pick pieces from a conveyor and place them to a table:

ROUTINE ru_conv_condition (nTbl : INTEGER)

BEGIN
CONV_TRACK(CONV_INIT, nTbl) -- conveyor reset, tab.nTbl
END ru_conv_condition

PROGRAM conv
BEGIN
CONDITION[1]:
WHEN $DIN[1] DO
ru_conv_condition(1)

175
Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

ENDCONDITION
CYCLE
ENABLE CONDITION[1]
WAIT FOR $DIN[1] -- wait for the workpiece
CONV_TRACK(CONV_ON, 1) -- enable tracking
MOVEFLY LINEAR NEAR P1 BY 100 ADVANCE -- move towards
-- the truck
MOVE LINEAR TO P1 -- move to the workpiece
CLOSE HAND 1 -- pick up the workpiece
MOVE AWAY 100
CONV_TRACK(CONV_OFF, 1) -- disable tracking
MOVEFLY LINEAR NEAR P2 BY 100 ADVANCE -- move on the table
MOVE LINEAR TO P2
OPEN HAND 1 -- release workpiece
MOVE AWAY 100
END conv

10.6 Teaching Positions

Teaching cannot be performed when the conveyor is moving since tracking is not
allowed in Programming state.
Before starting the teaching session, CONV_TRACK built-in routine must be executed
with the zeroing command (with immediate activation if needed). The best method is to
switch the conveyor off after the passage through the zero position has been detected
and the CONV_TRACK built-in routine has been properly executed.
Otherwise the user has to measure the distance between the workpiece and the sensor
and then assign the zero position by the CONV_TRACK built-in, indicating the optional
parameter <dist>, where dist is the measured distance (in case of circular tracking it is
calculated along the circumference).
In Programming state and conveyor tracking enabled, every time a move starts the
position transducer is read and the cartesian positions are updated.

10.7 Tracking Interruption

LOCK statement and some alarms due to the motion, stop the program execution, but
the robot continues its tracking; this means that the robot moves in order to maintain
held the TCP with respect to the moving truck.
Fatal alarms, HOLD and DRIVES OFF commands stop both the execution of the
program and tracking. An output signal should be issue in order to stop and restart the
conveyor motion.

10.8 Limitations during Conveyor Tracking

All cases of Conveyor Tracking involve a number of limitations:
– only Cartesian (linear or circular) trajectories on POSITION type points can be
carried out during tracking;

176
 Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

– as joint type movements are not allowed, the recovery trajectories must also be of
the Cartesian type. Therefore, the values of the $RCVR_TYPE variable may be 3,
4, 5 , 6 only;
– no active motions can be present, when CONV_TRACK built-in routine is called to
activate or deactivate tracking;
– it is not possible to check tolerances on the stopping points during tracking as the
movement of the carrier involves continuous movement of the axes of the robot
also during stoppages. Therefore the only permissible value of the $TERM_TYPE
system variable is NOSETTLE;
– the values of $BASE and $TOOL variables cannot be modified immediately before
the carrier release movement. $UFRAME can however be modified as required;
– a linear trajectory on the fixed positions, i.e. with $CONV_TYPE := CONV_OFF
must be carried out after any error that causes release of robot trajectory;
– it is not possible to restart tracking after a power failure without first of all bringing
the robot to a fixed position (i.e. executing CONV_TRACK built-in with CONV_OFF
command).
– it is recommended not to use the CONV_TRACK built-in as the first statement in a
HOLDABLE program.

Tab. 10.1 - Conveyor Tracking System Variables

Name Description Type

Identifier of the being configured tracking application type:
TT_APPL_ID INTEGER
conveyor = 2
Several arms can be configured on the same Controller and not
necessarily they all are to track the conveyor, or sometimes it is
not correct to use them for tracking; it is then needed to also
configure a bit mask indicating to C5GPlus which are the
TT_ARM_MASK enabled arms for tracking, by means of the following statement: INTEGER
$TRK_TBL[nTbl].TT_ARM_MASK := <arm_mask>
Only the arms which are in cluded in the mask are allowed to
do the conveyor tracking; for the other ones an error message
occurs on attempts to activate the conveyor.
For the robot to properly track the conveyor, it is needed to
define a reference frame on the conveyor base:
$TRK_TBL[nTbl].TT_FRAMES[1] := <base1>
$TRK_TBL[nTbl].TT_FRAMES[2] := <base2>
$TRK_TBL[nTbl].TT_FRAMES[3] := <base3>
There are three reference values for the conveyor, with the
following meaning:
1 <base1> is used for several conveyor types except the ARRAY[3] OF
TT_FRAMES
rototranslating one, for which such a reference is only used POSITION
during the press linear tracking;
2 <base2> is used to track the press upwards during the
press-bend movement;
3 <base3> is used to track the press downwards during the
press-bend movement.
In case of linear conveyors, the X axis of the base reference
frame, must be aligned to the positive motion direction of the

177
Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

Tab. 10.1 - Conveyor Tracking System Variables (Continued)

Name Description Type

conveyor; X-Y plane must match with the truck plane direction
In the circular case, axis X must be tangent to the rotating table;
axis Y must be in radial direction referred to the table and
oriented towards the rotation center; the Z axis comes from the
X and Y ones, using the right hand rule and it is upwards if the
table moves anticlock wise, downwards on the contrary. In case
of circular tracking, the reference system origin must be at a
known distance from the rotation center and not exactely
corresponding to it; this distance represents the table radius
and must be assigned to TT_R_PRMS[2] variable.
INTEGER parameters for tracking configuration
– TT_I_PRMS[1] sin/cos pulse number
– TT_I_PRMS[2] conveyor configuration (linear, circular, rail
tracking, rototranslating conveyor )
– TT_I_PRMS[3] rt modality
In order to discriminate among the different BASEs
(see TT_FRAMES), in case of rototranslating conveyor, it is
needed to set the following variable, run-time editable, before
activating tracking:
$TRK_TBL[nTbl].TT_I_PRMS[3] := <modality>
ARRAY[20] OF
TT_I_PRMS where the allowed values to be assigned to the variable are as INTEGER
follows:
– 0: press linear tracking;
– 1: rototranslation upwards tracking;
– 2: rototranslation downwards tracking.
It must be measured when the truck is either in the zero position
(see later) or in a known position. Some criteria must be
complied with in choosing the reference origin position and the
axes direction, which are slightly different for either linear,
circular or rototranslating tracking. See also par. 10.9 Use of the
Roto-translating Conveyor on page 179.
I/O port index for tracking:
TT_PORT_IDX ARRAY[5] OF INTEGER
– TT_PORT_IDX[1] port number for conveyor encoder
I/O port type code for tracking:
TT_PORT_TYPE ARRAY[5] OF INTEGER
– TT_PORT_TYPE[1] port type for conveyor encoder
REAL parameters for tracking configuration
– TT_R_PRMS[1] tx_rate
– TT_R_PRMS[2] radius (circular / roto-traslanting)
– TT_R_PRMS[3] speed limit
– TT_R_PRMS[4] acceleration limit
– TT_R_PRMS[5] tracking window start limit
– TT_R_PRMS[6] tracking window end limit
TT_R_PRMS ARRAY[20] OF REAL
– TT_R_PRMS[7] sheet depth in mm
– TT_R_PRMS[8] die cave angle in rad
– TT_R_PRMS[9] die shoulder radius in mm
– TT_R_PRMS[10] die cave width in mm
– TT_R_PRMS[11] knife radius in mm
– TT_R_PRMS[12] Maximum bend rotation angle in rad
– TT_R_PRMS[13] parameter 1 for arma filter

178
 Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

Tab. 10.1 - Conveyor Tracking System Variables (Continued)

Name Description Type

– TT_R_PRMS[14] parameter 2 for arma filter
– TT_R_PRMS[15] arma_filter_3 (rt)
– TT_R_PRMS[16] arma_filter_4 (rt)

Tab. 10.2 - Conveyor Tracking Built-ins

Built-in name Parameters

CONV_TRACK cmd, nTbl, <arm_num>, <dist>
Where:
– cmd - conveyor command with the following
allowed values:
• -1 initialize (CONV_INIT)
• 0 deactivate (CONV_OFF)
• 1 initialize and activate (CONV_INIT_ON)
• 2 activate (CONV_ON)
– nTbl - number of the configured table for
conveyor
– arm_num - optional; number of the arm to be
used for conveyor trackin operations; if missing,
the prog_arm is used
– dist - optional; distance between the sensor and
the being tracked object, at the time the conveyor
initialization is required; the default value is 0.

10.9 Use of the Roto-translating Conveyor

Usually, $TRK_TBL[nTbl].TT_FRAMES, frame cannot be permanently calculated at the
configuration time, because it depends on the bend upward or downward direction.
Anyway, it is possible to fix some headlines which could be useful to determine it.
The X axis of the base frame must be lined up with the Conveyor motion direction (which
means the knife of the bending-press); the X-Y plane must be orthogonal to the
bending-press motion plane and the origin must be fixed in the maximum opening point
of the bending-press.
If the bend direction of the part is upward, the Y axis must enter the bend motion plane;
on the contrary, it must exit the motion plane.
The value of $TRK_TBL[nTbl].TT_R_PRMS[2] is the robot distance from the bend (in
mm); such a value must be calculated referred to the robot position at the beginning of
the bend, from the sheet point of contact (see Fig. 10.2).

179
Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

Fig. 10.2 - Bend beginning position

1. Bending-press 2. Sheet 3. Robot

Fig. 10.3 - Bending Press 3-dimensional representation

Fig. 10.4 - Bending Press graphical representation

180
 Comau Robotics Product Instruction

CONVEYOR TRACKING (OPTIONAL FEATURE)

10.9.1 Configuration parameters

The needed parameters to properly configure the tracking, are as follows:

$TRK_TBL[nTbl].TT_R_PRMS[7] Sheet depth in mm

$TRK_TBL[nTbl].TT_R_PRMS[8] Die cave angle in rad
$TRK_TBL[nTbl].TT_R_PRMS[9] Die shoulder radius in mm
$TRK_TBL[nTbl].TT_R_PRMS[10] Die cave width in mm
$TRK_TBL[nTbl].TT_R_PRMS[11] Knife radius in mm
$TRK_TBL[nTbl].TT_R_PRMS[12] Maximum bend rotation angle in rad

181
Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

11. MOTION WITH WEAVING (OPTIONAL

FEATURE)

Weaving Motion
The option code is CR17926207.

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
– Weaving on multiarm systems.

182
 Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

11.1 Weaving Mode

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

183
Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

11.2 Weaving Activation

Weaving 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 continuous 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.
A movement after a weaving stop is called first motion with weaving. A weaving stop can
occur if the user disables it intentionally, or if the movement is a joint motion, or if two
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).

184
 Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

11.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:
– An INTEGER field defines the weaving wave form generation modality,
$WEAVE_TBL[n].WEAVE_MODALITY, with possible values 0..8:
• $WEAVE_MODALITY=0 - the wave form is generated by the transverse
speed;
• $WEAVE_MODALITY=1 - the wave form is generated by the wave length. 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 with circular wave form, generated by the
transverse speed.
• $WEAVE_MODALITY=4 - weaving with circular wave form, generated by the
wave length.
• $WEAVE_MODALITY=5 - weaving with ‘V’ wave form, generated by the
transverse speed.
• $WEAVE_MODALITY=6 - weaving with ‘V’ wave form, generated by the
wave length.
• $WEAVE_MODALITY=7 - weaving with triangular wave form, generated by
the transverse speed.
• $WEAVE_MODALITY=8 - weaving with triangular wave form, generated by
the wave length.
– 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 fields 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 minor semi-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 major semi-axis of the ellipse representing the weaving form).
– A REAL field defines the weaving height related to the weaving plane in case of
either triangular or ‘V’ weaving
• $WEAVE_TBL[n].WV_HEIGHT
– Four INTEGER fields define the dwell times (not applicable for circular wave form):
• $WEAVE_TBL[n].WV_LEFT_DWL defines the left dwell time (in ms) in case
of $WEAVE_MODALITY = 0, 3, 5, 7; it defines the covered distance (in mm)
on the left along the path, instead, in case of $WEAVE_MODALITY = 1, 4, 6,
8. Limits: 0 to 10.000;
• $WEAVE_TBL[n].WV_CNTR_DWL defines the dwell time (in ms) in the
centre in case of $WEAVE_MODALITY = 0, 3, 5, 7; it defines the covered

185
Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

distance (in mm) in the center along the path, instead, in case of
$WEAVE_MODALITY = 1, 4, 6, 8. Limits: 0 to 10.000;
• $WEAVE_TBL[n].WV_RIGHT_DWL defines the right dwell time (in ms) in
case of $WEAVE_MODALITY = 0, 3, 5, 7; it defines the covered distance (in
mm) on the right along the path, instead, in case of $WEAVE_MODALITY =
1, 4, 6, 8. Limits: 0 to 10.000;
• $WEAVE_TBL[n].WV_END_DWL defines the dwell time (in ms) at the end of
the movement in case of $WEAVE_MODALITY = 2; it does not take any
effect in the other cases. Limits: 0 to 10.000;
– a BOOLEAN field controls the corners smoothness of the wave form (see later
description); it is not applicable in case of circular wave form:
• $WEAVE_TBL[n].WV_SMOOTH ;
– a REAL field controls the transverse speed:
• $WEAVE_TBL[n].WV_TRV_SPD (recommended 0.035 m/sec);
– four REAL fields for the 4 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 angle between the weave plane and the weave direction
(see later description):
• $WEAVE_TBL[n].WV_PLANE (-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 (-180
to +180 degrees) for the weaving direction in case of either Weaving without
Arm motion or 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 (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
– an INTEGER field indicates the 'weaving dwell' modality
• if $WEAVE_TBL[n].WV_DWL_MODALITY = 0 (default), the 'weaving dwell'
just stops the wave form generation and not the robot trajectory;
• if $WEAVE_TBL[n].WV_DWL_MODALITY = 1, the 'weaving dwell' also stops
the robot trajectory. Such a modality is applicable to the Transversal Speed
Weaving case (in which the dwell is expressed in ms).
Parametric weaving is defined by three indications:

186
 Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

– Wave Shape
– Weave Plane (angle of weaving plane)
– Weave Amplification (used to vary the weaving amplitude)

11.3.1 Wave Shape

In the cartesian weaving, the wave form can be either trapezoidal or circular, either lying
on a plane or in the space (3D weaving) with ‘V’ or triangular wave form.
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, 3, 5, 7 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 such parameters. The motion speed along the
trajectory ($LIN_SPD) does not affect frequency, but rather the wave length. Fig. 11.1
shows the basic shape and defines the various dwell times. It also shows how the speed
and slope are calculated in case of trapezoidal wave.
If WEAVE_MODALITY = 1, 4, 6, 8 the wave length (and therefore the frequency) are
maintained as the speed varies; overrides do not affect the wave form.
If WEAVE_MODALITY=2, the wave form is generated with 4 different transverse
speeds. Profiles are asymmetric.

Fig. 11.1 - Weave Parameters - A

a. Weaving direction b. Time

1 - ts[1] 2 - Left dwell time 3 - ts[2] 4 - Central dwell time

5 - ts[3] 6 - Right dwell time 7 - ts[4] 8 - Final dwell time
9 - Left amplitude 10 - Right amplitude

Note that the following formula is used for transverse speed calculation

Left amplitude
Transverse speed = ----------------------------
ts

187
Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

Meaning of the ts[n] terms (ramp up or down times), depending on the weaving modality:
– Modality 0, 3, 5, 7 - ts times are all equal and are generated to reach a
transverse speed $weave_tbl[n].wv_trv_spd;
– Modality 1, 4, 6, 8 - 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].

Fig. 11.2 - WeaveParameters - B

1 - Weaving direction 2 - Path 3 - Transverse speed

4 - Torch speed = Linear speed 5 - Torch speed = Resulting speed 6 - Linear speed

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 motion 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. 11.3 shows the different shapes that
can be achieved using the $WEAVE_TBL settings.

Fig. 11.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 amplitudes
6 - Circular

188
 Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

Fig. 11.4 - Triangular weaving

Fig. 11.5 - ‘V’ weaving

The weave wave frequency is calculated in one of the shown below ways, according to
the used modality:
– modality 0, 5, 7

– modality 2

where:
dwell sum = left dwell + right dwell + 2 * center dwell (ms)
The maximum frequency depends on the mechanical design of the arm, but the weave
form will match the theoretical trajectory up to about 5 Hz (cartesian weaving) or 8 Hz

189
Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

(joint weaving) on arms intended for arc welding.

Fig. 11.6 - WeaveParameters - C

The weave parameters - B (see Fig. 11.2) are valid for any wave form.
The frequency, in case of circular wave form, modality 3, described by the transverse
speed, is:

11.3.2 Weave Plane

Weave plane only applies to cartesian weaving and is established as explained below.
At the beginning of the first motion with weaving, the approach vector of the tool and the
tangent to the motion 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”).

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. 11.7 shows such a procedure.

190
 Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

Fig. 11.7 - 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 plane
9 - Weaving plane 10- Approach vector (along Z Tool)

Weaving can be executed between two trajectories connected in fly; in this case, by
default, the weaving direction on the second trajectory is recalculated maintaining the
inclination angle 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 Controller will refer to this angle only for
the first motion 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 (see par. 6.10.2.2
FLY_CART (Controller Aided Resolved Trajectory) on page 129 for further details).

Fig. 11.8 - Weaving during continuous motion (fly)

1 - Start point 2 - Weaving plane angle= 0°

For a circular motion, the weave plane is continuously evaluated along the path, so that
the weave direction is always perpendicular to it. If the weave plane is not parallel to the

191
Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

plane of the circle, the weave plane will be on the frustum of a cone as shown in Fig. 11.9
- Circular Weaving on page 192.

Fig. 11.9 - Circular Weaving

1 - Initial weaving direction 2 - Start point 3 - Final weaving direction

4 - Final point 5 - Centre of circumference

If, instead, the need is to keep the weaving plane constant in respect to the torch
orientation, i.e. keeping constant the angle between the torch plane and the weaving
direction in the connected in fly trajectories, variable
$WEAVE_TBL[n].WV_PLANE_MODALITY must be set to 2; in this case too weaving
will pass from one direction to the other one without interruption.
The need of weaving along a circular helicoid trajectory could arise in specific
applications, in which the weaving plane is integral with the torch instead of the
trajectory, as in the above described standard case. In this case, the value of
$WEAVE_TBL[n].WV_PLANE_MODALITY variable must be set to 1 instead of
0 (default).
In this case, the weaving direction is, by default, the one corresponding to the torch Y
direction. If weaving in a different direction is needed, the use of
$WEAVE_TBL[n].WV_DIRECTION_ANGLE variable is suggested, which represents a
rotation angle around the Z vector of the torch itself.

11.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 movements in fly or along a path is performed, the amplitude corresponding
to 100% is determined at the first motion 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
movement. Thus, a series of movements can be used to weld along a variable length
seam without stopping (note that the $WEAVE_TBL[n].WV_AMP_PER variable is read
at each movement, but the definition of 100% is only determined at the first motion with

192
 Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

weaving).
Fig. 11.10 shows the weave amplification feature.

Fig. 11.10- Weave amp

1 - Final amplitude 2 - Final point 3 - Start point 4 - Initial amplitude

1 - Welded part 2 - First motion in fly 3 - Second motion in fly

4 - Welding 5 - Fly motion node

193
Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

11.4 Stopping Motions with Weaving

When movement stops at the last position of a path or upon the operator to press the
HOLD key, the torch could be away from the trajectory because of weaving. In this case,
the C5GPlus Controller will bring the torch onto the trajectory before stopping.
In emergency stop or power failure cases, the arm stops immediately, even if away from
the original trajectory. When power is restored and START key is pressed, the trajectory
recovery is performed before the weaving motion resumes.
Fig. 11.11 illustrates these cases.

Fig. 11.11- Weave stop

1. System in Hold state 2. Stop point 3. Original path

4. Emergency stop or Power failure 5. Trajectory resume 6. Original path

194
 Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

11.5 Programming Weaving

Weaving is programmed by first assigning weave table values and then activating
weaving by selecting an appropriate index into the table by means of $WEAVE_NUM
predefined variable.
$WEAVE_NUM can also be used in a WITH clause. In such a 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 change the active weaving table index during a single movement or
a path segment, as each movement can be referred to just one table.
However, the wave form 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. 11.1).

Tab. 11.1 - Predefined variables for Weaving

Name Type Limits Default WITH

$WEAVE_NUM INTEGER [ 0, 10 ] UNINIT YES
$WEAVE_MODALITY INTEGER [ 0, 4 ] 0 YES
$WEAVE_TYPE INTEGER [0, 10] UNINIT YES
$WEAVE_TBL ARRAY NO
[$NUM_WEAVES] OF
RECORD
$WEAVE_TBL[idx].WV_PLANE REAL [-180, +180] deg 0.0 NO
$WEAVE_TBL[idx].WV_LENGTH_WAVE INTEGER [0, 10000] 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
$WEAVE_TBL[idx].WV_RADIUS REAL 0.0 NO
$WEAVE_TBL[idx].WV_PLANE_MODALITY INTEGER [0, 2] 0 NO
$WEAVE_TBL[idx].WV_DIRECTION_ANGLE REAL [-180, +180] deg 0.0 NO

195
Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

Tab. 11.1 - Predefined variables for Weaving (Continued)

Name Type Limits Default WITH

$WEAVE_TBL[idx].WV_HEIGHT REAL 0.0 NO
$WEAVE_TBL[idx].WV_DWL_MODALITY INTEGER [0, 1] 0 NO
$NUM_WEAVES INTEGER [0, 16] 10 NO
(*) If $WEAVE_MODALITY=0,3,5,7 they are expressed in mm
If $WEAVE_MODALITY=1,4,6,8 they are expressed in ms

196
 Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

11.6 Weaving without Arm motion

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

11.6.1 Mode
The weaving without Arm motion mode is activated by means of
$CRNT_DATA[arm_num].WEAVE_TYPE_NOMOT predefined variable which has got
the same functionalities as described in par. 11.1 Weaving Mode on page 183: the only
difference is that such a mode is performed without a motion embedded to the weaving.

11.6.2 Activation
For this functionality too, the activation is performed by means of defining the being
executed weaving 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 exactly 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.

11.6.3 Parameters
The used parameters belong to the same group described in the previous par. 11.3
Weaving Parameters on page 185.
Anyway, there are some features which make a no-sense for this functionality: e.g.
mode 1 cannot be selected which involves a wave form related to the wave length,
because the Arm does not move.
The weaving direction is, by default, the torch X direction corresponding one. If weaving
in a different direction is needed, variable $WEAVE_TBL[n].WV_DIRECTION_ANGLE
can be used representing a rotation angle of the torch around the Z vector.

11.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[1].WV_LEFT_AMP := 5
$WEAVE_TBL[1].WV_RIGHT_AMP := 5

197
Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

$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 usual
working motions.

WARNING - in case of HOLD state, weaving is stopped and deactivated: enable the
functionality again to move weaving again.

198
 Comau Robotics Product Instruction

MOTION WITH WEAVING (OPTIONAL FEATURE)

11.7 Weaving on multiarm systems

In order to allow programming with different wave shapes, on Arms sharing the same
program in a multiarm system, $WEAVE_NUM, $WEAVE_MODALITY and
$WEAVE_TYPE are now fields of the $PROG_ARM_DATA[arm_num] variable.
This means such variables are local to both the program (like it already was, for previous
versions), and the Arm.
Where and when there is not any ambiguity, the $PROG_ARM_DATA[arm_num] string
can be skipped over.
Such a modification does not cause any incompatibility for single Arm systems.
For multiarm systems the following settings can be made, for example:
– $WEAVE_NUM := 1 -- modally sets the weaving table number, for the program
default Arm;
– $PROG_ARM_DATA[2].WEAVE_NUM := 2 -- modally sets the weaving table
number for Arm 2;
– MOVE TO p1 WITH $WEAVE_NUM=3 SYNCMOVE ARM[2] TO p2 WITH
$WEAVE_NUM = 4 -- nodally sets different weaving tables for the two involved
Arms.

WARNING - There could be a conflict with the previous versions: if the following
statements have been written
– $WEAVE_NUM := 1
– MOVE TO p1 -- it is the default Arm, so weaving is activated
– $WEAVE_NUM := 2
– MOVE ARM[2] TO p2 -- in current version, ARM 2 does not weave because
-- $WEAVE_NUM is set for the $PROG_ARM i.e. ARM 1.

199
Comau Robotics Product Instruction

JOINT SOFT SERVO (OPTIONAL FEATURE)

12. JOINT SOFT SERVO (OPTIONAL FEATURE)

Joint Soft Servo

The option code is CR17926203.

12.1 Description
Joint Soft Servo is a software option used in some applications when it is required that
the robot is compliant to movements produced by external forces. For example, when a
workpiece is hooked from a press, the detachment is facilitated by the pushing of a roll;
the robot must follow the movement without opposition.
When Joint Soft Servo is enabled, the robot should be steady. The Joint Soft Servo
modality is automatically disabled by a DRIVE OFF.
The degree of compliance of each axis must be defined when such a modality is
enabled.
To enable/disable the Joint Soft Servo modality, use ARM_SOFT built-in routine,
provided by PDL2 programming language.

For further information, please refer to PDL2 Programming Language manual -

BUILT-IN routines List chapter, ARM_SOFT paragraph.

200
 Comau Robotics Product Instruction

FLOW MODULATE ALGORITHM

13. FLOW MODULATE ALGORITHM

13.1 Basic concepts

This functionality, used in applications such as Cosmetic Sealing and Glueing,
modulates the flow of material to be delivered during the part machining, according to
the speed of the TCP (Tool Center Point).
The dispensing device, according to the set voltage, delivers a certain amount of
material. The maximum allowed voltage value depends on the dispensing device.
The voltage to be supplied is passed each time from C5GPlus by means of a predefined
variable, either $FMO or $AOUT or $WORD. Maximum allowed value is 65535.
If, for example, the maximum voltage value that can be delivered is 10 Volt and the
$FMO or $AOUT or $WORD predefined variable is set to 65535 (maximum $FMO /
$AOUT / $WORD value), this means that the machine will apply the maximum voltage
(10 Volt) for the material delivery.
Some dedicated 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_VAR (INTEGER): type of variable to be operated on. If set to 1 the flow
modulation algorithm is applied to $ARM_VEL; if set to 2 the flow modulation
algorithm is applied to $RAD_VEL.
– $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 to 2.
– $FW_CNVRSN (REAL): conversion factor to be applied to calculate the flow for
delivering. This conversion value can also be modified while the algorithm is
working.
– $FW_ENBL (BOOLEAN): algorithm state indicator - enabled or disabled.
– $FW_FLOW_LIM (2 INTEGER array): indicates the minimum [1] and maximum [2]
flow limits above which the modulation algorithm will apply the closest limit.
– $FW_SPD_LIM (2 REAL array): indicates the minimum [1] and maximum [2] speed
limits above which the flow modulation algorithm will apply the closest limit.
– $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 to the Output port indicated in FLOW_MOD_ON call (see par.
NOTE on page 204).
A full description is provided about the following topics:
– Calculating the flow-speed function
– Activating/deactivating the algorithm.

201
Comau Robotics Product Instruction

FLOW MODULATE ALGORITHM

13.2 Calculating the flow-speed function

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 voltage in bits
applicable to the Output port. These values are defined during the initial configuration
when setting the $FLOW_TBL fields.

Proceed as follows, with reference to the previous figure:

a. maximum speed definition ($FW_SPD_LIM[2])

b. maximum flow definition ($FW_FLOW_LIM[2])

202
 Comau Robotics Product Instruction

FLOW MODULATE ALGORITHM

c. conversion factor calculation ($FW_CNVRSN), as

$FW_CNVRSN := $FW_FLOW_LIM[2] / $FW_SPD_LIM[2]

d. either minimum flow ($FW_FLOW_LIM[1]) or minimum speed ($FW_SPD_LIM[1])

values definition, choosing the most limiting quantity, and setting the other quantity
to zero, for consistency.

Example
In case in which using the robot speed ($ARM_VEL) as input ($FW_VAR = 1) is wished,
proceed in the following way:

a. $FW_SPD_LIM[2] := 0.45 -- maximum speed = 450 mm/s

b. $FW_FLOW_LIM[2] := 65535 -- output port maximum value (16 bit in the example)

c. $FW_CNVRSN := $FW_FLOW_LIM[2] / $FW_SPD_LIM[2]

d. assigning the minimum value

• flow limitation:
$FW_FLOW_LIM[1] := 128 -- output port minimum value
$FW_SPD_LIM[1] := 0
• speed limitation:
$FW_SPD_LIM[1] := 0.1 -- speed minimum value 100 mm/s
$FW_FLOW_LIM[1] := 0

203
Comau Robotics Product Instruction

FLOW MODULATE ALGORITHM

13.3 Activating/deactivating the algorithm

What is configured in the $FLOW_TBL, is activated by means of the following call:
FLOW_MOD_ON (<port>, <flow_table_index>)
where:
– <port> refer to an INTEGER type port, i.e. $FMO, $AOUT, $WORD. For example
the parameter can be $FMO[4] or $AOUT[2], etc. The value contained in this port
is used by the algorithm to calculate the voltage to be supplied to the dispensing
device
– <flow_table_index> is the $FLOW_TBL table index. Allowed values: 1 or 2.
It is deactivated instead, by means of the following call:
FLOW_MOD_OFF (<flow_table_index>)
where:
– <flow_table_index> is the $FLOW_TBL table index. Allowed values: 1 or 2.

– The program calling FLOW_MOD_ON with a certain index, must be the same
which calls FLOW_MOD_OFF with such an index.
– When the program is deactivated, the algorithm too is deactivated and the table is
automatically released (implicit FLOW_MOD_OFF).

NOTE
For detailed information about FLOW_MOD_ON and FLOW_MOD_OFF built-in
routines and their usage, refer to PDL2 Programming Language manual - chap.
BUILT-IN ROUTINES LIST.

204
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

14. PRESUPPOSITIONS FOR SMART ROBOT

PROGRAMMING

14.1 Introduction
Current chapter summarizes further information related to the use of COMAU robots.
They are classified as being with spherical wrist or with non-spherical wrist.
COMAU robots which are involved in current chapter are shown in the following
Tab. 14.1 - Involved Robot models on page 205:

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

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

205
Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

14.2 Glossary
TCP - Tool Center Point. It is the point at the end of the tool and it is geometrically
described by the $TOOL system variable or by the Tool tables in DATA environment. It
can be local or remote. For SMART NJ4(L) robot the TCP position, with reference to the
robot axes, causes some limitations to the robot working area.
WCP - Wrist Center Point. For spherical wrist robots, WCP is the intersection point
between joint 5 and joint 6; for SMART NJ4 robots (non-spherical wrist) there isn’t a true
WCP: such a word means the intersection point between joint 4 and joint 5.

1. Wrist offset

RRS - Robot Realistic Simulation. It is a protocol that defines some rules to implement
a software sequence that allows a robotics CAD simulator (i.e. Robcad) to move the
robot using the same algorithms than the original Controllers. Such a software sequence
is called RCS module. It is provided by Comau and integrated into the simulators.
Nominal position - This term refers to machines with the Kinematics compensation
algorithm. The nominal position is the destination where the robot must move its TCP.
It usually comes from a CAD simulation where the model of the robot is theoretical,
without mechanical strains due to payload, calibration errors, etc.
Internal representation of the robot position - This term refers to machines with the
Kinematics compensation algorithm. The internal representation of the robot position is
the one coming out from the encoders/resolvers. It is also the position where the robot
is really moved to compensate the differences between the real machine and the
theoretical robot model.
Cartesian position or POSITION - It is a variable that describes the target position for
a MOVE statement by referring to a Cartesian frame of reference. In C5GPlus 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.

206
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

14.3 Offset algorithm with Dynamic Model

This algorithm improves the mechanical precision in movement and positioning, thus
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 accuracy 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 singularities

In current paragraph information is 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 on
page 205, 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

207
Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

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 212 for non-spherical wrist robots and
par. 14.6.2.1 Axis 5 singularity on page 218 for spherical wrist robots.
Nevertheless there is a general feature available with Comau C5GPlus 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
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 218).
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 path

2 - Exact singularity position

3 - Behaviour of the WRIST_JOINT modality.

Getting closer to the singularity, speed is maintained high while

orientation slightly changes

208
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

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 212) 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 point

209
Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

14.5.1.2 Wrist Singularity Management (optional feature)

Wrist Singularity Management

The option code is CR17926220.

To help programming in cases of possible motion through the wrist singularity, an

optional functionality is available called 'Wrist Singularity Management': when using
such an option, the trajectory planner will take care of evaluating whether or not to
modify ‘W’ attitude flag of the destination position and to switch the evolution modality
to WRIST_JNT when in correspondence to the lowest path of 4 and/or 6 robot joints.
Such an option is only provided for spherical wrist SMART family robots (not applicable
for NJ4 family robots): if the option is enabled for an arm not in accordance with the
required feature, a message is issued at startup phase:
'Arm n Wrist Singularity Management not possible to enable'
and any further reference to the funtionality for such an arm, is simply ignored.
If the option is present, the user is allowed to enable it within his/her user program, by
setting the following flag:
$CRNT_DATA[arm_num].WSM_ENBL := TRUE.
Such a flag value is not saved to the .C5G file: if the user wishes to indiscriminately apply
this option to all his/her programs, just set its value to TRUE within the STARTUP
program.
This functionality can be applied to any orientation evolution type: if, during motion, there
is not the need to change 'W' flag, the chosen orientation will be preserved; if, on the
contrary, the system detects the need to modify it, the orietation type for such a
movement will be forced to WRIST_JNT. In this condition, if the orientation previously
chosen by the user was different than WRIST_JNT and the movement was in FLY, the
fly itself will be deleted: a warning message will then be issued to point out the fly
deletion; the program will continue running.
Furthermore, it is suggested, for the functionality proper functioning, to check
$TURN_CARE and $SING_CARE predefined variables setting: they should be set to
FALSE.

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.

210
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

The WRIST_JNT evolution can be set for Cartesian manual motion, 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
– 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

211
Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

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 approximation
2a - 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
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°.

[ -6; +6 ]
Forbidden ranges [ -174; -186 ]
[ +174; +186 ]
[ -7; +7 ]
Safe ranges [ -173; -187 ]
[ +173; +187 ]

212
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

Fig. 14.1 - SMART NJ4 forbidden zone

1. ±6 degrees around 0° and 180°

Actions Allowed Forbidden Notes

REC JOINTPOS inside the singularity zone It is possible to record a joint position
X
(JOINTPOS).
REC POSITION/XTNDPOS inside the singularity It is NOT possible to record a
zone X Cartesian position (POSITION or
XTNDPOS).
MOVE JOINT through singularity zone X
MOVE LINEAR/CIRCULAR through singularity zone It is possible to move in a Cartesian
X
with the standard evolution modality (RS_WORLD) way only with the WRIST_JNT
MOVE LINEAR/CIRCULAR through singularity zone evolution (see par. 14.5 Moving
with the WRIST_JNT evolution modality through axis 5 singularities on
X page 207). In the standard modality
(RS_WORLD) MOVE
LINEAR/CIRCULAR is not allowed.
JOG JOINT inside the singularity zone X It is possible to jog the robot in a
Cartesian way only if the
JOG BASE, UFRM, TOOL inside the singularity WRIST_JNT modalities are enabled
X
zone (WR-BASE, WR-UFRM, WR-TOO,
JOG WR-BASE, WR-UFRM, WR-TOOL inside the see par. 14.5.2 Manual motion (jog
singularity zone keys) on page 210). It is not allowed
X to jog inside the singularity zone with
the standard jog modalities (BASE,
UFRAME, TOOL).
MOVE JOINT TO JOINTPOS inside the singularity
X
zone
MOVE LINEAR TO JOINTPOS inside the singularity
X
zone If the destination point is inside the
MOVE JOINT TO POSITION/XTNDPOS inside the singularity zone it is not possible to
X
singularity zone move there both with the standard
MOVE LINEAR TO POSITION/XTNDPOS inside the evolution and with WRIST_JNT.
X
singularity zone

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

213
Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

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.

These areas can be reached in a joint way; the limitations only refer to Cartesian
movements

Actions Allowed Forbidden Notes

REC JOINTPOS inside the forbidden zone It is possible to record a joint position
X
(JOINTPOS).
REC POSITION/XTNDPOS inside the forbidden It is NOT possible to record a
zone X Cartesian position (POSITION or
XTNDPOS).
MOVE JOINT through the forbidden zone X It is allowed to move through this
MOVE LINEAR/CIRCULAR through the forbidden zone with every type of movement. It
zone X is sufficient that the destination point
is out of the forbidden zone.
JOG JNT inside the forbidden zone X
It is possible to jog the robot in every
JOG BAS, USR, TOL inside the forbidden zone X modality.
JOG BWR, UWR, TWR inside the forbidden zone X
MOVE JOINT TO JOINTPOS inside the forbidden
X
zone
MOVE LINEAR TO JOINTPOS inside the forbidden
X If the destination point is inside the
zone
forbidden zone, it is possible to reach
MOVE JOINT TO POSITION/XTNDPOS inside the it only if it is a JOINTPOS.
X
forbidden zone
MOVE LINEAR TO POSITION/XTNDPOS inside the
X
forbidden zone

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

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

214
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

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.

The same situation can also happen with remote tool.

1 - Remote TCP inside the forbidden zone

Actions Allowed Forbidden Notes

REC JOINTPOS inside the forbidden zone It is possible to record a joint position
X
(JOINTPOS).
REC POSITION/XTNDPOS inside the forbidden zone It is NOT possible to record a
X Cartesian position (POSITION or
XTNDPOS).
MOVE JOINT through forbidden zone X
MOVE LINEAR/CIRCULAR through forbidden zone with It is possible to move in a Cartesian
X
the standard evolution modality (RS_WORLD) way only with the WRIST_JNT
MOVE LINEAR/CIRCULAR through forbidden zone with evolution (see par. 14.5 Moving
the WRIST_JNT evolution modality through axis 5 singularities on
X page 207). In the standard modality
(RS_WORLD) MOVE
LINEAR/CIRCULAR is not allowed.

215
Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

Actions Allowed Forbidden Notes

JOG JNT inside the forbidden zone X It is possible to jog the robot in a
Cartesian way only if the
JOG BAS, USR, TOL inside the forbidden zone X WRIST_JNT modalities are enabled
JOG BWR, UWR, TWR inside the forbidden zone (BWR, UWR, TWR, see par. 14.5.2
Manual motion (jog keys) on
page 210). It is not allowed to jog
X
inside the forbidden zone with the
standard jog modalities (BAS, USR,
TOL).
MOVE JOINT TO JOINTPOS inside the forbidden zone X
MOVE LINEAR TO JOINTPOS inside the forbidden zone X
If the destination point is inside the
MOVE JOINT TO POSITION/XTNDPOS inside the forbidden zone, it is possible to reach
X
forbidden zone it only if it is a JOINTPOS.
MOVE LINEAR TO POSITION/XTNDPOS inside the
X
forbidden zone

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

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

Actions Allowed Forbidden Notes

REC JOINTPOS inside the forbidden zone It is possible to record a joint position
X
(JOINTPOS).

216
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

Actions Allowed Forbidden Notes

REC POSITION/XTNDPOS inside the forbidden It is NOT possible to record a
zone X Cartesian position (POSITION or
XTNDPOS).
MOVE JOINT through forbidden zone X
MOVE LINEAR/CIRCULAR through forbidden zone It is possible to move in a Cartesian
X
with the standard evolution modality (RS_WORLD) way only with the WRIST_JNT
MOVE LINEAR/CIRCULAR through forbidden zone evolution (see par. 14.5 Moving
with the WRIST_JNT evolution modality through axis 5 singularities on
X page 207). In the standard modality
(RS_WORLD) MOVE
LINEAR/CIRCULAR is not allowed.
JOG JNT inside the forbidden zone X It is possible to jog the robot in a
Cartesian way only if the
JOG BAS, USR, TOL inside the forbidden zone X WRIST_JNT modalities are enabled
JOG BWR, UWR, TWR inside the forbidden zone (BWR, UWR, TWR, see par. 14.5.2
Manual motion (jog keys) on
page 210). It is not allowed to jog
X
inside the forbidden zone with the
standard jog modalities (BAS, USR,
TOL).
MOVE JOINT TO JOINTPOS inside the forbidden
X
zone
MOVE LINEAR TO JOINTPOS inside the forbidden If the destination point is inside the
X
zone forbidden zone, it is possible to reach
MOVE JOINT TO POSITION/XTNDPOS inside the it only if it is a JOINTPOS
X
forbidden zone
MOVE LINEAR TO POSITION/XTNDPOS inside the
X
forbidden zone

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

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.

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 out of work range".

217
Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

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
par. 14.6.1 Inverse conversion of SMART NJ4 (non-spherical wrist) model on page 211
don’t exist for spherical wrist robots. There is only some limitation about the singularity
of axis 5 and when the TCP is close to axis 1 for spherical wrist shelf mounted machines.
Detailed information are given about Axis 5 singularity.

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

SMART NJ4 robot has been designed for integration of cabling and ease of off-line
programming. For this reason it has a fixed wrist configuration to give the needed space
and distances to include pre-twisted cables and hoses through the wrist. Following this
concept, such a robot model is completely without any external cable on the forearm,
avoiding the unknown behavior of the cables with conventional robots while moving
close to the wrist singularity.

The disadvantage is that SMART NJ4 robot has a larger singularity zone around axis 5
with respect to spherical wrist robots (see par. 14.6.1.4 Axis 5 singularity on page 212).
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 C5GPlus 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

218
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

page 207 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
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 rotation takes more effect if the tool approach vector is not parallel to axis 6 of the
robot. If they are parallel, something can still be done, provided that the TCP is not
aligned along axis 6.

The following pictures show three different cases with a spot welding gun.

BEST situation (90° between axis 6 and gun approach

vector)

219
Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

WORST situation (approach vector aligned with axis 6)

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 219) 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 222).
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;

220
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

– the pallet is placed at the same level of the robot calibration position;
– the pallet is placed exactly in front of the robot.

To eliminate any singularity problems, the programmer has to remove al least one of the
listed above conditions. For example, putting the pallet in a lower position or mounting
the robot in a higher place the robot will be able to reach all the positions on the rack
without any problems (see next picture).

221
Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

Similarly it is possible to solve any singularity problem by laterally moving the rack. In
this case it is not necessary to change the height.

In any case the best solution can be found by means of an off-line simulation. In this way
it is possible to calculate the minimum displacement of the rack, either sideways, or up,
or down .
It is important to remember that SMART NJ4 models gives big advantages during
simulation because there aren’t any external cable on the forearm. This allows solving
any reachability problem during the work-cell design phase. At this time it will be
possible to choose the best location for the elements, the best gripper shape and robot
paths.

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.

222
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

As shown in the above pictures, such a solution allows the robot to follow a linear
trajectory exactly in front of it from up to down. It also allows to reach all the available
working area always maintaining the frontal position and the same orientation.
The same applies to spot-welding guns. If the work-cell layout is already defined, a small
angle can considerably improve the behavior of the robot. This method can also solve
the worst situations where the approach vector of the gun is exactly aligned with axis 6
(see par. 14.7.1.1 Changing the orientation of the points along the path on page 219).
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.

223
Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

224
 Comau Robotics Product Instruction

PRESUPPOSITIONS FOR SMART ROBOT PROGRAMMING

14.7.2 Conclusions
Many methods and hints have been given to increase the capabilities of SMART NJ4
robots inside the singularity zone. It has been demonstrated that in the most cases it is
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.

225
Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

15. COLLISION DETECTION

(OPTIONAL FEATURE)

Collision Detection
The option code is CR17926201.

15.1 Introduction
The Collision Detection algorithm (optional feature) allows the system to stop the robot
arm motion, as soon as any noise force on joints takes effect.
Such a capability can be enabled and disabled by the user, either from a Program
statement or a system Command

VERY IMPORTANT! Remeber that the Collision Detection functionality has been
designed to limit any damages to the robot mechanics 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.

Current chapter supplies information about the following topics:

– Basic concepts
– Enabling/Disabling the Collision Detection functionality
– Collision Detection working modes
– Operational tips
– Sample programs.

226
 Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

15.2 Basic concepts

– Basic information about the algorithm working principles
– Preliminary operations
– Working modes
– Basic tools for the functionality usage.

15.2.1 Basic information about the algorithm working principles

The algorithm operating mode is based on the comparison between the individual
motors actual currents and the values coming from the dynamic model which,
depending on the robot position, on its payload and on its inertia, can calculate in
advance the needed currents to move the robot itself. The collision functionality signals
the detected collision on one or more axes, to the user, if such currents difference is
reasonably enough.

So far, all Comau robots are provided with dynamic model; auxiliary axes are not.
Any auxiliary axes affecting the arm movement (e.g. a rail) could worsen the collision
functionality performance, up to cause false collisions to be detected.

15.2.2 Preliminary operations

The Collision Detection functionality is strictly dependent on a proper identification of
the used payload: an mis-estimated payload could cause a false collision to be
detected (e.g. false collision during the program normal execution).

For such a reason, the user should check that the current payload has properly been
identified, before activating the Collision Detection functionality.

It is then NEEDED that the payload is properly identified by means of its own variables:
– $TOOL_MASS
– $TOOL_CNTR
– $TOOL_INERTIA.
It is up to the user to
– insert the nominal data or use the inserire i dati nominali oppure utilizzare il
Automatic Payload identification (optional feature) program,
– update the payload values, when using applications in which the payload changes
during the working cycle (e.g. Pick & Place).

15.2.3 Working modes

TWO working modalities are available for the Collision Detection functionality:
– COLLISION - default mode at the system powerup, used to detect general
collisions which could occur in unpredictable ways, inside the robot working space

227
Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

(e.g. robot collision with the surrounding environment, wire stuck in a welding
operation, etc),
– SEARCH - special mode to manage specific object search and pick applications,
in order to handle light collisions whose occurrence is expected a priori (not
accidental collisions).

For any further operational information and details, refer to par. 15.4 Collision Detection
working modes on page 232.

15.2.4 Basic tools for the functionality usage

The following tools are available to use the Collision Detection functionality from within
PDL2 programs:
– CD_SET
– $COLL_ENBL
– $A_ALONG_1D[12]
– $COLL_EFFECT
– $A_AREAL_1D[57].

15.2.5 CD_SET
Built-in routine which allows to enable, disable, change modality, set the sensibility of
the Collision Detection functionality.
It affects the functionality performance both in COLLISION mode and in SEARCH mode.

For any further information, refer to PDL2 Language manual, chap.Built-in Routines
List, par.CD_SET Built-in Procedure.

15.2.6 $COLL_ENBL
When this predefined variable is TRUE, the Collision Detection functionality is enabled,
with immediate effect on any movements. It is a field of $CRNT_DATA.
By default, it is NOT reset (i.e. put to FALSE) at the DRIVE OFF; the algorithm remains
enabled until the user does not disable it intentionally, putting $COLL_ENBL flag to
FALSE.
Disabling at the DRIVE OFF can also be set to be automatic, by means of
$A_ALONG_1D[12] predefined variable.
Such a variable value is meaningful both in COLLISION mode and in SEARCH mode.

For any detailed information, refer to PDL2 Language manual, chap.Predefined

Variables List, par.$COLL_ENBL: Collision enabling flag.

228
 Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

15.2.7 $A_ALONG_1D[12]
By default, the Collision Detection functionality is NOT reset at the DRIVE OFF, it
remains enabled until the user does not disable it intentionally. Anyway the user can
ask for it to be automatically disabled at DRIVE OFF, by setting to 1 the bit 10 of such a
system variable, using BIT_SET built-in routine:

BIT_SET($ARM_DATA[num_arm].A_ALONG_1D[12], 10)

Bit 10 modification can be executed either at run-time or by means of .C5G configuration

file (which obviously can be saved).
Such a variable value is meaningful both in COLLISION mode and in SEARCH mode.

For any detailed information, refer to PDL2 Language manual, chap.Predefined

Variables List, par.$A_ALONG_1D: Internal arm data.

15.2.8 $COLL_EFFECT
It indicates the detected collision effect on the arm status. Refer to par. 15.4.1.2 Severity
of the collision error on page 232 for further details.
Such a variable value is meaningful in COLLISION mode only.

For any detailed information, refer to PDL2 Language manual, chap.Predefined

Variables List, par.$COLL_EFFECT: Collision Effect on the arm status.

15.2.9 $A_AREAL_1D[57]
The meaning of this variable value is described in par. 15.4.2 SEARCH mode on
page 233

$ARM_DATA[num_arm].A_AREAL_1D[57]:= vr_timeout

Such a variable value is meaningful in SEARCH mode only.

For any detailed information, refer to PDL2 Language manual, chap.Predefined

Variables List, par.$A_AREAL_1D: Internal arm data.

229
Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

15.3 Enabling/Disabling the Collision Detection

functionality

NOTE THAT
once enabled, the general issue is that the Collision Detection functionality remains
enabled until
– the user disables it intentionally (Disabling)
– the system is restarted
– the motors are put to DRIVE OFF (just in case of bit 10 set to 1 in
$A_ALONG_1D[12]).

– Enabling
– Disabling.

15.3.1 Enabling
Use one of the following ways to enable the Collision Detection functionality:
– set $COLL_ENBL predefined variable to TRUE
$CRNT_DATA[arm_num].COLL_ENBL := TRUE -- enable functionality
– use CD_SET built-in routine with whichever parameter (except COLL_DSBL)
CD_SET(COLL_HIGH, <$ARM>)
CD_SET(COLL_MEDIUM, <$ARM>)
CD_SET(COLL_LOW, <$ARM>)
CD_SET(COLL_SEARCH, <$ARM>).
– enable it using Motion Page - Status - Collision Detection (optional feature) (as
highlighted in the figure below).

CAUTION
Remember that, at STARTUP time, the algorithm is NOT automatically enabled.

15.3.2 Disabling
The Collision Detection functionality can be disabled in one of the following ways:
– put $COLL_ENBL predefined variable to FALSE

230
 Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

$CRNT_DATA[arm_num].COLL_ENBL : =FALSE -- disable functionality

– use CD_SET with COLL_DSBL

CD_SET (COLL_DSBL<,num_arm>) -- disable functionality

– disable it using Motion Page - Status - Collision Detection (optional feature)

(highlighted in the figure below).

As already stated, by default the Collision Detection functionality is NOT reset by the
system at each DRIVE OFF; it remains enabled instead until the user does not disable
it intentionally, by setting such a flag to FALSE, unless bit 10 of $A_ALONG_1D[12] is
used.

231
Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

15.4 Collision Detection working modes

– COLLISION mode
– SEARCH mode
– Changing the working mode.

15.4.1 COLLISION mode

The COLLISION mode is set as the default at the system powerup; it is the standard
working mode for the algorithm, i.e. to detect general collisions which could occur in
unpredictable ways, inside the robot working space (e.g. robot collision with the
surrounding environment, wire stuck in a welding operation, etc).
Upon a detected collision, the system reacts on the basis of three expected behaviours
which can be defined by the user by means of $COLL_EFFECT variable, according to
the modalities described in par. 15.4.1.2 Severity of the collision error on page 232.
The following topics are described below:
– Modifying the sensitivity
– Severity of the collision error.

15.4.1.1 Modifying the sensitivity

The algorithm can work using three different sensitivity levels: HIGH, MEDIUM and
LOW (default=LOW), which can be modified by the user by means of CD_SET built-in
routine:
– CD_SET(COLL_HIGH, <$ARM>)
– CD_SET(COLL_MEDIUM, <$ARM>)
– CD_SET(COLL_LOW, <$ARM>).

15.4.1.2 Severity of the collision error

The user can specify the severity of the collision error. To do so, $COLL_EFFECT
predefined variable (field of $ARM_DATA) must be used, setting it to the wished value:
– 0 to generate a DRIVE OFF upon the collision;
– 1 to set the system to HOLD status;
– 2 to generate system event 197 meaning “collision detected”.

In the last case above, the robot DOES NOT STOP, it continues the programmed
movement: it is the care of the user to properly handle the triggered event, by deleting
the current motion which otherwise would continue moving towards the obstacle, and
programming the new trajectory.
A sample program is provided in par. 15.6.2 Managing the ‘detected collision’ event on
page 237.

When $COLL_EFFECT=0, the following error is detected:

62513 – 10 SAX RILEVATA COLLISIONE

232
 Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

The command related to latched alarms must be used to reset it:

– UtilityLogLatchAcknowledge command, or
– Alarm Page, Ack command, when using the Teach Pendant.

15.4.2 SEARCH mode

This mode is to be used to manage specific object search applications , in order to
handle very light collisions whose occurrence is expected a priori (not accidental
collisions).
The SEARCH mode activation changes the algorithm parameters handling, in order to
make it sensible enough to detect even very light collisions. In this condition the
algorithm sensitivity is detached from the one defined for the COLLISION mode and
therefore cannot be modified by a built-in call.
Upon a collision, the system reacts by issuing a system event 197. In such a situation,
both changing from SEARCH mode to COLLISION mode, and issuing a new system
event 197, are inhibited until the algorithm does not detect any press for at least a
minimum time interval defined by $A_AREAL_1D[57] system variable (default is 70 ms).

The SEARCH mode is dedicated to object search and pick specific applications; for
such a reason, it must be used with very well defined robot motion features which avoid
false collisions arise and are compatible with the occurrence of an expected collision
and its management, preventing any damages to the gripper or the work-piece.
It is then suggested to use the SEARCH mode with not more than 15% speed and
acceleration/deceleration overrides ($ARM_SPD_OVR, $ARM_ACC_OVR and
$ARM_DEC_OVR). Note that the values may change depending on the machine model.

In the next sections the following topics are described:

– Modifying the sensitivity
– Severity of the collision error.

15.4.2.1 Modifying the sensitivity

NOT ALLOWED in this working modality.
In this mode, using the CD_SET built-in with any of the standard sensitivities
(COLL_HIGH, COLL_MEDIUM, COLL_LOW), causes switching the modality, i.e.
deactivating the SEARCH mode and activating the COLLISION mode.

15.4.2.2 Severity of the collision error

When the algorithm is in SEARCH mode, all collisions are notified by means of the
system event 197.
The $COLL_EFFECT variable value, in this modality, DOES NOT have any effects on
the algorithm functioning.

233
Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

The robot stop must then be explicitly handled by the user in a dedicated CONDITON
which monitors it.
Example:
CONDITION[2]NODISABLE:
WHEN EVENT 197 DO
LOCK -- locks the robot
CANCEL CURRENT -- cancels the current movement
...
...
...
ENDCONDITION

15.4.3 Changing the working mode

During the automatic execution of a user program, the system does not autonomously
perform any changing of the working mode, which then can be changed by the user by
means of the CD_SET built-in; at startup time only, the system automatically sets the
COLLISION mode.
A detailed description of how to change the modality is provided in the following
sections:
– From COLLISION mode to SEARCH mode
– From SEARCH mode to COLLISION mode.

15.4.3.1 From COLLISION mode to SEARCH mode

Changing from COLLISION mode to SEARCH mode, can be made in LOCAL and
REMOTE states only, using the CD_SET built-in

CD_SET (COLL_SEARCH<, num_arm>)

15.4.3.2 From SEARCH mode to COLLISION mode

Changing from SEARCH mode to COLLISION mode happens by means of one of the
following built-in calls:
– CD_SET (COLL_LOW<, num_arm>)
– CD_SET (COLL_MEDIUM<, num_arm>)
– CD_SET (COLL_HIGH<, num_arm>)
Changing the modality always involves choosing the Collision sensitivity.
This changing is just performed when the system does not detect any collision for at
least a minimum defined time interval. The default is 70 ms.
The user is allowed to modify such a minimum time by specifying the wished value in
the $A_AREAL_1D[57] system variable.
Thanks to this mechanism, the mode changing requested by the user, only takes effect
when the robot has released the press on the workpiece.

234
 Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

15.5 Operational tips

To customize the Collision Detection functionality, it is suggested to identify the
situations in which it is needed a higher or lower sensitivity, or even different Working
modes; such situations could be, for example:
– release movements
– short positioning movements
– technological movements (pick, place, welding, etc.).
In such situations, the user is allowed to choose to modify the sensitivity in different
program sections, by means of the CD_SET built-in, compatibly with the risk of false
collisions.

False collision
This is a collision detected by the Collision Detection functionality, but actually never
happened. The cause could be choosing a too high sensitivity for the associated
movement (e.g. a movement with high acceleration/deceleration.
This could happen if the sensitivity (COLL_LOW, COLL_MEDIUM, COLL_HIGH) has
been chosen without a proper analisys of the collision type to be protected from and then
it turns out to be too high for some specific movements in the program.

Note that increasing the sensitivity is directly proportional to the probability of false
collisions detection.

The user must know very well his/her own needs for the Collision Detection usage.
If it is an immediate and simple usage, the suggested strategy is to enable the
functionality and then to use, for example, one threshold only for any movement types
(e.g. trying with COLL_MEDIUM, then setting to COLL_LOW if any false collisions
occur).
The lack of such a strategy is that the chosen sensitivity is not fine tuned to have high
performancies. The merit, instead, is the fast setting.

235
Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

15.6 Sample programs

The following sample programs are provided:
– Enabling the Collision Detection functionality by means of a CONDITION
– Managing the ‘detected collision’ event
– Workpiece searching and picking.

15.6.1 Enabling the Collision Detection functionality by means of

a CONDITION

PROGRAM collision
VAR pnt0001j, pnt0002j, pnt0003j, pnt0004j : JOINTPOS FOR ARM[1]

ROUTINE set_coll_dsbl
BEGIN
CD_SET (COLL_DSBL)
END set_coll_dsbl

ROUTINE set_coll_high
BEGIN
CD_SET (COLL_HIGH)
END set_coll_high

BEGIN
CONDITION[1] :
WHEN AT START DO -- set high sensitivity at motion start
set_coll_high
ENDCONDITION

CONDITION[2] :
WHEN AT END DO -- disable the Collision functionality at motion end
set_coll_dsbl
ENDCONDITION

CD_SET (COLL_DSBL)
MOVE TO $CAL_SYS
...

CYCLE
CD_SET (COLL_LOW)

MOVE TO pnt0001j
MOVE TO pnt0002j

-- increase the sensitivity on a movement to be monitored

MOVE LINEAR TO pnt0003j WITH CONDITION[1], CONDITION[2]

MOVE TO pnt0004j
END collision

236
 Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

15.6.2 Managing the ‘detected collision’ event

A program section is provided below, as an example only, to manage the system event
197 of detected collision.

PROGRAM colltouch
VAR pnt0006p: POSITION

BEGIN

CONDITION[1] NODISABLE:
WHEN EVENT 94 DO -- U4 key pressed event
UNLOCK -- unlock the machine
RESUME -- for next restart
...
ENDCONDITION

CONDITION[2] NODISABLE:
WHEN EVENT 197 DO -- upon detected collision event
LOCK -- lock the machine
CANCEL CURRENT -- cancel the current movement
...
ENDCONDITION
...
ENABLE CONDITION[1]
ENABLE CONDITION[2]

$COLL_EFFECT:=2
CD_SET (COLL_LOW)

CYCLE
MOVE TO pnt0006p
...

END colltouch

237
Comau Robotics Product Instruction

COLLISION DETECTION (OPTIONAL FEATURE)

15.6.3 Workpiece searching and picking

PROGRAM searchmode PROG_ARM = 1

VAR jnt0001J, jnt0002J, pick_jpos, away_jpos, rel_jpos : JOINTPOS FOR ARM[1]

ROUTINE manage_collision
BEGIN
LOCK -- lock the machine
CANCEL CURRENT -- cancel current movement
CD_SET (COLL_MEDIUM) -- resume is performed at press end, after the waiting time
UNLOCK
RESUME
END manage_collision

ROUTINE set_coll_search
BEGIN
CD_SET (COLL_SEARCH) -- activate SEARCH mode
END set_coll_search

BEGIN
CONDITION[1]:
WHEN EVENT 197 DO -- detected collision event 197
manage_collision
ENDCONDITION

CONDITION[2] :
WHEN AT START DO -- activate SEARCH mode at MOVE start
set_coll_search
ENDCONDITION

CD_SET (COLL_LOW)
move to $cal_sys
...
CYCLE
MOVE TO jnt0001J -- approach movements
MOVE TO jnt0002J
...
MOVE LINEAR TO pick_jpos, -- object search movement
WITH CONDITION [1],
WITH CONDITION [2],
WITH $ARM_SPD_OVR = 15,
WITH $ARM_ACC_OVR = 15,
WITH $ARM_DEC_OVR = 15,
ENDMOVE
... -- handling workpiece pick
ToolFrame (4, 1) -- new tool, including the workpiece data

MOVE LINEAR TO away_jpos, -- press release movement

WITH $ARM_SPD_OVR = 15,
WITH $ARM_ACC_OVR = 15,
WITH $ARM_DEC_OVR = 15,
ENDMOVE
CD_SET (COLL_LOW)

MOVE LINEAR TO rel_jpos -- release movement

...
END searchmode

238
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

16. USE OF POSITIONERS MANAGED BY

C5GPLUS

16.1 Introduction
This chapter is addressed to the installers and maintenance engineers of the automated
cell, to supply them with the use procedures and the information needed for the Control
Unit software configuration so to obtain the correct management of the positioner
equipped with robot external axes.
In particular the need is underlined to carry out the positioner configuration customising
when this is not a standard product.

In any case, even with a standard positioner, the radius of the part overall dimensions
always has to be defined.

The positioners are divided into families, and a paragraph is dedicated to each of them.
The procedures and conventions contained in the following paragraphs are very
important to ensure the consistency of the installation and above all the correct
functioning of the system when, for example, the cooperative motion is used, i.e. the
enslavement of a robot in the position of the part to be processed mounted on the
positioner.

It is the responsibility of the positioner designer to check and guarantee that the unit
operates in conformity with the relevant standards. In particular it must be verified that
in the following situations:
– normal use (Automatic/Programming),
– emergency stop,
– safety braking,
– Hold,
– Drive off,
– impact on any mechanical pads
the unit behaves in a manner that complies with current safety standards.

16.2 Summary

The following subjects:

– USE of the Teach Pendant (use of the external axes configuration software)
– automatic calculation for the positioner BASE ,
are dealt with in C5GPlus Control Unit Use manual, respectively in:
– par. 5.17.2.15 Posit on page 278 and par. 5.17.2.16 Posit_Arm on page 281
– par. 12.5 BASE automatic calculation for positioners on page 618.

239
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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 Conventions

Conventions 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. TOOL, UFRAME and Positioners BASE
automatic calculation on page 582).

For special conventions and specifications of each positioner, see the relevant
paragraph for that particular model or family.

– Axis rotation directions

– Convention for the mechanical positioning of points P1, P2 and P3

16.3.1 Axis rotation directions

The directions of the positioner axis rotations cannot be chosen at will: they have to
strictly follow the convention in which the axes have a positive anticlockwise direction (in
relation to the rotation axis).

In other words they have to follow the right-hand rule referring to the direction indicated
in Fig. 16.1 in correspondence to the axes: pointing the thumb of the right hand in the
direction of the dashed line arrow (that represents each axis), the fingers are to close in
the positive direction of the rotating axis. For this description, the orbital positioner has
been chosen because it is particularly representative.

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. TOOL, UFRAME and

240
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

Positioners BASE automatic calculation on page 582 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);
– 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, Obase

Xf, Yf, Zf, Of = Xflange, Yflange, Zflange, Oflange

16.4 Programming override value calculation

To comply with the safety standards in force for robots and positioners, a configuration
tool is provided on the Teach Pendant (Setup page, Posit sub-page). This calculates the
speed value in manual mode.
The following formula is used:

241
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

where:
250 = maximum speed allowed as per standard [mm/s]
955 = numeric conversion factor
Rt = motor transmission ratio [Mt/axt]
Vm = motor maximum speed [Rpm]
r = part overall dimension radius [mm]

MAXIMUM PROGRAMMING SPEED

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

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. TOOL,
UFRAME and Positioners BASE automatic calculation on page 582 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).

242
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

If, operating with the Teach Pendant, the controlled axis moves in the opposite direction
to this rule, the transmission ratio sign must be changed using the Teach Pendant

16.5.2 Calibration
The lathe positioner does not require special rules for the calibration position.

16.5.3 Kinematic description

To configure such positioners, see C5GPlus Control Unit Use Manual, Setup page,
par. 5.17.2.15 Posit on page 278.

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.

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

243
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

OPTION AXIS VALUE

Axis length [mm] 7 /
Type of axis 7 ROTATING
Axis offset [mm] 7 /
Programmed speed override 7 X

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.

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

244
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

Also the convention should be borne in mind that concerns points P1, P2, P3 described
in the Chap. TOOL, UFRAME and Positioners BASE automatic calculation on page 582
to calculate $BASE (or $AUX_BASE) of the positioners (see Fig. 16.4).

Fig. 16.4 - Definition of the reference system

1 - axis 1 2 - axis 2 Xf, Yf = Xflange, Yflange Xb, Yb = Xbase, Ybase

16.6.1.3 Kinematic description

To configure such positioners, see C5GPlus Control Unit Use Manual, Setup page,
par. 5.17.2.15 Posit on page 278.

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.

245
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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 a positioner formed by auxiliary axes 7 and 8: ax_logic1 = 7 e ax_logic2 = 8

If the part has overall dimensions that are less than the diameter of the bearing plate, r2
is to be equal to the radius of the bearing plate. This is to always consider the worst case
of part maximum overall dimensions or of the mechanical structure of the positioner in
motion.

Next, the configuration software, on the Teach Pendant, calculates the manual mode
speed value.
Two tables follow, summarising the useful mechanical data, assuming that the
positioner is handled with auxiliary axes 7 and 8 respectively.

OPTION AXIS VALUE

Axis length [mm] 7 L1
Axis type 7 ROTATING
Axis offset [mm] 7 /
Program speed override 7 X1

OPTION AXIS VALUE

Axis length [mm] 8 /
Axis type 8 ROTATING
Axis offset [mm] 8 L2
Program speed override 8 X2

246
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

It is possible to manage a positioner with 2 degrees of freedom, type perpendicular

TDB-TLS with a variable length of the second axis (L2 in the schemes of documentation)
manually changeable, by setting the dedicated variable
$CNRT_DATA[arm_num].VAR_OFST[n_ax]
at the beginning of the motion program.
This setting does not need a re-configuration of the positioner or a saving and reboot.

16.6.2 Positioner with two axes in "L" arrangement

16.6.2.1 Definition of the reference system

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 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 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;
– the Zflange axis is perpendicular to the flange surface with outward direction.

16.6.2.1.1 Calibration
The conventions for the calibration are as follows:
– The first axis is to be calibrated so that the Zflange axis is aligned to Zbase;
– The second axis is to calibrate with all the flange reference axes parallel to the
corresponding base reference; in particular Yflange is to be parallel to Ybase and
have the same direction.

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

Also the convention is to be borne in mind that concerns points P1, P2, P3 described in
Chap. TOOL, UFRAME and Positioners BASE automatic calculation on page 582 to

247
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

calculate the $BASE (or $AUX_BASE) of the positioners (see Fig. 16.6).

Fig. 16.6 - Definition of the reference system

1 - axis 1 2 - axis 2 Xb, Yb, Zb, Ob= Xbase, Ybase, Zbase, Obase
Xf, Yf, Zf, Of = Xflange, Yflange, Zflange, Oflange

16.6.2.2 Kinematic description

To configure such positioners, see C5GPlus Control Unit Use Manual, Setup page,
par. 5.17.2.15 Posit on page 278.

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

248
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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

If the part has overall dimensions that are less than the diameter of the bearing plate, r2
is to be equal to the radius of the bearing plate; in the same way for r1 a minimum value
is to be used equal to r1m to take into consideration the mechanical structure of axis 7.
This is to always consider the worst case of part maximum overall dimensions or of the
mechanical structure of the positioner in motion

Next, the configuration software, on the Teach Pendant, calculates the manual mode
speed value.
Two tables follow that summarise the useful mechanical data, assuming that the
positioner is handled with auxiliary axes 7 and 8 respectively.

OPTION AXIS VALUE

Axis length [mm] 7 L1
Axis type 7 ROTATING
Axis offset [mm] 7 /
Program speed override 7 X1

OPTION AXIS VALUE

Axis length [mm] 8 /
Axis type 8 ROTATING
Axis offset [mm] 8 -L2
Program speed override 8 X2

249
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

It is possible to manage a positioner with 2 degrees of freedom of "L" type with a variable
length of the second axis (L2 in the schemes of documentation) manually changeable,
by setting the dedicated variable
$CNRT_DATA[arm_num].VAR_OFST[n_ax]
at the beginning of the motion program.
This setting does not need a re-configuration of the positioner or a saving and reboot.

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 Zbase axis is perpendicular to the bearing surface and in upward direction;
– 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;
– the Zflange axis is perpendicular to the flange surface with outward direction.

250
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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

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.

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

Also the convention is to be borne in mind that concerns points P1, P2, P3 described in
the Chap. TOOL, UFRAME and Positioners BASE automatic calculation on page 582 to
calculate the $BASE (or $AUX_BASE) of the positioners (see Fig. 16.8).

16.7.3 Kinematic description

To configure such positioners, see C5GPlus Control Unit Use Manual, Setup page,
par. 5.17.2.15 Posit on page 278.

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

251
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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] = L2
For example, for a positioner formed by auxiliary axes 7 and 8: ax_logic1 = 7 e ax_logic2 = 8

If the part has overall dimensions that are less than the diameter of the bearing plate, r2
is to be equal to the radius of the bearing plate r2m; in the same way for r1 a minimum
value is to be used equal to r1m to take into consideration the mechanical structure of
axis 7. This is to always consider the worst case of part maximum overall dimensions or
of the mechanical structure of the positioner in motion..

Next, the configuration software, on the Teach Pendant, calculates the manual mode
speed value.
Two tables follow, summarising the useful mechanical data, assuming that the
positioner is handled with auxiliary axes 7 and 8 respectively.

OPTION AXIS VALUE

Axis length [mm] 7 L1
Axis type 7 ROTATING
Axis offset [mm] 7 *
Program speed override 7 X1

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 length [mm] 8 L3

252
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

Axis type 8 ROTATING

Axis offset [mm] 8 L2
Program speed override 8 X2

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:
– The Cartesian positions (POSITION) are defined in the cell space regardless of the
linear slide axis position and therefore moving only the slide will change the
Cartesian position;
– Manually moving the slide (jog) in a Cartesian reference (for example jog BASE),
the TCP position remains unchanged due to the displacement of the robot axes
that offset the displacement.

On the Teach Pendant the linear axis can be moved in Cartesian mode, using the 7+
and 7- keys and it is not possible to enable or disable the slide integration in real time (a
Controller restart is needed).

16.8.1.1 Definition of the reference system

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 Zbase axis is perpendicular to the bearing surface and in upward direction;
– 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

253
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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

Fig. 16.10- Definition of the reference system

1. slide base reference

2. robot base
Xbs, Ybs, Zbs = Xbase_slide, Ybase_slide, Zbase_slide
Xbr, Ybr, Zbr = Xbase_robot, Ybase_robot, Zbase_robot

16.8.1.2 Calibration
The slide calibration position is fixed close to the negative limit of the stroke and marked
with a zero notch.
Since this is an integrated axis it is not treated as a positioner for the part to be machined
and therefore it is not necessary to pick up points P1, P2 and P3 described in the
Chap. TOOL, UFRAME and Positioners BASE automatic calculation on page 582.

16.8.1.3 Kinematic description

To configure such positioners, see C5GPlus Control Unit Use Manual, Setup page,
par. 5.17.2.17 Rail on page 282.

The parameters needed for the correct kinematic description of the integrated slide are
indicated in Fig. 16.11.
Next, the configuration software, on the Teach Pendant, calculates the manual mode
speed value.
A table follows summarising the useful mechanical data, bearing in mind that it is
mandatory that the integrated slide is handled with auxiliary axis 7.

254
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

OPTION AXIS VALUE

Axis length [mm] 7 L
Axis type 7 TRANSLATING
Axis offset [mm] 7 /
Program speed override 7 X

Fig. 16.11- Parameters for the kinematic description of the integrated

slide

L = slide useful stroke

Xbs, 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;
– 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

255
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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 ;

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 disable the column integration in real time.

16.8.2.1 Definition of the reference system

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 Zbase axis is perpendicular to the bearing surface and in upward direction;
– 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
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.

Fig. 16.13- Definition of the reference system

1 - column rotation 2 - column base reference 3 - robot base Xb, Yb, Zb = Xbase, Ybase, Zbase

256
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

16.8.2.2 Calibration
The column calibration position is determined half way along the useful stroke and
marked by a zero notch. As this is an integrated axis it is not treated as a positioner of
the part to be machined and therefore it is not necessary to find points P1, P2 and P3
described in the Chap. TOOL, UFRAME and Positioners BASE automatic calculation on
page 582.

16.8.2.3 Kinematic description

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.

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

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

257
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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.

Usually, on the Teach Pendant, the auxiliary axes cannot be jogged in cartesian mode
(TOOL, BASE, UFRAME): in case of integrated portals it is allowed to joint move the
linear axes when jog is set to cartesian, using the keys corresponding to the axes,
obtaining the effect of moving the joint keeping still the robot TCP position.
Furthermore, to help in programming, the JPAD keys have been re-configured in order
to move each of the portal individual axis.
For further information related to auxiliary axes and JPAD, refer to C5GPlus Control Unit
Use manual - par. 5.3.1.2 Black keys on page 59 - Chap. TP5 Teach Pendant on
page 52.

258
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

16.8.3.1 Definition of the reference system

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

16.8.3.2 Calibration
The calibration position of the Portal, is usually defined close to the negative stroke of
each auxiliary axis, marked with a zero notch.

16.8.3.3 Kinematic description

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.

259
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

To configure the 3 linear axes portal, refer to C5GPlus Control Unit Use manual, Setup
page, par. 5.17.2.14 Portal on page 277.

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.

OPTION AXIS VALUE

Axis length [mm] 7 L1
Axis type [Tras/Rot] 7 TRANSLATING
Axis offset [mm] 7 H
Axis type [Coord] 7 [X,Y,Z]
Axis length [mm] 8 L2
Axis type [Tras/Rot] 8 TRANSLATING
Axis type [Coord] 8 [X,Y,Z]
Axis length [mm] 9 L3
Axis type [Tras/Rot] 9 TRANSLATING
Axis type [Coord] 9 [X,Y,Z]

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.

16.8.4 Two linear axes Portal

The current section describes the configuration of a robot mounted on a portal

260
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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.

Usually, on the Teach Pendant, the auxiliary axes cannot be jogged in cartesian mode
(TOOL, BASE, UFRAME): in case of integrated portals it is allowed to joint move the
linear axes when jog is set to cartesian, using the keys corresponding to the axes,
obtaining the effect of moving the joint keeping still the robot TCP position.
Furthermore, to help in programming, the JPAD keys have been re-configured in order
to move each of the portal individual axis.
For further information related to auxiliary axes and JPAD, refer to C5GPlus Control Unit
Use manual - par. 5.3.1.2 Black keys on page 59 - Chap. TP5 Teach Pendant on
page 52.

16.8.4.1 Definition of the reference system

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

261
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

Fig. 16.18- Definition of the reference system

16.8.4.2 Calibration
The calibration position of the Portal, is usually defined close to the negative stroke of
each auxiliary axis, marked with a zero notch.

16.8.4.3 Kinematic description

To configure the 2 linear axes portal, refer to C5GPlus Control Unit Use manual, Setup
page, par. 5.17.2.14 Portal on page 277.

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.

OPTION AXIS VALUE

Axis length [mm] 7 L1
Axis type [Tras/Rot] 7 TRANSLATING
Axis offset [mm] 7 H
Axis type [Coord] 7 [X,Y,Z]
Axis length [mm] 8 L2
Axis type [Tras/Rot] 8 TRANSLATING
Axis type [Coord] 8 [X,Y,Z]

262
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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

Usually, on the Teach Pendant, the auxiliary axes cannot be moved in jog when in
cartesian mode (TOOL, BASE, UFRAME): in case of trans-rotational column it is
allowed to joint move the linear axes when jog is set to cartesian, using the keys
corresponding to the axis, obtaining the effect of moving the joint keeping still the robot
TCP position.
Furthermore, to help programming, the JPAD keys have been re-configured in order to
move each of the portal individual axis.
For further information related to auxiliary axes keys and JPAD, refer to C5GPlus
Control Unit Use manual - par. 5.3.1.2 Black keys on page 59 - Chap. TP5 Teach
Pendant on page 52.

16.8.5.1 Definition of the reference system

The base reference system of the Trans-rotational Column is defined according to the

263
Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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

Fig. 16.20- Definition of the reference system

16.8.5.2 Calibration
The Column calibration position is defined at mid-stroke, marked with a zero notch; the
Rail calibration position is usually defined close to the negative stroke of the auxiliary
axis, marked with its zero notch.

16.8.5.3 Kinematic description

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

264
 Comau Robotics Product Instruction

USE OF POSITIONERS MANAGED BY C5GPLUS

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

OPTION AXIS VALUE

Axis length [mm] 7 L
Axis type [Tras/Rot] 7 TRANSLATING
Axis offset [mm] 7 H1
Axis length [mm] 8 R
Axis type [Tras/Rot] 8 ROTATIONAL
Axis offset [mm] 8 H2

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 .

265
Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

17. INTERFERENCE REGIONS (OPTIONAL

FEATURE)

Interference Regions
The option code is CR17926216.
To use Cartesian Hybrid Regions, the following option is required:
Advanced Interference Regions
The option code is CR17926218.

17.1 Introduction
Interference Regions are interference/interchange volumes shared between Robot and
Robot, and between Robot and structures.
Their handling allows to interact among machines, optimizing the use of the cell inside
space, in order to guarantee the collision prevention, upon defining the geometry of the
Robot working zone inside volumes.
In the Interference Regions handling system, a library has been created of basic
geometrical shapes allowing to support most functional cases, to control both cartesian
and joint working areas.
Both for cartesian and joint case, it is allowed to define 16 geometrical regions to be
used both to monitor and block the Robot to enter them.
– Regions types
– Regions Shape and definition
– IR_LIB library to support Interference Regions creation
– Examples.

17.2 Regions types

Two kind of Regions are defined:
– Forbidden Regions
• Cartesian Forbidden and Allowed Regions
• Joint Forbidden Regions
– Monitored Regions
• Cartesian Monitored Regions
• Joint Monitored Regions.
– Hybrid Regions
• Cartesian Hybrid 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

266
 Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

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.

17.2.1 Cartesian Forbidden and Allowed Regions

In these Regions the TCP (Tool Center Point) will never be allowed to either enter
(Forbidden) or exit (Allowed). 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
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 either NEVER enter (Forbidden) or NEVER EXIT from
(Allowed), and also should NEVER work in close proximity of its boundaries, at
maximum speed. The Robot, in fact, slows down its motion proportionally to the distance
from the specified region surface.

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

Such a logical port is associated to the region by means of the IR_SET built-in routine
(see chap.BUILT-IN Routines List - PDL2 Programming Language manual, for a
detailed description).

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

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

267
Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

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

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.

17.2.5 Cartesian Hybrid Regions

Note that, as already stated, the following option is required for using the Cartesian
Hybrid regions:
Advanced Interference Regions
code CR17926218.

The Cartesian Hybrid Regions are regions that change their behaviour depending on an
input signal (IR_CONSENT).
The two allowed behaviours are similar the “Monitored Region” one if IR_CONSENT =
TRUE or to the "Forbidden Region" one if IR_CONSENT = FALSE.

CAUTION - please note that Hybrid Monitored Regions and Hybrid Forbidden Regions
are SIMILAR to Monitored Regions and Forbidden Regions, respectively, but they are
NOT THE SAME. So, it is strongly recommended to carefully read the corresponding
descriptions.

– Status IR_CONSENT = TRUE, the region is Hybrid Monitored and the Robot is
allowed to enter it; the actual position is specified by means of two output signals:
• TCP inside the hybrid region
• IR_PRESENCE = TRUE
• IR_RESERVATION = TRUE
• TCP close to the hybrid region (inside the warning region)
• IR_PRESENCE = FALSE
• IR_RESERVATION = TRUE
• TCP far from the hybrid region (outside the warning region)
• IR_PRESENCE = FALSE
• IR_RESERVATION = FALSE
– Status IR_CONSENT = FALSE, the region is Hybrid Forbidden, the Robot access
is denied, no system errors occur. Moreover, the actual position is specified by
means of two output signals:
• TCP inside the hybrid region - impossible, the attempting to enter Robot is
decelerated and stopped onto the region boundary. It is then put to LOCKed
state
• TCP close to the hybrid region (inside the warning region)
• IR_PRESENCE = FALSE
• IR_RESERVATION = TRUE

268
 Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

The speed is modified depending on the distance from the hybrid region
boundary.
• TCP far from the hybrid region (outside the warning region)
• IR_PRESENCE = FALSE
• IR_RESERVATION = FALSE
– Transition of IR_CONSENT from FALSE to TRUE - If any pending motion exists
in LOCK state (automatically set by the system in case of Robot close to a Hybrid
Forbidden Region), an UNLOCK command is executed on the Robot arm which
will then automatically resume its program execution.
– Transition of IR_CONSENT from TRUE to FALSE - If the robot TCP was inside
the hybrid region just a moment before (i.e. when IR_CONSENT = TRUE the robot
was allowed to enter), an error occurs and the robot is immediately stopped. On
the contrary, the region is simply switched from Hybrid Monitored Region to Hybrid
Forbidden Region.

Presence, Reservation and Consent logical ports are associated to the region by means
of the IR_SET built-in routine (see chap.BUILT-IN Routines List - PDL2 Programming
Language manual, for a detailed description).

Example

IR_SET(IR_RESERVATION,$FMO[1],1,1,ON)
IR_SET(IR_PRESENCE,$FMO[1],2,1,OFF)
IR_SET(IR_CONSENT,$FMI[1],1,1,ON)

17.3 Regions Shape and definition

– Cartesian Regions shape and definition
– Joint Regions shape and definition.

17.3.1 Cartesian Regions shape and definition

There are four shapes for Cartesian Regions:
– Sphere
– 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. 17.4 IR_LIB library to support
Interference Regions creation on page 272.
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.

269
Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

17.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. 17.1 - Sphere

R - radius

17.3.1.2 Cylinder
By means of sequentially teaching points P1 and P2, the frame and the cylinder height
are defined. The radius is assigned by the User at the end of the guided teaching
procedure.
In details:
– P1 defines the frame origin.
– P2 defines cylinder height and orientation.

Fig. 17.2 - Cylinder

H - height R - radius

17.3.1.3 Box
By means of sequentially teaching P1, P2, P3 points, frame and two dimensions (width
and depth), are defined, whereas by means of teaching P4 point height is defined. In

270
 Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

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 defines the frame origin.
– P2 defines width axis.
– P3 defines base plane and depth.
– P4 defines height.

Fig. 17.3 - Box

H - height W - width D - depth

17.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. 17.4.

Fig. 17.4 - Plane

17.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:

271
Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

– 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 Interface.
– Specify the allowed stroke ends.
The axes are first positioned 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. 17.4 IR_LIB library to support Interference Regions creation on
page 272.

17.4 IR_LIB library to support Interference Regions

creation
By means of this library, automatically loaded in memory at the Controller Unit Startup,
the User can intuitively declare the wished joint and cartesian Interference Regions.
To create a Joint Region, the following routine is to be called in the PDL2 program:
– IR_CreateJoint (aj_neg_joint, aj_pos_joint, ai_num_arm, ai_mask, ai_t_idx)
This routine must be imported in the calling program, as follows:

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

To create Cartesian Regions, instead, according to the previously described geometric

shapes, the following routines are to be called in the PDL2 program:
– Regions related to the WORLD reference frame
– Regions related to the currently active UFRAME.

17.4.1 Regions related to the WORLD reference frame

– 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)
– IR_CreateSimplePlane (ap_p1, ai_ornt, ab_side, ai_num_arm, ai_t_idx) .
Such routines are to be imported by the calling program, in the following way:

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

272
 Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

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_CreateSimplePlane (ap_p : POSITION; ai_ornt : INTEGER, ab_side :
BOOLEAN, ai_num_arm, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL
or by means of the IMPORT statement:

IMPORT ‘IR_DEF’

17.4.2 Regions related to the currently active UFRAME

If the defined Region is related to the currently active UFRAME, if such UFRAME
changes, the Region moves as a consequence.

– IR_CreateSphereUF (ap_p1, ar_R, ai_num_arm, ai_t_idx)

– IR_CreateCylinderUF (ap_p1, ap_p2, ar_R, ai_num_arm, ai_t_idx)
– IR_CreateBoxUF (ap_p1, ap_p2, ap_p3, ap_p4, ai_num_arm, ai_t_idx)
– IR_CreatePlaneUF (ap_p1, ap_p2, ap_p3, ai_num_arm, ai_t_idx)
– IR_CreateSimplePlaneUF (ap_p1, ai_ornt, ab_side, ai_num_arm, ai_t_idx) .
Such routines are to be imported by the calling program, in the following way:

ROUTINE IR_CreateSphereUF (ap_p1 : POSITION; ar_R : REAL; ai_num_arm ai_t_idx :

INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL
ROUTINE IR_CreateCylinderUF (ap_p1, ap_p2 : POSITION; ar_R : REAL; ai_num_arm,
ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL
ROUTINE IR_CreateBoxUF (ap_p1, ap_p2, ap_p3, ap_p4 : POSITION; ai_num_arm,
ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL
ROUTINE IR_CreatePlaneUF (ap_p1, ap_p2, ap_p3 : POSITION; ai_num_arm, ai_t_idx :
INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL
ROUTINE IR_CreateSimplePlaneUF (ap_p : POSITION; ai_ornt : INTEGER, ab_side :
BOOLEAN, ai_num_arm, ai_t_idx : INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL

or by means of the IMPORT statement:

IMPORT ‘IR_DEF’

17.4.3 Example 1
An example follows to define a cylindrical cartesian region from within a program:

273
Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

-- Cylinder definition: base=pnt0007P, height=pnt0008P, radius=200 mm,

-- used for arm 1, Interference Region number 3
IR_CreateCylinder(pnt0007P, pnt0008P, 200, 1, 3)

-- Associating Cartesian Region number 3 to digital output $FMO[1], bit 2,

-- indicating that it is monitored
IR_SET($FMO[1], 2, 3, IR_PRESENCE, OFF)

-- Activating Cartesian Region number 3

IR_SWITCH(ON, 3)

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], each time the TCP enters such a Region.

17.4.4 Example 2
In the following example a PDL2 program section is shown which creates a Joint
Monitored Region for axis 6 only.

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_num_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_num_arm,ai_mask,4)

-- Associating Joint Region number 4 to digital output $FMO[1], bit 3, indicating

that it is monitored
IR_SET($FMO[1], 3, 4, IR_PRESENCE, ON)

-- Activating Joint Region number 4

IR_SWITCH(ON, 4)

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 immediately set to ON, as
declared by IR_SET($FMO[1],3,4, ON) built-in routine.

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.

274
 Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

17.5 Examples
– Sample program for Cartesian Interference Regions
– Sample program for a Joint Interference Region.

275
Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

17.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 = 1

VAR 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 GLOBAL
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_CreatePlane(ap_p1, ap_p2, ap_p3 : POSITION; ai_num_arm, ai_t_idx :
INTEGER) : BOOLEAN EXPORTED FROM IR_LIB GLOBAL
ROUTINE 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 --> box
IR_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

276
 Comau Robotics Product Instruction

INTERFERENCE REGIONS (OPTIONAL FEATURE)

17.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 = 1

VAR 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 jnt0023J
END ir_jnt

277
Comau Robotics Product Instruction

AXES PURSUIT (OPTIONAL FEATURE)

18. AXES PURSUIT (OPTIONAL FEATURE)

Axes Pursuit
The option code is CR17926217.

18.1 Introduction
The Axes pursuit functionality makes it possible moving, both in Automatic and
Programming mode, one or more axes belonging to one Arm (called the MASTER)
allowing one or more axes of a different Arm (called the SLAVE) to pursue the MASTER
Arm axes.
– Axes Pursuit
– Error handling when Axes Pursuit functionality is active
– Configuring the software option.

18.2 Axes Pursuit

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

278
 Comau Robotics Product Instruction

AXES PURSUIT (OPTIONAL FEATURE)

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.

18.3 Error handling when Axes Pursuit functionality is

active

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.

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.

18.4 Configuring the software option

To 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 and defining the pursuing direction (by means of indicating
+/- sign on the axis number).

279
Comau Robotics Product Instruction

AXES PURSUIT (OPTIONAL FEATURE)

Example:
$AX_PURSUIT_ARM_MASTER := 1 -- indicates the MASTER Arm is
-- Arm 1

$ARM_DATA[2].AX_PURSUIT_LINKED[3] := 7 -- indicates axis 3 of

-- Arm 2 (SLAVE)
-- pursues axis 7 with
-- negative sign of
-- Arm 1 (MASTER)

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

280
 Comau Robotics Product Instruction

LOW RESOLUTION EULER ANGLES (OPTIONAL FEATURE)

19. LOW RESOLUTION EULER ANGLES

(OPTIONAL FEATURE)

Low Resolution Euler Angles

The option code is CR17926219.

A software option exists which allows to always have lower precision in small orientation
variations around X and Y axes.
Using such an option, the precision is 0.2 degrees, instead of 0.02 degrees, default
value.
Such a functionality is useful when creating POSITION type points is required, e.g. by
means of the ‘:’ operator.
It is exactly like using bit 23 of $CNTRL_INIT predefined variable. For further
information, please refer to PDL2 Programming Language manual - chap. Predefined
Variables List.

281
Comau Robotics Product Instruction

PALLETIZING FUNCTIONALITY (OPTIONAL FEATURE)

20. PALLETIZING FUNCTIONALITY (OPTIONAL

FEATURE)

Palletizing Motion
The option code is CR17926214.

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.

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.

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.

20.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:

282
 Comau Robotics Product Instruction

PALLETIZING FUNCTIONALITY (OPTIONAL FEATURE)

– from within a PDL2 Program - call ARM_PALLETIZING (ON, <arm_num>)

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

For further information, please refer to PDL2 Programming Language manual -

BUILT-IN Routines List chapter.

– from Teach Pendant - select the required Arm and move focus to the
Palletizer Status (see Fig. 20.1 - yellow highlighted field), so that Enable key
is displayed. Touch it to enable the functionality (see Fig. 20.1 - red
highlighted key).

Fig. 20.1 - Palletizing Funtionality on the TP - enabling

Upon the functionality enabling, ‘Pallet’ string is displayed in the status bar (see Fig. 20.2
- purple highlighted field).

NOTES
– Since the activation moment, it will NOT be possible to jog the robot axes which
are bind to keep the second Euler angle geometry to 180° (which means to have
the flange position parallel to the floor), and axis 4.
– In the trajectory generation, the system will automatically take care of computing
optimized trajectory for palletizing operations.
– It is allowed to use the robot as a Palletizer, both in programming mode and in
automatic cycle.

20.2 Disabling

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

To disable the Palletizing Functionality and recover the usual robot functioning again, it
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”

283
Comau Robotics Product Instruction

PALLETIZING FUNCTIONALITY (OPTIONAL FEATURE)

For further information, please refer to PDL2 Programming Language manual -

BUILT-IN Routines List chapter.

– from Teach Pendant - move focus to the Palletizer Status (see Fig. 20.2 - yellow
highlighted field), so that Disable key is displayed. Touch it to disable the
functionality (see Fig. 20.2 - red highlighted key).

Fig. 20.2 - Palletizing Functionality on TP - disabling

20.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 300
MOVEFLY LINEAR TO pnt0002P ADVANCE
MOVEFLY LINEAR NEAR pnt0003P BY 20 ADVANCE
MOVE LINEAR TO pnt0003P
MOVEFLY LINEAR AWAY 400 ADVANCE
MOVEFLY JOINT TO pnt0004P ADVANCE
MOVEFLY LINEAR TO pnt0005P ADVANCE
MOVEFLY LINEAR NEAR pnt0006P BY 300 ADVANCE
MOVEFLY LINEAR TO pnt0006P ADVANCE
MOVEFLY LINEAR NEAR pnt0007P BY 20 ADVANCE
MOVE LINEAR TO pnt0007P
MOVEFLY LINEAR AWAY 1000
ARM_PALLETIZING(OFF,1)
END test_arm_palletizing

284
 Comau Robotics Product Instruction

ROBOT ABSOLUTE ACCURACY

21. ROBOT ABSOLUTE ACCURACY

Robot Absolute Accuracy

The option code is CR17926208.

21.1 Introduction
This system improves the robot positioning accuracy inside the work area.
This software option compensate the following errors:
– kinematic errors caused by the inaccuracy of the robot levers lengths,
– errors caused by the improper axes coupling (axes orthogonality),
– flexure errors due to the mechanical parts wheight.

21.2 Notes for a proper use

In the current chapter some notes are provided, in order to define peculiarities and
proper usage of this software option performance.
In order that the kinematic errors compensation can be activated on a robot, the file
containing the kinematic model is required: such a file has .rob extension. Its name is
composed as follows:

<$SYS_ID>_<narm>.rob (e.g. CNTRLC5G_9999999_1.rob)

and, from 2.31.014 version on, as a different choice for a better robot identification, the
file name can also be as follows:

<$SYS_ID>_<$ARM_ID>_<narm>.rob (e.g. C5G_9999999_NJ4_2400001_1.rob)

Each robot is provided with its specific file which cannot be used by any other robots.
A maximum of 4 arms for each system is allowed, and each one could be provided with
a file identifying its own kinematic model.
All .rob files are saved on the Control Unit, in UD:\SYS folder.
In order to check whether the kinematic compensation is active, either open the
Motion-Status page on the Teach Pendant, or view the joint/cartesian positions and
check the presence of an explanatory character, related to the compensation on such a
position, with the following meaning:
– r : indicates that either a movement is in progress or the compensation has not
been executed on the current position so the displayed position is real
(compensated);
– n : indicates that the compensation has been executed on the current position, so
the displayed position is the nominal one (i.e. IDEAL);
– d : indicates that the compensation algorithm is currently disabled.

285
Comau Robotics Product Instruction

ROBOT ABSOLUTE ACCURACY

The kinematic compensation acts while the program is running, on the motion
statements final position.
This means that for each NOMINAL position (i.e. IDEAL positions - typically generated
by CAD systems) the compensation algorithm is applied which in turn generates a
corresponding position called COMPENSATED (i.e. REAL), where the robot is moved
to, in order to improve the positioning accuracy on the nominal point.
It is recommended to increase the points density, for a better trajectory accuracy.
The compensation software only works when the robot is out from singularity areas
(where the user is not allowed to move the robot to the required position). Anyway,
during the positions teaching phase, the programmer should be able move close to the
singularity position in order to find a nearby position which can be compensated. To do
so, the following command is available

SET ARM NOSTROKE

which disables the compensation algorithm for 60 seconds. In such lapse of time the
user can reach the target and teach a new position.
The displayed joint and cartesian position values, are NOMINAL (IDEAL) values with
steady robot only (controlled on the final position). What is displayed while the robot is
moving, is referred to the kinematic compensation world.
The returned value from ARM_POS and ARM_JNTP PDL2 built-ins, represents the
robot NOMINAL position with steady robot only (controlled on the final position).
The returned value from HDIN_READ and HDIN_SET PDL2 built-ins, represents the
robot NOMINAL position.
The user can calculate the compensation effects by using POS_IDL_COMP and
POS_COMP_IDL system built-ins. Refer to PDL2 Programming Language manual for
further details. Note that such built-ins don’t act in close way (they don’t return exactly
the original position if applied in cascade).
For a proper robot programming, with active compensation, keep the $CNFG_CARE
system variable value to TRUE.
The variables taught by means of the Teach Pendant are NOMINAL type: anyway note
that such operation is not recommended, because the algorithm gives the highest
performance with offline defined positions.
Thus, any procedures which include teaching positions requires the following
precautions:
– it is recommended to use the TOOL MASTER procedure, and avoid the 4 points
procedure;
– when calculating the positioners Base, even if the Absolute Accuracy functionality
should never be disabled, it is suggested to do it before teaching such positions,
by means of the following instructions:

BIT_CLEAR($CRNT_DATA[narm].C_ALONG_1D[28],1)
BIT_SET($CRNT_DATA[narm].C_ALONG_1D[28],2).

At the end of the Base calculation procedure, enable the functionality again either
by means of the following instructions

BIT_CLEAR($CRNT_DATA[narm].C_ALONG_1D[28],2)
BIT_SET($CRNT_DATA[narm].C_ALONG_1D[28],1)

or by restarting the system.

286
 Comau Robotics Product Instruction

ROBOT ABSOLUTE ACCURACY

Furthermore note that, in JOG environment, if for example X+ key is kept pressed along
1 m, whenever jogging is stopped, not only the X component variation but also small
variations of the other cartesian coordinates are displayed.

In case of robot with kinematic compensation, the OnPosition (ON POS) functionality is
disabled.
When either replacing a motor or axes calibration are needed, the functionality
performance will NOT turn out to be worse if the procedure is properly executed by using
the dedicated tools.
The performance is worse, instead, in case of replacing an element of the structure such
as gearbox or link.

287
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22. MANUAL GUIDANCE (OPTIONAL FEATURE)

Manual Guidance
The option code is CR17926213.

The Manual Guidance functionality is included by default in Cobot systems and it is a

dedicated feature, as decribed in the Cobot - Technical specifications, Transport
and Installation, Integration, Maintenance manual.

– Introduction
– Manual Guidance device (MG)
– Procedures
– Use of the Manual Guidance system
– Dedicated PDL2 routines
– Errors.

288
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.1 Introduction
The Manual Guidance is a functionality allowing the user to execute a manual intuitive
movement of the robot. This means that the robot FOLLOWS the movement manually
transmitted by the operator, via the Manual Guidance device (MG).
Such a functionality has been conceived to meet the need of manually moving the robot
even without any in-depth technical knowledge about cartesian reference systems,
coordinates transformations, robot geometry, etc.
It is based on C5GPlus Control Unit, RoboSAFE type.
The functionality does not depend on the used robot type; the only difference is as
follows:
– if the robot is COLLABORATIVE, MG is allowed to work both in PROGR (the
Enabling Device button acts as DRIVE-ON / DRIVE-OFF command) and AUTO
states (in AUTO-LOCAL state the system must already be in DRIVE-ON; in
AUTO-REMOTE state the DRIVE-ON signal coming from remote must be active)
– if the robot is NOT COLLABORATIVE, MG is only allowed to work in PROGR state.
The corresponding software option is required to be enabled to use the Manual
Guidance, functionality.

289
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.2 Manual Guidance device (MG)

The Manual Guidance (MG) device, mounted downstream the Force/Torque sensor, is
provided with two handles (A) and two buttons (B), as shown in the figure below.

A - handles
B - buttons

Even if the operator is allowed to use just one hand to manually move the robot, it is
strongly recommended to hold the handles (A) with both hands, in order to obtain a
proper behaviour of the MG device.
Buttons are described in the following par. 22.2.1 Buttons on page 291.

It is recommended to remove the MG device after its usage (figure below, on the left).
The block containing the sensor (figure below, on the right) is NOT removed in any case
together with the MG device.

290
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.2.1 Buttons

1. Enabling Device
2. Emergency stop
3. User Buttons.

22.2.1.1 Enabling Device

In PROGR state the Enabling Device button controls the DRIVE-ON/DRIVE-OFF

command and also enables and disables the manual motion.
In AUTO-LOCAL or AUTO-REMOTE state, the Enabling Device button enables and
disables the manual motion; the DRIVE-ON/DRIVE-OFF command comes from
external devices.

291
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.2.1.2 Emergency stop

Emergency Stop button. The operating modes are as follows:

– activate by pressing
– release by screwing (clockwise).
Upon this button press, the robot stop takes place with a controlled deceleration ramp,
according to IEC 60204-1, class 1.

22.2.1.3 User Buttons

Two buttons are available on the device, which can be customized by the user.

An environment called User Buttons is provided as a SETUP subpage:

SETUP->Motion->Force Control ->User Buttons.

292
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

It is allowed to associate two functionalities to each button (1 or 2), depending on how

the button is pressed: press and long press.

The choice is among the following actions:

– no action
– custom
– path learning
– translation/rotation
– change sensitivity.

Select the chosen action and the press mode for each button, then touch OK key to
confirm (figure above, on the left).

When all the settings are done, touch Save key to make them permanent (figure above,
on the right).

293
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.2.1.3.1 no action
Choosing this item means that when the associated button is pressed in the specified
way (press or long press), no actions are performed.

22.2.1.3.2 custom
The custom action can be executed by long pressing one of the User Buttons (the
associated one) and the Enabling Device, in order to guarantee that operator’s hands
are both occupied on the robot wrist.
At each long press of the user button (together with the Enabling Device press), the
system executes the PDL2 statements inserted in the ru_customUserButtons routine
of MG_CustomUserButtons.cod program.
Such a program is available in the following Control Unit folder
UD:\SYS\UTIL
The routine can be associated to the button long press only, with Hold-to-Run modality.
The button must be kept pressed during the whole routine execution; if it is released
before the execution completion, an error message occurs.
If the Enabling Device button is released during the routine execution, an error message
occurs as well.
Please note that the user routine execution starts one second after the button press.

22.2.1.3.3 path learning

CAUTION - learning a path is allowed when the system is in DRIVE-ON only.

Choosing this item means that when the associated button is pressed in the specified
way (press or long press), the system starts learning the path which can be later used
in a PDL2 program, automatically saved into a MONI file of REPLAY type.
Such a file can be specified in a MOVE instruction with REPLAY clause.

Example:
MOVE FROM start_pos REPLAY 'rec_file.log'
-- The robot moves from the current position towards start_pos,
-- then it performs the movements previously saved in file
-- rec_file.log

When the same button is pressed again, the system stops learning the path.

This action also stops if it is automatically interrupted in case of either “Maximum length
reached” for the moni file or DRIVE-OFF occurred.
An interrupted recording action is definitively finished and cannot be continued.

Refer to Chap.23. - Path Learning on page 317 for further details about such a
functionality configuration.

294
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.2.1.3.4 translation/rotation
Choosing this item means that each time the associated button is pressed in the
specified way (press or long press), translation/rotation movements are enabled.
The circular sequence is
– translation,
– rotation,
– both.

22.2.1.3.5 change sensitivity

Choosing this item means that each time the associated button is pressed in the
specified way (press or long press), the Manual Guidance Sensitivity value is modified.
The circular sequence is
– low,
– middle,
– high.

The higher the sensitivity, the more the robot becomes compliant.

295
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.3 Procedures

22.3.1 Introduction
– Fieldbus devices configuration procedure
– Force/Torque sensor setup procedure
– Force/Torque sensor compensation procedure
– Compensation status check procedure
– Force/Torque sensor and corresponding NetBox installation procedure.

22.3.2 Fieldbus devices configuration procedure

SETUP -> IO -> IO_CNFG - Configuration and mapping of the I/Os corresponding to the
Fieldbus devices.

a. Touch the Network menu and select Powerlink item

b. In the Bus Coupler page, touch the Fieldbus key, which allows to select the
module to be inserted

c. Touch Select key to open the list of the available modules

296
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

d. insert the Ethernet/IP Scanner module (Insert key)

e. Touch the Options menu and choose Force Control item to configure the
selected Fieldbus module

f. The word YES, displayed in Config column (figure below) at the end of the
operation, states that the module has been properly configured.

297
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

g. Step back to IO_CNFG main page (using Back key) and save the new
configuration, by touching the Save key

h. Close IO_CNFG program

i. Perform a system restart (Restart Cold – CCRC command).

22.3.3 Force/Torque sensor setup procedure

CAUTION
A Service type user profile is required to access this procedure.
If the current user profile is not Service, the system displays an informational message
and the Force/Torque sensor data are read-only.

SETUP -> Motion -> Force Control – Setting sensor parameters

298
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

a. Choose the Sensor - open the sensors list by touching the Sensor field, select the
wished sensor and touch OK key to confirm

b. Set the Sensor frame – specify the position (PDL2 variable of POSITION type)
from robot flange center to sensor center

c. Choose the Sensor mounting – available choices are

– Series (sensor and MG device directly mounted on the flange)
– Parallel (sensor and MG mounted on a device displacing it from the flange
center).

d. Save the new settings.

CAUTION! Be sure that the payload has been properly identified, before using the MG
device, in order to avoid any collisions and resulting damages to the robot, its
equipments, and to the operators.

299
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.3.4 Force/Torque sensor compensation procedure

SERVICE -> Motion -> Force Control – this procedure is needed at the first use and,
later in case of sensor drift

a. Touch the Compens. menu and select New item

b. Follow the wizard hints while executing the procedure. If a new starting position is
needed, issue the Teach command to teach it. Touch Next key to continue

c. Touch Next key to continue

300
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

d. Open the compensation program in IDE environment

e. Execute the program in IDE, to check for no collisions occurring during

movements. The system must be in PROGR status mode and the program must
be executed step-by-step

e.1 If problems arise with the axes ranges, close IDE (figure below)

e.2 Touch Axes range key (next figure, on the left).

When the suitable range is found, save such values for future use, by touching
Salva key (next figure, on the right)

301
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

e.3 Step back to d.

f. When the program execution is completed, close IDE

g. The program returns to the compensation procedure main page. Touch Next key
to continue

h. Switch the system to AUTO-LOCAL and DRIVE-ON

302
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

i. Press START button to begin the compensation procedure.

NOTE THAT the robot starting position is either the calibration position
($CAL_SYS) or the one taught during the Teach phase, if any (step b.).
Wait for the procedure completion

j. When finished, the program displays the computed data. It is suggested to visually
check the Mass value

k. Touch the Save key to save all the compensation data

l. Each compensation procedure is associated to an index, from 1 to 32, and a name,

both chosen by the user (as shown in the next two figures)

303
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

m. Touch OK key to confirm, in both the pages (figures above)

n. Close the page (figure above). The new Compensation has been recorded.

22.3.5 Compensation status check procedure

SERVICE -> Motion -> Force Control – this procedure checks the specified
compensation status.

a. Touch the Compensation field to select the wished one

304
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

b. Touch Compens. menu and choose Status item

c. The displayed page shows some “leds” related to the following information:
– system status and DRIVE-ON/DRIVE-OFF
– Force and Torque components status for the selected compensation

d. Switch the modal selector to AUTO-LOCAL and put the motors to DRIVE-ON. The
corresponding “leds” must become green, as highlighted in the figure below

305
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

e. Check that all the Force and Torque components “leds” are green. If even only one
“led” is red, execute the Force/Torque sensor compensation procedure and check
the “leds” status again, until all of them are green.

22.3.6 Force/Torque sensor and corresponding NetBox

installation procedure
The currently used Force/Torque sensor is supplied together with its associated NetBox.
Before using a newly supplied sensor (refer to the hardware manual for any information
about it), the following operations are needed:

a. connect a PC on Ethernet, to the NetBox (the IP address set by Comau for the in
use NetBox is 192.168.1.1)

b. insert the NetBox IP address in the user’s favourite browser address bar. It is then
allowed to modify the following settings:
– Comunications -> IP Address Mode -> insert STATIC IP
– Comunications -> IP Address Mode -> enable “Ethernet/IP Protocol”
– Apply
– Settings -> low pass fIlter ->152Hz
– Apply
Refer to the official documentation of the device supplier, for any detailed information.

306
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.4 Use of the Manual Guidance system

– MG System Use procedure
– Status of the MG functionality.

22.4.1 MG System Use procedure

CAUTION! Be sure that the payload has been properly identified, before using the MG
device, in order to avoid any collisions and resulting damages to the robot, its
equipments, and to the operators.

After all settings and configurations described in the previous chapters have been
executed, proceed as follows by means of the Service Page - Force Control
environment on the Teach Pendant, to be able to use the Manual Guidance system.

a. Access the SERVICE -> Motion -> Force Control subpage

b. Insert the Reference frame - specify the position (PDL2 variable of POSITION
type) from the robot flange center to the MG handles center, i.e. to the dwell in
which torques are applied during the manual guidance movements

307
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

c. Select the Contact material – touch the related field to open the table including the
available materials and select the wished one (the default choice is Manual
Guidance)

d. Select the wished Compensation - touch the related field to open the
compensations table; if the wished one is not in the table, create a new one
executing the Force/Torque sensor compensation procedure

e. Choose the wished Sensitivity - touch the field related to the individual Force or
Torque component (figure below, on the left), to open the corresponding
Sensitivity page (figure below, on the right)

The available choices are:

– Disable - disables the movement related to the selected component (figure

above, on the right)
– Low/Middle/High - sets the sensitivity for the selected component (next
figure). The higher the sensitivity, the more the robot becomes compliant, as
far as such a component

308
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

– Apply to all - apply the choice (either disable or sensitivity level) to all the
Force and Torque components

f. Keep pressed the Enabling Device button, complying the rules described in
par. 22.2.1.1 Enabling Device on page 291 and start manually moving the robot.

g. The Data key allows displaying the current data, in different formats, while using
the Manual Guidance system:
– Data
– Dashboard
– Chart

Data
Displays the page in which the described above values can be selected (figure
above)

Dashboard
Displays graphical analog gauges for real-time reading the sensor data (Force and
Torque components values)

309
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

Chart
Provides the graphic representation (diagrams) of the sensor data (Force and
Torque components values), on the time basis

h. In the ForceControl main page a checkbox is also available, labelled Trace

moni.log, to enable recording a MONI file, useful to collect data in case of possible
problems and to send it to Comau in order to analyze the situation.

As soon as Trace moni.log checkbox is selected, the system opens the MONI
page (as shown in the above figure on the right).
The user is allowed to modify the following data only:
– Sampling
– Length (sec).

Refer to par. 5.18.2.7 Moni on page 332 for any further operational information.

310
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.4.2 Status of the MG functionality

In the upper part of the Force Control service page, a status bar is displayed (figure
below) indicating the Manual Guidance functionality current status.

The available states are:

STATUS DESCRIPTION
The system is waiting for the “ForceControl_FT_sensor” Fieldbus device
Waiting for FT sensor connected
connection
Waiting for FT sensor
ForceControl_FT_sensor needs compensation
compensation
Waiting for load FT sensor
A Force/Torque sensor compensation is in the activation phase
compensation
Waiting for DRIVE-ON and The system is waiting for the robot motors are in ON state and the
selection of contact material contact material is selected
The system is waiting for the enabling device buttons to be pressed, to
Monitoring State
execute the Manual Guidance functionality
Running State The Manual Guidance functionality is running
The static compensation (with NOT moving robot) of the Force/Torque
FT sensor static compensation
sensor, is in progress
The robot has reached a position which is useful to acquire the needed
FT sensor static compensation
data for the Force/Torque sensor static compensation calculation (with
pos. reached
NOT moving robot)
Waiting for FT sensor The needed data for the Force/Torque sensor compensation calculation
compensation computing done have been acquired; the computation is in progress.

311
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.5 Dedicated PDL2 routines

The following routines are available, written in PDL2 language, which can be called,
from within a user program, to perform selections and settings related to the Manual
Guidance functionality usage:
– FC_SetComp routine
– FC_SetGain routine
– FC_SetCFPos routine
– FC_SetComplianceLevel routine.

22.5.1 FC_SetComp routine

Name FC_SetComp
Function/Usage Select a Force/Torque sensor compensation
– comp - (INTEGER) index of the Force/Torque sensor compensation to be selected
– n_arm – (INTEGER) (OPTIONAL) ARM number for which selecting a Force/Torque
sensor compensation (only one value is allowed)
– await – (BOOLEAN) (OPTIONAL) – default = TRUE
Parameters
• if TRUE, wait for the new contact material to be active. If the wished contact
material cannot be selected, the following error occurs:
46533: [FOCO] wrong FSM state
• if FALSE, no checks are executed for the contact material to be really active.
Routine FC_SetComp (comp:INTEGER; n_arm:INTEGER(); await:BOOLEAN())
Declaration
EXPORTED FROM FC_lib GLOBAL

22.5.2 FC_SetGain routine

Name FC_SetGain
Function/Usage Select a contact material
– gain - (INTEGER) index of the contact material to be selected
– n_arm – (INTEGER) (OPTIONAL) ARM number for which selecting a contact material
for the Force/Torque sensor
– await – (BOOLEAN) (OPTIONAL) – default = TRUE
Parameters
• if TRUE, wait for the new contact material to be active. If the wished contact
material cannot be selected, the following error occurs:
46533: [FOCO] wrong FSM state
• if FALSE, no checks are executed for the contact material to be really active.
Routine FC_SetGain (gain:INTEGER; n_arm:INTEGER(1);
Declaration
await:BOOLEAN(TRUE)) EXPORTED FROM FC_lib GLOBAL

22.5.3 FC_SetCFPos routine

Name FC_SetCFPos
Function/Usage Set the coordinates of the reference frame

312
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

– x, y, z, a, e, r - (REAL) components of a PDL2 POSITION in which the reference frame

value in relation to the robot flange is set
Parameters
– n_arm – (INTEGER) (OPTIONAL) ARM number for which selecting the reference
frame (only one value is allowed)
Routine FC_SetCFPos (x, y, z, a, e, r: REAL; n_arm:INTEGER(1))
Declaration
EXPORTED FROM FC_lib GLOBAL

22.5.4 FC_SetComplianceLevel routine

Name FC_SetComplianceLevel
Function/Usage Allow setting the sensitivity level for using the functionality
– ai_fx – (INTEGER) wished sensitivity for the force component along the Force/Torque
sensor x axis
– ai_fy – (INTEGER) wished sensitivity for the force component along the Force/Torque
sensor y axis
– ai_fz – (INTEGER) wished sensitivity for the force component along the Force/Torque
sensor z axis
– ai_tx – (INTEGER) wished sensitivity for the torque component along the Force/Torque
sensor x axis
– ai_ty – (INTEGER) wished sensitivity for the torque component along the Force/Torque
Parameters sensor y axis
– ai_tz – (INTEGER) wished sensitivity for the torque component along the Force/Torque
sensor z axis
The allowed values for ai_fx, ai_fy, ai_fz, ai_tx, ai_ty, ai_tz, are as followsi:
6 = LOW SENSITIVITY
5 = MEDIUM SENSITIVITY
4 = HIGH SENSITIVITY

0 = DISABLED COMPONENT
– ai_n_arm – (INTEGER) (OPTIONAL) ARM number for which selecting the reference
frame (only one value is allowed)
Routine FC_SetComplianceLevel (ai_fx, ai_fy, ai_fz, ai_tx, ai_ty,
Declaration
ai_tz: INTEGER; ai_n_arm:INTEGER()) EXPORTED FROM FC_lib GLOBAL

313
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

22.6 Errors

Code 46523-10
Message [FOCO]: Fieldbus device ForceControl_FT_sensor not found
Cause No Fieldbus devices called ForceControl_FT_sensor found
Execute the Fieldbus devices configuration procedure to configure the ForceControl_FT_sensor
Remedy
Fieldbus device

Code 46524-10
Message [FOCO]: Fieldbus device ForceControl_FT_sensor not enabled
Cause The fb_enabled field of the ForceControl_FT_sensor Fieldbus device is set to OFF
Use the Fieldbus devices configuration tools to set the fb_enabled field of the
Remedy
ForceControl_FT_sensor to ON.

Code 46525-10
Message [FOCO]: Fieldbus device ForceControl_FT_sensor not connected
Cause The ForceControl_FT_sensor Fieldbus device is not connected to the system
Check the electrical connections and the software configuration of the ForceControl_FT_sensor
Remedy
Fieldbus device

Code 46526-10
Message [FOCO]: Payload not declared
Cause Attempt to use the Manual Guidance functionality without any robot payload identification
Remedy Set the proper payload

Code 46527-10
Message [FOCO]: sensor threshold reached
Cause The sensor threshold has been reached during the movement in ManualGuidance
Remedy Stop applying any forces or torques to the sensor and resume after few seconds

Code 46529-10
Message [FOCO]: F/T sensor compensation required (0x<Mask>)
The Force/Torque limit (declared as a function of the sensor frame), set by the system, has been
Cause exceeded. The <Mask> value provides information about which Force/Torque component
exceeded the limit set by the system
Remedy Stop applying any forces or torques to the sensor and resume after few seconds

Code 46530-10
Message [FOCO]: force/torque in sensor frame exceeded (0x<Mask>)
The Force/Torque limit (declared as a function of the sensor frame), set by the system, has been
Cause exceeded. The <Mask> value provides information about which Force/Torque component
exceeded the limit set by the system
Remedy Stop applying any forces or torques to the sensor and resume after few seconds

314
 Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

Code 46531-10
Message [FOCO]:velocity limit exceeded (0x<Mask>)
The velocity limit set by the system has been exceeded. The <Mask> value provides information
Cause
about in which direction the velocity limit set by the system has been exceeded.
Remedy Stop applying any forces or torques to the sensor and resume after few seconds

Code 46533-10
Message [FOCO]: wrong FSM state
Cause The Manual Guidance functional algorythm is in an unknown state
Contact COMAU ([email protected]) possibly specifying which operations caused the
Remedy
error

Code 46535-10
Message [FOCO]: SAFE not in Normal mode
Cause The SAFE system is not in Normal modality
Remedy Switch the SAFE system to Normal modality

Code 46536-10
Message [FOCO]: Timeout F/T sensor compensation computation
Cause The Force/Torque sensor compensation procedure cannot reach any results
Repeat the Force/Torque sensor compensation procedure modifying the robot movements, if
Remedy
possible

Code 46537-10
Message [FOCO]: $TRK_TBL not configured yet. Activation not allowed
Cause The Force/Torque sensor compensation procedure has not been executed yet
Remedy Execute the Force/Torque sensor setup procedure

Code 46538-10
Message [FOCO]: Compensation not selected
Cause Attempt to use the Manual Guidance functionality without any compensation has been selected
Remedy Select a compensation

Code 46539-10
Message [FOCO]: Contact material not selected
Cause Attempt to use the Manual Guidance functionality without any contact material has been selected
Remedy Select a contact materia (par. 22.4.1 MG System Use procedure on page 307, step c.)

Code 46540-10
Message [FOCO]: Gains file not found
Cause The file including the contact materials list has not been found
Remedy Contact COMAU ([email protected])

315
Comau Robotics Product Instruction

MANUAL GUIDANCE (OPTIONAL FEATURE)

Code 46541-10
Message [FOCO]: Arm number out of range
Cause The use of the Manual Guidance functionality is only allowed for Arm 1
Remedy Use the Manual Guidance functionality with Arm 1 only

Code 46542-10
Message [FOCO]: Sensitivity out of range
Attempt to use a not allowed sensitivity level. The allowed values are:
6 = LOW SENSITIVITY
5 = MEDIUM SENSITIVITY
Cause
4 = HIGH SENSITIVITY

0 = DISABLED COMPONENT
Remedy Use the allowed sensitivity level

Code 46543-10
Message [FOCO]: Second Euler angle must be between 0 and +180 degrees
Cause Attempt to assign a not allowed value to the second Euler angle
Remedy Use a value between 0 and +180 degrees

Code 46544-10
Message [FOCO]: First and third Euler angle must be between -180 and +180 degrees
Cause Attempt to assign a not allowed value to the first and third Euler angle
Remedy Use a value between 0 and +180 degrees

316
 Comau Robotics Product Instruction

PATH LEARNING

23. PATH LEARNING

– Description
– PDL2 routines to handle MONI REPLAY type files.
– Example

23.1 Description
Path Learning is a functionality allowing to record a trajectory while the robot is
executing it. It is saved into a binary moni file of replay type, and can be later executed
again using a

MOVE FROM start_pos REPLAY ‘moni_replay.log’

statement, inserted in a PDL2 program.

A basic model for such a PDL2 program is automatically created by Path Learning
functionality (unless opposite indication - see mrri_stop_moni_replay routine) and can
be customized according to the user’s needs.
Furthermore, during the trajectory registration, it is also allowed to save the status of
some specific I/O ports: such a status will then be later replayed, while the trajectory is
executed again (by means of the MOVE FROM...REPLAY statement).
The following dedicated routines are available to set and configure the following
parameters related to the moni replay file:
– mrri_moni_replay_init routine - to set the filename, the path of the folder including
it, the trajectory execution velocity
– mrri_moni_replay_cnfg_io routine - to specify the I/O ports (if any) whose current
status is to be recorded in the file.

Note that such I/O ports must have already been mapped.
After the mrri_moni_replay_cnfg_io routine execution, a cold restart of the Control Unit
is required (Restart Cold command) to make the settings operational.

Refer to par. 5.3.3 REPLAY (execution of a saved trajectory) on page 55 for further
details about MOVE REPLAY instruction.

317
Comau Robotics Product Instruction

PATH LEARNING

23.2 PDL2 routines to handle MONI REPLAY type files

– mrri_start_moni_replay routine
– mrri_stop_moni_replay routine
– mrri_moni_replay_init routine
– mrri_moni_replay_cnfg_io routine
– mrru_moni_replay_dump_io routine.

Note that, in the following descriptional tables, all parameters included between ‘<’ and
‘>’ (e.g. <ai_param1>) are optional.

23.2.1 mrri_start_moni_replay routine

Name mrri_start_moni_replay
Function/Usage Starts the execution of the trajectory to be saved in a moni replay file
Parameters – <ai_dec>: (INTEGER) sampling during the moni replay acquisition phase. Default = 1
– 0 - no errors detected
Returned value
– -1 - error detected
ROUTINE mrri_start_moni_replay(ai_dec : INTEGER()) : INTEGER
Declaration
EXPORTED FROM MoniReplay_lib GLOBAL
PROGRAM start_moni
...
BEGIN
...
Example mrri_start_moni_replay -- start acquiring the trajectory that
will be
-- saved in a moni replay
...
END start_moni

23.2.2 mrri_stop_moni_replay routine

Name mrri_stop_moni_replay
Function/Usage Stops the execution of the trajectory saved in a moni replay file
– <ab_create_pdl>: (BOOLEAN) if TRUE, a sample PDL2 file is created in the same
Parameters folder of the moni replay file,to later execute the saved trajectory. The .PDL file is also
translated into .COD. format. Default = TRUE

318
 Comau Robotics Product Instruction

PATH LEARNING

– 0 - no errors detected
– -10 - attempt to stop a trajectory registration, which was never started
Returned value – -11 - error while copying the moni replay file from the creatin folder to the folder in
which it is to be saved
– -12 - error during the .PDL and .COD files creation
ROUTINE mrri_stop_moni_replay(ab_create_pdl : BOOLEAN()) : INTEGER
Declaration
EXPORTED FROM MoniReplay_lib GLOBAL
PROGRAM stop_moni
...
BEGIN
...
mrri_start_moni_replay -- start acquiring the trajectory that is
saved
Example
-- in a moni replay
...
mrri_stop_moni_replay -- stop acquiring the trajectory for the
current
-- moni replay
END stop_moni

23.2.3 mrri_moni_replay_init routine

Name mrri_moni_replay_init
Function/Usage Allows customizing the trajectory acquisition saved in a moni replay file
– <as_moni_folder>: (STRING) path and name of the Control Unit folder in which moni
replay file, .PDL sample file and corresponding .COD file must be saved. Default =
‘TD:\’
– <as_moni_name>: (STRING) name for saving moni replay file, .PDL sample file and
Parameters
corresponding .COD file. If such a file already exists, an incremental numeric suffix is
added to the filename. Default = ‘moni_replay’
– <ai_moni_spd>: (INTEGER) value assigned to $RPL_SPD_OVR predefined variable
in the .PDL sample file. Default = 100
– 0 - no errors detected
Returned value
– -1 - error detected
ROUTINE mrri_moni_replay_init(as_moni_folder, as_moni_name:
Declaration STRING(); ai_moni_spd : INTEGER()) : INTEGER EXPORTED FROM
MoniReplay_lib GLOBAL

319
Comau Robotics Product Instruction

PATH LEARNING

PROGRAM moni_init
...
BEGIN
...
mrri_moni_replay_init('UD:\\usr\\PathLearning\\Moni\\',
'test_pl')
...
END moni_init

-- The program saves moni replay and PDL2 files if any (.pdl e .cod)
using
-- it, in UD:\\usr\\PathLearning\\Moni\\ folder.
Example -- If the folder does not exist, it is automatically created. The
files are
-- saved with the following extensions:
-- test_pl.log
-- test_pl.pdl
-- test_pl.cod.
-- For further acquisitions, a suffix is added to the filename,
composed
-- by an undescore character and an incremental number (maximum is
1000)
-- (e.g. “_1”, “_2”, etc.). Once the limit is reached, the filename
starts
-- from the original again.

23.2.4 mrri_moni_replay_cnfg_io routine

Name mrri_moni_replay_cnfg_io
Allows defining which I/O ports must be saved into the acquired moni replay file. The I/O
ports must have already been mapped.
Function/Usage
After this routine execution, a cold restart of the Control Unit is required (Restart Cold
command), as indicated on the Teach Pendant display, to make the settings operational.
– <ai_num>: (INTEGER)value 1..10 specifying which ones of the ten available ports
Parameters
must be associated to the moni replay file acquisition
– <ai_io_idx>: (INTEGER) index of the I/O port to be saved into the moni replay file
acquisition
– <ai_io_type>: (INTEGER) type of the I/O port to be saved into the moni replay file
acquisition:
• 1 = $DIN
• 2 = $DOUT
– <ab_ovr>: (BOOLEAN) if TRUE and an attempt is in progress to associate an already
associated I/O port, it is overwritten. If FALSE, it is left unchanged. Default = TRUE
– 0 - no errors detected
– -101 - none of the ten available ports can be associated to the moni replay file
acquisition
Returned value – -102 - the specified I/O port is not allowed (ai_io_type)
– - 104 - the specified I/O port index, specified by ai_io_idx, to be saved into the moni
replay file acquisition, is not allowed
– -105 - the ai_num parameter value is NOT included between 1 and 10
ROUTINE mrri_moni_replay_cnfg_io(ai_num, ai_io_idx, ai_io_type :
Declaration INTEGER; ab_ovr : BOOLEAN()) : INTEGER EXPORTED FROM MoniReplay_lib
GLOBAL

320
 Comau Robotics Product Instruction

PATH LEARNING

PROGRAM conf_pl_io NOHOLD

CONST KI_TYPE_DOUT = 2
ROUTINE mrri_moni_reply_cnfg_io(ai_num, ai_io_idx, ai_io_type :
INTEGER;ab_ovr : BOOLEAN()) : INTEGER EXPORTED FROM MoniReply_lib
GLOBAL
BEGIN
IF mrri_moni_reply_cnfg_io(1, 1, KI_TYPE_DOUT) <> 0 THEN
WRITE LUN_CRT ('config $DOUT[1] in position 1 error', NL)
ELSE
WRITE LUN_CRT ('config $DOUT[1] in position 1 OK', NL)
ENDIF
Example IF mrri_moni_reply_cnfg_io(2, 2, KI_TYPE_DOUT) <> 0 THEN
WRITE LUN_CRT ('config $DOUT[2] in position 2 error', NL)
ELSE
WRITE LUN_CRT ('config $DOUT[2] in position 2 OK', NL)
ENDIF
-- issue a cold restart command (CCRC)
END conf_pl_io

-- When executing the sample program, the status of $DOUT[1] and

$DOUT[2]
-- ports, is recorded during the moni replay acquisition
-- (NOTE THAT such ports must have previously been mapped).

23.2.5 mrru_moni_replay_dump_io routine

Name mrru_moni_replay_dump_io
Send to the screen (CRT and TP-INT) the currentlyselected I/O ports, to be registered to the
Function/Usage
acquired moni replay file
Parameters none
Returned value none
ROUTINE mrru_moni_replay_dump_io EXPORTED FROM MoniReplay_lib
Declaration
GLOBAL
PROGRAM dump_pl_io NOHOLD
ROUTINE mrru_moni_reply_dump_io EXPORTED FROM MoniReply_lib GLOBAL
BEGIN
...
mrru_moni_reply_dump_io
Example
...
END dump_pl_io

-- The I/O ports associated to the Path Learning functionality are

-- displayed onto the Terminal Screen

23.3 Example
PROGRAM test_pl_monireply
VAR vp_ini_test_pl_monireply : POSITION NOSAVE
VAR vp_fin_test_pl_monireply : POSITION NOSAVE
VAR vp_base_test_pl_monireply : POSITION NOSAVE
VAR vp_tool_test_pl_monireply : POSITION NOSAVE

321
Comau Robotics Product Instruction

PATH LEARNING

VAR vp_uf_test_pl_monireply : POSITION NOSAVE

BEGIN
$ARM_DATA[ 1].RPL_DIR_PATH := 'UD:\\USR\\tD\\PL\\'
RPL_GET_POS('test_pl_monireply.log',
vp_ini_test_pl_monireply, vp_fin_test_pl_monireply,
vp_base_test_pl_monireply, vp_tool_test_pl_monireply,
vp_uf_test_pl_monireply,
$PROG_ARM) -- extract the needed information about the
-- trajectory execution, from 'test_pl_monireply.log' file
$RPL_SPD_OVR := 100 -- set the execution velocity for the
-- recorded trajectory
$BASE := vp_base_test_pl_monireply
$TOOL := vp_tool_test_pl_monireply
$UFRAME := vp_uf_test_pl_monireply
CYCLE
MOVE TO vp_ini_test_pl_monireply
MOVE FROM vp_ini_test_pl_monireply REPLAY
'test_pl_monireply.log'
END test_pl_monireply

322
 Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24. IMPR - APPLICATION FOR CONTINUOUS

PROCESSES OPTIMIZATION (OPTIONAL
FEATURE)

Roboshop Continuous Process Improver - IMPR

The option code is CR17926139.
This option is available since 4.20.xxx system software version.
In the following description, the option is referred to as IMPR.

24.1 Introduction
Executing a trajectory related to a continuous process with controlled speed, could
tansmit extreme stress to the performing manipulator. In such situations, it is suitable to
improve the robot dynamic behaviour preserving the user trajectory.
An application has been implemented to perform the described above task. It is supplied
as a Roboshop© software optional feature.
Such an app is called Roboshop Continuous Process Improver, abbreviated to
IMPR, and:
– Roboshop© needs a dedicated software licence, to use it
– it is suitable for machining applications (e.g. milling) with a duration of not more
than 5 minutes,
– a cartesian type moni.log trajectory file is needed in input, obtained by executing
a PDL2 program on a real or simulated controller
– it is suitable for serial productions (i.e. without any differences between a working
part and another)
– no synchronizations with external devices are supported, to date
– a PDL2 program is provided as output, using the MOVE REPLAY statement and
the corresponding moni.log file (refer to par. 5.3.3 REPLAY (execution of a saved
trajectory) on page 55)

The following topics are described in the current chapter:

– Installing
– Operations
– User Interface
– Comparing velocities.

323
Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24.2 Installing
Roboshop© software and the MATLAB Runtime library are required to install the IMPR
application on a PC.
Proceed as described below:

a. after Roboshop© has been installed, run the executable file supplied by Comau
(RoboshopImpr_v2.12.exe) to generate a Roboshop© version including IMPR.

b. Click Next key to continue.

c. Specify the wished installation folder, click Next and then Install keys to start the
true installation phase.

324
 Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

d. To complete the IMPR functionality installation, run the

RoboshopMatlabUtils_v1.0.exe application supplied by da Comau.

e. Depending on whether the Matlab Runtime library is already installed in the PC or

not, the procedure asks the user to choose between
• Install Matlab RUNTIME - full installation (Matlab Runtime not present in the
PC)
• Minimal Setup (No matlab runtime) - minimal installation (Matlab Runtime
is already present in the PC)

f. The full installation could take several minutes. At the end the IMPR environment
is available in Roboshop©.

325
Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

g. At the Roboshop© with IMPR first execution, the application needs a dedicated
licence key, to be required to COMAU by clicking Request License

h. When the licence key is supplied, copy it to the corresponding area (highlighted in
red in the figure below) and click Register key

i. At the and, a message is displayed stating that the registration is completed. IMPR
optimizer is ready to be used.

326
 Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24.3 Operations
– Creating the moni.log input file
– Using IMPR optimizer.

24.3.1 Creating the moni.log input file

The IMPR application input must be a moni.log data file that is to be created by
executing a PDL2 program specified by the user. The execution can be either directly
performed on the Control Unit or simulated in the Roboshop© virtual environment.
Two routines are available to acquire such a file, in the UD:\sys\util folder of the Control
Unit, for the operation beginning (Start) and end (Stop).
They are included in the StartStopMoni.cod file that is the user’s care to be loaded into
the execution memory.
– imprStartMoni
– imprStopMoni.

imprStartMoni
Name imprStartMoni

Function/Usage Starts the data recording to the specified moni file

– moni_name : STRING - name of the being created file

– ai_moni_type : INTEGER - optional parameter - specifies the data file type.
Allowed values:
Parameters • 17 - no auxiliary axes in the system
• 36 - the system includes auxiliary axes
• other values - not dedicated to IMPR
– ai_arm : INTEGER - optional parameter - specifies the reference arm.
ROUTINE imprStartMoni(moni_name : STRING; ai_moni_type, ai_arm :
Declaration
INTEGER()) EXPORTED FROM StartStopMoni

imprStopMoni
Name imprStopMoni

Function/Usage Ends the data recording to the specified moni file

Parameters none

Declaration ROUTINE imprStopMoni EXPORTED FROM StartStopMoni

Such routines identify, including it, the process phase to be optimized, as shown in the
following example.

Example
PROGRAM TEST
...
ROUTINE imprStartMoni(moni_name : STRING; ai_moni_type, ai_arm :
INTEGER()) EXPORTED FROM StartStopMoni
ROUTINE imprStopMoni EXPORTED FROM StartStopMoni

327
Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

...
BEGIN
...
MOVE JOINT TO pnt0001P
imprStartMoni('prog_02') -- Process start
MOVEFLY LINEAR TO pnt0002P ADVANCE
MOVEFLY LINEAR TO pnt0003P ADVANCE
...
MOVE LINEAR TO pnt1234P
imprStopMoni -- Process end
...
END TEST

24.3.2 Using IMPR optimizer

a. Activate the IMPR optimizer by means the icon available in Roboshop©.

b. The IMPR environment is opened.

328
 Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

c. Insert the following data:

• Moni Type - name and path of the moni.log file, to be given as input to the
optimizer. Click “...” key (highlighted in the figure above).

When the wished moni.log file has been chosen, click Open key (figure above)
• Speed [m/s] - wished execution speed
• values for some more else parameters, if any. Refer to par. 24.4.1.1 Basic
menu on page 332 for further information.

d. After the wished values have been inserted, click the Run key (previous figure) to
start the optimization of the input path.

329
Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

e. At the optimization operation end, which could take until some minutes, depending
on the path complexity, the following Standard diagrams are displayed:
• Trajectory - obtained trajectory
• Override - needed speed override for the optimization
• Velocity - scalar velocity of the operational peak
• Velocity details - chromatic details of the scalar velocity evolution.
Note that if also the Advanced users menu parameters are used, five more
diagrams are provided. Refer to par. 24.4.2.2 Advanced users diagrams on
page 337 for a detailed description.

CAUTION - If either the input moni.log file and the selected parameters for the
optimization are such that the generated output moni file cannot be loaded into the
Control Unit due to its dimensions, or in case of exagerated complexity of the path, the
procedure is interrupted and the following error occurs:
Output file too big .
In this case, the user should operate to acquire a smaller input moni.log file, by further
partitioning the original program.

If the optimization results don’t meet the expectations, act on the Basic menu (or
on the Advanced users menu, if used) parameters and then go back to step d.

Note that the Basic menu Reset key resets the optimizer parameters to the default
values.

The user is allowed to save the optimizations history and compare different parameters
combinations, by specifying a value greater than 1 for the History Depth parameter of
the Basic menu. Refer to par. 24.5 Comparing velocities on page 340 for further details.

f. If, on the contrary, the optimization results are satisfactory, continue with
generating the PDL2 program and the corresponding optimized path, by clicking
the Export PDL key (as shown in the figure below on the left)

g. Specify the destination folder and filename and then click Save key (previous figure
on the right).
The following files are created in the selected folder:
– a file including the optimized trajectory data (<filename>.log)

330
 Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

– a PDL2 program model (<filename>.pdl) able to execute it; it will have a format like
the one in the following exeample:

PROGRAM My_continuous_process_01 PROG_ARM = 1

VAR p1 : POSITION
BEGIN
$RPL_DIR_PATH :='UD:\\usr'
$RPL_SPD_OVR:=100
$BASE := POS(0)
$TOOL := POS(808.679993,-2.24499989,70.75,180,90,180)
$UFRAME := POS(1600,0,-1050,0,0,0)
p1:=POS(44.7498932, 294.629761, 687.280273, 0, 0,
-179.830002, '')

MOVE TO {0, 0, -90, 0, 90, 0}

DELAY 1000
CYCLE
MOVE TO p1
DELAY 1000
MOVE FROM p1 REPLAY 'My_continuous_process_01.log'
DELAY 1000
END My_continuous_process_01
The IMPR optimizer generates such a PDL2 template-program, complete and
executable, due to the fact that, before the MOVE REPLAY execution, the robot is
moved to a general non-singularity position for the wrist, probably reachable since
coming from the calibration.
Nevertheless, some cases could exist in which the position cannot be reached, so it is
needed to check whether the joint MOVE and the MOVE REPLAY connection can be
executed, since not being part of the original trajectory taken into consideration by the
optimizer. Such observations apply to the case of executing the program generated by
IMPR without any modifications.
However, more often the user extracts the statement

MOVE FROM p1 REPLAY 'My_continuous_process_01.log'

(where the name of the .log file is simply a sample name) from the template-program
and inserts it in his/her own original program, in place of the block composed by all the
motion statements which are included between imprStartMoni and imprStopMoni
routine calls, in the Creating the moni.log input file step.
In such a case, also the other statements must be extracted, which are highlighted in
bold style, in the previous example.
Furthermore, it is suggested to use the RPL_GET_POS built-in which allows the user to
load positional information included in the moni replay, such as $TOOL, $UFRAME,
etc., into program variables. This allows checking whether the original program declared
frames match with the ones of the MOVE REPLAY, before executing it; if not, an error
would occur. Anyway, the loaded values belong to the program variables only and do
not affect the system variables.

Refer to the PDL2 Programming Language manual, chap.Built-in routines list, for
any further information about the RPL_GET_POS built-in routine.

331
Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24.4 User Interface

– Menu
– Diagrams
– Actions Log.

24.4.1 Menu
– Basic menu
– Advanced users menu.

24.4.1.1 Basic menu

The value of the following parameters can be set:

– Speed
maximum speed in m/s (default 0.2)
– Filter Effect
modifies the optimization parameters in order to achieve different behaviours of the
robot. Lower values correspond to an optimization with lower accelerations, i.e.
higher trajectory execution times but with less stress for the manipulator. Default
value is 4, allowed values from 1 (minimum stress) to 7 (maximum stress).
– Running Speed Tool
the value of this parameter can be increased but at the expense of the adherence
to the original trajectory, in order to speed up the optimization of particularly long
trajectories (default value is 3, allowed values from 1 to 6).
– History Depth
enables the optimizations history (default value is 1, maximum value is 3), in order
to be able to compare combinations of different parameters (see par. 24.5
Comparing velocities on page 340).

332
 Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24.4.1.2 Advanced users menu

Press CTRL+SHIFT+A keys combination to access such a menu. The following

parameters value can be set:
– Add control point at [mm]: a higher value of this parameter makes a more
smoothed trajectory in the corners, improving the robot performance at the
expense of the adherence to the original trajectory
– nurbs order: modifying this value, affects the used interpolation mathematical tool.
The suggested values for this parameter are either 4 or 6 (default value is 4,
allowed values from 3 to 6). Higher values give rise to shapes with continuity of
higher orders
– Regeneration step: indicates the resolution level on the trajectory. Higher values
limit the generated trajectory less, compared to the original one. The suggestion is
to keep the default value, i.e. 0.25
– Interpolation type: indicates the used interpolation technique. Allowed values are
"pchip" (default value), "nurbs" and "spline". The suggestion is to keep the default
value.
– Max desired acceleration [m/s^2]: indicates the maximum allowed acceleration.
Parameters for the trajectory geometry optimization:
– L Inf. Norm Lim. [mm]: indicates the tolerance, in mm, for the precision referred
to the original trajectory (maximum geometric reconstruction error).
– U95 Lim. [mm]: indicates the tolerance, in mm, for the precision referred to the
original trajectory (statistical average of the geometric reconstruction error).
Parameters for the optimization of the geometric trajectory execution in time:
– Spd Err. L Inf. Norm Lim: this parameter affects the maximum difference between
the scalar speed of the optimized trajectory (theoretical) and the scalar speed of
the trajectory performed by the manipulator (real). Keep values close to 1, in order
to achieve a good adherence between the real scalar speed and the theoretical
one.
– Spd Err. U95 Lim. [dB]: the more negative the value, the higher the probability for
the manipulator to accurately and without any deformations execute the trajectory.
– Opt. f1 Opt. f2 Opt. f3 [Hz]: higher values for these parameters, reduce the
execution time of the optimized trajectory, increasing however the stress for the
manipulator.

333
Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24.4.2 Diagrams
At the end of the optimization process, the results are displayed in graphic form.
Such diagrams are grouped in:
– 4 basic diagrams
– 2 diagrams reserved to auxiliary axes, if any
– 5 advanced diagrams.
They are useful to understand the control effects on the robot motion planning.
On the 2D diagrams, select a portion to zoom-in such an area. Furthermore, act back or
forth on the mouse wheel for zooming in and out effects.
Some combinations with the CTRL key are also available with the numeric keypad
(numpad), in order to achieve the following actions:
– CTRL + zoom-in
– CTRL - zoom-out
– CTRL 0 to go back to the original viewing.
Zoom-in and zoom-out operations are available for 3D diagrams too, as well as tilting
the diagram in order to view it from various positions. Act back or forth on the mouse
wheel for zooming effects. The view variation is achieved by keeping the right key
pressed while moving the mouse.
The diagrams provided by the optimizator are od the folowing types:
– Standard diagrams
– Advanced users diagrams.

24.4.2.1 Standard diagrams

– Trajectory
– Override
– Velocity
– Velocity details
If the system configuration also includes auxiliary axes, the following diagrams are
provided as well:
– Auxiliary axes
– Auxiliary axes velocity

24.4.2.1.1 Trajectory
This diagram shows the robot reconstructed reference trajectory.

334
 Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24.4.2.1.2 Override
This diagram shows the velocity reduction values in terms of Override, as a function of
the path.

24.4.2.1.3 Velocity
This diagram shows the velocity evolution as a function of the time.

335
Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24.4.2.1.4 Velocity details

This diagram shows the trajectory characterized by a colours map which describes the
scalar speed reduction points on the path.
The colours range is from dark blue, representing lower reduction (higher Override), to
warmer colours representing higher reduction of the speed.

24.4.2.1.5 Auxiliary axes

Auxiliary axes position.

24.4.2.1.6 Auxiliary axes velocity

Auxiliary axes velocity.

336
 Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24.4.2.2 Advanced users diagrams

– Positions
– Input Position
– Moni Input Velocity
– Quaternion
– Quaternion Derivatives.

24.4.2.2.1 Positions
It represents the 3D position of the points chosen by IMPR to create the optimized
trajectory, starting from the original one.

24.4.2.2.2 Input Position

It represents the positions supplied as input to the application, by means of the moni.log
type file.

24.4.2.2.3 Moni Input Velocity

It is the representation of the manipulator TCP scalar velocity, supplied as input to the
application.

337
Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24.4.2.2.4 Quaternion
It is the representation, in quaternions, of the orientation variation.

24.4.2.2.5 Quaternion Derivatives

It is the representation of the orientation variation speed.

24.4.3 Actions Log

Whenever an optimization is performed, the system creates a new log file which
summarizes the parameterization used for the operation, in the folder including the
moni.log input file.
Such a file name is

338
 Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

<input_moni_name>_imprLogPar__<yyyy-mm-dd>.txt
including the list of the used values, as well as the optimization operation date and time.

339
Comau Robotics Product Instruction

IMPR - APPLICATION FOR CONTINUOUS PROCESSES OPTIMIZATION (OPTIONAL FEATURE)

24.5 Comparing velocities

The user is also provided with the capability of comparing the results of Override and
Velocity obtained in successive optimizations (with a maximum of 3), on varying some
parameters.
Such a functionality can be activated from the Basic menu by modifying the value of the
History Depth field.
Two sample diagrams follow to allow comparing two optimizations.
Comparing Override:

Comparing Velocity:

340
 Comau Robotics Product Instruction

END USER LICENSE AGREEMENT

25. END USER LICENSE AGREEMENT

END USER LICENSE AGREEMENT OF THE COMAU

SOFTWARE - COPYRIGHT(c) 2021 COMAU S.p.A.
WARNING: This computer program by Comau, is protected by copyright law and
international treaties. Unauthorized reproduction or distribution of this program, or any
portion of it, may result in severe civil and criminal penalties, and will be prosecuted to
the maximum extent possible under the law.

DEFINITIONS

a. Agreement - includes this License Agreement;

b. Software - shall mean Licensor's proprietary software product(s) together with

related documentation and components (including new releases, enhancements,
and modifications provided under warranty or maintenance, if applicable), in this
agreement also defined <Comau Software>;

c. Licensee - shall mean the part (natural person) who buys the license of the
Software;

d. Licensor - shall mean Comau S.p.A., an Italian company with office in Grugliasco
(TO), Via Rivalta 30.

1. GENERAL PROVISIONS
1.1 This Agreement provides for use of the license making reference to the Software
entitled <Comau Software> and is made between Licensor and Licensee.
1.2 The subject Software includes the Software itself and the related documentation.
By using and installing the above Software, the Licensee accepts to be subject to
the provisions in the present Agreement.
1.3 The subject Software is protected in accordance with International Law Provisions
and Treaties in the field of Copyright, and in addition in accordance with other Laws
and Treaties in the field of Intellectual Property. Failing to comply with said
provisions shall result in the infringer being sued in accordance with the Law.
1.4 License for use of the above Software is hereby granted without any time limit.

2. USER LICENSE
2.1 Licensor grants the Licensee, intended as a natural person, a personal license to
run and use copies of the <Comau Software> in order to develop, to test and to
service/maintain the software used on the industrial automation applications
supplied by Comau.

341
Comau Robotics Product Instruction

END USER LICENSE AGREEMENT

2.2 The Licensee must comply with the instructions recited in this Agreement and keep
copy of the same, which copy must be available for inspection by Licensor.
2.3 In case of third-party software (including Open Source Software) and third-party
data integrated into the Software, the provision and use of such third-party software
shall be governed primarily by the licensing terms and terms of use of such
third-party.

3. NON-DISCLOSURE; ALTERATIONS; COPIES

3.1 Licensee acknowledges and agrees that the Software, its structure, organization,
source code and related documentation are valuable and proprietary trade secrets
of Licensor. Licensee shall (i) maintain the confidentiality of the Software, using, at
a minimum, the same safeguards afforded its own confidential, proprietary trade
secrets, but in no event less than reasonable care; (ii) not disclose, provide,
transfer, rent, sublicense, or otherwise make available any portion of the Software
to any third party, without first obtaining Licensor's written consent. Licensee's
non-disclosure obligation shall not apply to information now or hereafter in the
public domain through no fault of Licensee, information in the possession of
Licensee prior to disclosure by Licensor, information properly obtained without
restriction from a third party who is not bound by an obligation of confidentiality to
Licensor, or information independently developed by Licensee without reference to
the Software.
3.2 Licensee shall not (i) alter, modify, adapt, translate, reverse engineer, decompile,
disassemble, or create derivative works from the Software, nor take any other
steps intended to produce a source language statement of the Software or any part
thereof without Licensor's express prior written consent; (ii) rent, lease, grant a
security interest in, or otherwise transfer rights of the Software; (iii) manipulate or
alter the components that make up this Software in any way; (iv) repackage the
files that come with this Software; (v) make the Software publicly or privately
available (including, but not limited to, uploading to publicly accessible archives,
mirroring and distribution of the Software on flash memory drives, CD-ROM, on line
repositories or similar media) unless specifically and explicitly licensed by the
Licensor to do so; (vi) use parts of this Software in order to enhance competing
products; (vii) remove any proprietary notices or labels on the Software.
3.3 Licensee is authorized to copy the Software solely for backup, archival, and
disaster recovery purposes and only to the minimum extent necessary to
accomplish such purposes. Licensee shall not remove any copyright or proprietary
rights notices from the Software and shall reproduce all such notices on any copies
that it makes. Licensee is prohibited from copying, in whole or in part, any Software
documentation (including portions of source code) or training materials. Licensee
shall use every single License of Software only in a single computer. Every use of
a single License in more than one computer (for example installing software in
more than one computer or accessing a computer in remote mode) is strictly
forbidden.
3.4 In case of commercial use or resell to third part, Licensee is prohibited from
inserting (embedding) the Software in other software or platform without written
authorization from Licensor.
3.5 The obligations of this Section shall survive termination of this Agreement or any
license granted hereunder.

342
 Comau Robotics Product Instruction

END USER LICENSE AGREEMENT

4. FINALIZATION OF THE AGREEMENT

4.1 Licensor reserves the right to finalize this Agreement, without losing any of the
remaining rights belonging to it, in case the Licensee fails to comply with the terms
and conditions mentioned under 2.1 and 2.2 of this Agreement.
In case the Software is used for purposes different from the ones mentioned under
2.1, the guarantee of the machine, as far as use of the subject Software is
concerned, becomes void.
If at any given moment the conditions of use mentioned at par. 2.1 and 2.2 are not
met any more, the Licensee has the duty to destroy or to make unworkable all
copies of the Software which at whatever title happen to be available to him.
4.2 The User acknowledges that Licensor reserves all rights not expressly provided for
in this Agreement. For all conditions not expressly mentioned in this Agreement,
reference is hereby made to the provisions of Law prevailing in this field.

5. DISCLAIMER OF WARRANTY
5.1 This Software is provided "AS IS" without warranty of any kind, either expressed or
implied. Neither Licensor nor its suppliers warrant that the software or any use of
the software or equipment will be uninterrupted or error-free. In no event shall the
author, copyright holder or any other party who may redistribute the Software be
liable to the Licensee for damages. This includes any general, special, incidental
or consequential damages arising out of the use or inability to use the Software
(including, but not limited to, loss of data, data being rendered inaccurate, loss of
business profits, loss of business information, business interruptions, loss
sustained by you or third parties, or a failure of the Software to operate with any
other software) even if the author, copyright holder or other party has been advised
of the possibility of such damages.

6. LIMITATION OF LIABILITY
6.1 In no event Licensor aggregate liability to Licensee or any third party for any losses
or damages that arise out of the performance or breach of this Agreement, whether
in contract, tort, or other form of action, shall exceed the total fees paid to Licensor
under this Agreement. In no event shall Licensor be liable for any direct or indirect
damages, including, but not limited to, lost profits, loss of goodwill, data loss,
business disruption, or computer failure. Licensee acknowledges that the license
fees reflect the allocation of risk set forth in this Agreement and that Licensor would
not enter into this Agreement on the terms hereof without these limitations on its
liability.

7. TERMINATION
7.1 Licensor has the right to terminate this Agreement and Licensee's right to use this
Software upon any material breach by Licensee. If either party breaches a
provision of this Agreement, the other party may give written notice of default. If the

343
Comau Robotics Product Instruction

END USER LICENSE AGREEMENT

breaching party fails to cure the breach within sixty (60) days, this Agreement may
be terminated immediately by the other party. In the event that Licensee breaches
any of the licensing or confidentiality provisions of this Agreement, this Agreement
shall terminate immediately upon written notice by Licensor. Failure to pay any or
all fees due hereunder shall constitute a material breach of this Agreement.
7.2 Upon any termination of this Agreement, all licenses granted hereunder shall
cease, and Licensee shall make no further use of the Software and shall either
return to Licensor or destroy originals and all copies of the Software and supporting
materials. No refunds or credits will be due Licensee.
7.3 The Agreement immediately terminates if Licensee breaches the prevision of
sections n. 3.

8. MODIFICATION
8.1 This Agreement may be modified only in writing signed by both parties. Terms and
conditions on any Licensee purchase order or other ordering document shall not
be deemed to modify this Agreement, and are hereby replaced and superseded by
the terms and conditions of this Agreement. Additional purchases of Software
licenses by Licensee without execution of another agreement will be governed by
the terms of this Agreement unless the parties otherwise agree in writing. The
failure by either party to insist upon strict enforcement of any terms and conditions
of this Agreement shall not be construed as a waiver of the right to assert or rely
upon any such terms on any future occasion.
8.2 This Agreement or other legally binding document(s) referred to the Software,
constitute the entire agreement between the parties with respect to the subject
matter hereof and supersedes any prior or contemporaneous representations,
promises, warranties, or understandings between the Parties. This Agreement
shall be considered accepted and shall become effective by the Licensee's use of
the Software.

9. APPLICABLE LAW, JURISDICTIONAL MATTERS

9.1 This Agreement is governed by and construed under the laws of Italy without
regard to its conflict of law rules. Any action arising out of or in connection with this
Agreement may be heard exclusively in Turin, (Italy), and the Licensee hereby
irrevocably consent to the exclusive jurisdiction and venue of this court.

10. COMUNICATION
10.1 All notices required hereunder shall be in writing and sent by certified mail,
express mail, or via electronic means agreed-upon by the parties, such as
facsimile, to the registered addresses of the parties.

344
 Original instructions

Made in Comau