KST CR Motion Cooperation 22 en

SOFTWARE
KR C2
KUKA.CR Motion Cooperation 2.2
For KUKA System Software (KSS) 5.3/5.4/5.5/5.6
Issued: 10 Jun 2009 Version: 02
KUKA.CR Motion Cooperation 2.2 06.09.02 en 1 of 144

e Copyright 2009
KUKA Roboter GmbH

This documentation or excerpts therefrom may not be reproduced or disclosed to third parties without the express permission of the publishers.
Other functions not described in this documentation may be operable in the controller. The user has no claims to these functions, however, in
the case of a replacement or service work.
We have checked the content of this documentation for conformity with the hardware and software described. Nevertheless, discrepancies
cannot be precluded, for which reason we are not able to guarantee total conformity. The information in this documentation is checked on a
regular basis, however, and necessary corrections will be incorporated in subsequent editions.
Subject to technical alterations without an effect on the function.
2 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Target group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 The cooperating robots concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Synchronization of the motion start (Program Cooperation) . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Synchronization of the motion time (Motion Cooperation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Geometric coupling (master/slave) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Direct geometric coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Indirect geometric coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Forms of cooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Load sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Process--dependent procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Combined procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.4 Extended master--slave principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Control system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Safety instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 The KUKA.CR concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Function blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 CR controller concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 Shared pendant (KCP2--SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2 Control cabinets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.3 Networking in Windows XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.4 Networking in VxWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.5 CR cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.6 Safety Selection Board user interface (SSB--GUI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Installation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1 System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1 Installing the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2 Updating the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.3 Uninstalling the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.1 Operating system network cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.2 CR cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7 Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1 Positional accuracy/installation type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.2 Mastering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2.1 EMT mastering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2.2 Load data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.3 Supplementary load data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3 Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.3.1 Calibration of tools/base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.3.2 Calibration of robots relative to one another . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8 Shared pendant (KCP2-- SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8.1 Signal lamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.2.1 Network connection types: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.2.2 Network class and subnet mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.2.3 Windows network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2.3.1 IP addresses in the Windows network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2.3.2 Assigning the computer name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.2.3.3 Terminating the Windows network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.2.4 VxWorks network (cell configuration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.3 Cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.3.1 Status window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.3.2 Address window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.4 Activation of CR simulation (CellMap Simulation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.5 Safety Selection Board (SSB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.5.1 Lamp test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.5.2 Switching drives on/off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.6 Configuration of the controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.6.1 KCP master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.6.2 First client controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.6.3 Second client controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.6.4 CR cabling and final SSB test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.7 Decoupling a controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.7.1 Client controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.7.1.1 Carry out cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.7.1.2 Carry out cold restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.7.1.3 Change the cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.7.1.4 Lamp and motion test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.7.2 Host controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.7.2.1 Carry out cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.7.2.2 Carry out cold restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.7.2.3 Change the cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.7.2.4 Lamp and motion test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.8 Coupling a controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.8.1 Install the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.8.2 Carry out cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.8.3 Carry out cold restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.8.4 Remove standard KCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.8.5 Carry out cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.8.6 Carry out cold restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.8.7 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

9 Program Cooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.1 Program synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.1.1 The PROGSYNC command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.1.1.1 WAIT option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.1.1.2 NO WAIT option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.2 Shared workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.2.1 Functional principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.2.2 Setting up and configuring workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.2.3 Displaying the status of a workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.2.4 Restoring the status of a workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
9.2.5 Setting the commands ENTERSPACE and EXITSPACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.2.5.1 ENTERSPACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.2.5.2 EXITSPACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.2.6 Entry of actions running in parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.2.7 Simulating workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.3 Program control (Remote Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9.3.1 RemoteRead() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9.3.2 REMOTE START . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9.3.3 REMOTE WAIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9.3.4 Templates for polling REMOTE commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
9.4 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
9.4.1 SyncCmd() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
9.4.2 RemoteCmd() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
9.4.3 StrTo...() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.4.4 CancelProgSync() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.5 System variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.5.1 $COOP_KRC[ ] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.5.2 $PINGCOOPKRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.5.3 $LOCAL_NETWORK_OK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
9.5.4 $COMPLETE_NETWORK_OK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
9.5.5 $WorkspaceRestoreActive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
9.6 Program examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9.6.1 Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9.6.2 REMOTE commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
10 Motion Cooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.1 Motion synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
10.1.1 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
10.1.2 Geometric coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
10.2 Work Cell Diagram (WCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
10.2.1 Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
10.2.2 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
10.2.3 Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10.2.4 Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10.2.5 Fixed tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
10.2.6 Position points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
10.2.7 Mirroring position points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.2.7.1 Axis: Mirroring in the base coordinate system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.2.7.2 Geometric: Mirroring using the 3--point method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

10.3 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

10.3.1 Geometric coupling via $BASE (GEOLINK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.3.1.1 Functional principle in the KRL program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
10.3.2 Block--by--block synchronization (SYNC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.3.3 LK function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
10.4 Program structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.4.1 Load sharing with GeoLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.4.1.1 Solutions with GEOLINK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.4.2 Solution with SYNCCMD(), LK() and zero block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
10.4.3 Master/slave procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
10.4.4 Base reference of point positions in the WCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
10.5 Program examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
10.5.1 Load sharing process with two robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
10.5.1.1 Master program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
10.5.1.2 Slave program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
10.5.2 Load sharing process with two robots and an external axis . . . . . . . . . . . . . . . . . . . . . . . . . . 128
10.5.2.1 Master/slave procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
10.5.3 Process--dependent procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
11 Error treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

11.1 Deadlock of cooperating robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
11.1.1 Checking for deadlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
11.1.2 Enabling a workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
11.2 Missing network connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
11.3 Safety circuit (ESC) broken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
11.4 Robot cannot be jogged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
11.5 No connection established to client controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
11.6 Safety Selection Board (SSB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
11.7 Coupling does not work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
12 Abbreviations / technical terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

12.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.2 Technical terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

1 Introduction
1 Introduction
This documentation deals with the topic Cooperating Robots and the relationship between
the modules
G Shared Pendant
G Program Cooperation
G Motion Cooperation
If additional technologies are used (e.g. TouchSense, MultiArc, etc.), the relevant technol-
ogy documentation must also be observed.
1.1 Target group

This documentation is aimed at people with KUKA robot programming experience and basic
knowledge of network technologies.


2 The cooperating robots concept
2 The cooperating robots concept

One talks of cooperation between robots when their continuous path motions are synchro-
nized, or synchronized and geometrically coordinated.
These forms of cooperation are called synchronization and geometric coupling.
2.1 Synchronization
A distinction must be made between the following types of synchronization:
2.1.1 Synchronization of the motion start (Program Cooperation)

Irrespective of what motions they have been executing before, a simultaneous start is forced
for all robots at synchronization point t1. The individual controllers then resume their program
execution independently of one another. The synchronization is ended.
t t t
R1 R2 R3
3 3
3
3
3
1 3 2 1 3 1 3
t1 4
4 3 2
3
3 2 3
3
3 3
(1) Synchronization point

(2) Synchronization command
(3) Point on path
(4) Wait
Fig. 1 Synchronized motion start
The synchronized start is programmed in the individual programs by means of the command
PROGSYNC. This command can be used any number of times at any point in the program.
In the example (Fig. 1), controller R2 reaches the synchronization command first and must
thus wait the longest. Controller R1 reaches the synchronization command last, thereby de-
termining the synchronization point t1.
This kind of synchronization is also called program synchronization and forms the basis of
the technology package Program Cooperation.

2.1.2 Synchronization of the motion time (Motion Cooperation)

Irrespective of what motions they have been executing before, an identical motion time is
forced for all robots in the synchronization period t1. The individual controllers then resume
their program execution independently of one another. The synchronization is ended.
t t t
R1 R2 R3
3 3
3
3 3 3
t1
1 3 2 1 3 1 3
4
4 3 2
3
3 2 3
3
3 3

(3) Point on path
(4) Wait
Fig. 2 Synchronized motion time
The synchronization period t1 is programmed in the individual programs by means of the

command SYNC. This is an additional component of the LIN or CIRC motion command. Any
number of such synchronization periods can be programmed at any position in the programs.
The total planning time for the following synchronization is communicated between the con-
trollers in the advance run. Each robot adapts its velocity to the robot with the lowest path
velocity.
In the example (Fig. 2), controller R2 reaches the program command first and must thus wait
the longest. Controller R1 reaches the program command last, thereby determining the start
of the synchronization period. It is not necessary to repeat the SYNC command to end the
synchronization.
The program command SYNC forms the basis of the Motion Cooperation module.

2 The cooperating robots concept (continued)
2.2 Geometric coupling (master/slave)

Geometric coupling refers to path--synchronized robot motion.
Path--synchronized robot motions are possible when the separate kinematic systems are
combined. One robot follows the flange motions of a second robot either directly or indirectly.
Three conditions must be met:
(1) Selection of a master robot, which specifies independent motion blocks.
(2) Coordinated calibration of the robots in relation to one another (Fig. 3: LK_ROOT).
(3) Establishment of a kinematic chain between the robots.
The base coordinate system of the slave robot is relative, via an LK_Offset, to the
flange coordinate system of the master robot.
1
Slave
Master
$TOOL
$BASE
$WORLD
$ROBROOT
(1) Flange coordinate system
(2) LK_OFFSET (difference between $BASE and the flange coordinate system)
(3) LK_ROOT (difference between $ROBROOT and $WORLD)
Fig. 3 Geometric coupling

2.2.1 Direct geometric coupling

The slave follows the motions of the master robot directly.
Both robots are synchronized and perform identical linear or circular motions.
The slave requires no separate motion commands of its own. The interpreters of both robot
programs are synchronized by means of PROGSYNC commands at the start and end of the
motion.
This form of motion is used in load sharing.
2 2
1 1
Master Slave
(1) Synchronous linear motion of master and slave
(2) Synchronous circular motion of master and slave
Fig. 4 Motion with direct coupling
Fig. 5 Load sharing
2.2.2 Indirect geometric coupling

The slave follows the motions of the master robot indirectly.
The slave robot performs superposed, synchronous linear or circular motions.
The basic motions (1) are synchronous, as with direct coupling. The motions (2) of the slave
consist of different linear or circular motion blocks, which are superposed on the basic mo-
tions.
1 2
Master Slave Slave

(1) Linear motion of master and slave
(2) Synchronous circular motion of the slave
Fig. 6 Superposed motion in the case of indirect coupling

The slave executes its own motion blocks and synchronizes these with the workpiece mo-
tions of the master (process--dependent procedure).
Master
Slave
Fig. 7 Process--dependent procedure
2.3 Forms of cooperation

G Load sharing
G Process--dependent procedure
G Combined procedure
G Extended master--slave principle
2.3.1 Load sharing

Load sharing consists of geometrically coupled robots, whose motions are identical and syn-
chronized once the workpiece has been picked up.
The kinematic systems are combined to form a self--contained chain. The slave follows the
motions of the master directly. It is programmed in the base coordinate system of the master.
Slave
$BASE
Master
Fig. 8 Load sharing

2.3.2 Process--dependent procedure
$BASE
Master Slave
A
Fig. 9 Process--dependent procedure
Fig. 9 illustrates a form of cooperation between geometrically coupled robots. It is called a

process--dependent procedure. The slave processes the workpiece while it is being trans-
ferred from A to B by the master. In such a case, the master acts as a transfer and positioning
robot, while the slave is used as a process robot. During the transfer process, the master
keeps the workpiece constantly in an optimal processing position.
The base coordinate system of the slave is relative to the flange coordinate system of the
master robot. In this way, the relative positioning of the workpiece and tool is retained during
motions of the workpiece.
Geometric coupling of several slaves with the master is also possible (Fig. 10). Here, once
again, the tool motions of the slaves are relative to the motions of the workpiece.
Master
$BASE
Slave1 Slave2
Fig. 10 Extended process--dependent procedure

2.3.3 Combined procedure

If load sharing is combined with process--dependent variants, the following form of coopera-
tion is possible, for example (Fig. 11).
Two robots in load sharing mode guide a workpiece while allowing it to be processed by a
third robot. Both slaves are geometrically coupled with the master: slave 1 working in load
sharing mode with the master and slave 2 in process--dependent mode.
Master $BASE
Slave2
Slave1
Fig. 11 Combined procedure
2.3.4 Extended master--slave principle

The extended master--slave principle refers to the cooperation between two or more robots
and an external axis (e.g. linear unit or turntable).
The master is linked to a mobile external axis and performs geometrically coupled tasks to-
gether with a second robot mounted on the external axis.
Master Slave
EASYS
Fig. 12 Extended master--slave principle

2.4 Control system

KUKA controllers allow the integration of PLC functions:
G Synchronization of motion starts and motion blocks.
All the controllers wait at a defined synchronization point or force motion blocks of iden-
tical duration.
G Monitoring and control of the workspaces.
Enabling and disabling of shared workspaces and indication of their current status.
Fig. 13 Shared workspace
G Control of one robot by another by means of REMOTE commands.

Each controller can start programs on other controllers and monitor their status.
Important communication and safety data are exchanged in real time via an independent net-
work.
All controllers can be accessed centrally by means of a single shared pendant. This can be
used for start--up, configuration and program management of the whole group of controllers.

3 Safety instructions
3 Safety instructions
Before the KUKA.CR Motion Cooperation technology package is put into operation, the
general safety regulations for the robot system supplied by KUKA must be observed.
Please refer to the chapter [Safety] in the Operating Handbook.
The robot system may only be used in technically perfect condition in accor-
dance with its designated use and only by safety--conscious persons who are
fully aware of the risks involved in its operation.
The following constitute a risk of danger to life and limb and can cause serious dam-
age to machinery:
-- incorrectly configured robot controllers.
-- incorrectly programmed shared workspaces.
-- insufficient attention to spatial interaction of reciprocal interlocks.
Accident prevention regulations must be observed, particularly when testing pro-
grams!


4 The KUKA.CR concept
4 The KUKA.CR concept

The diagram illustrates the structure of the KUKA.CR Motion Cooperation technology
package.
Motion Cooperation
Linked Kinematic (LK) Motion Sync Work Cell Diagram (WCD)
Program Cooperation
Cell Map PROGSYNC Workspace Sharing Remote Command
Shared Pendant
Cell Map Safety Selection Board (SSB)
KUKA.CR Motion Cooperation
KUKA System Software (KSS)
Operating system
Fig. 14 KUKA.CR Motion Cooperation function blocks
4.1 Function blocks

G Cell configuration (Cell Map):
Serves to define the group structure of cooperating robots. Here the controllers are as-
signed ranks, IP addresses, etc.
G Safety Selection Board (SSB):
An additional KR C2 edition05 component which, in Test mode, allows the safe selec-
tion of the robot drives displayed in a separate user interface (SSB--GUI). Once the
drive has been selected and activated, this state is locked in the ESC for safety pur-
poses. This prevents unintentional activation of other drives.
G PROGSYNC:
Program command that synchronizes the program sequence of the controllers in-
volved. This command defines a synchronization point.

G Workspace Sharing:
Subprogram for setting up and monitoring workspaces. Controls the intersection of
cooperating robot workspaces.
G Remote Command:
This program command can be used to execute commands on other controllers (pro-
gram start and stop, assignment of global variables, etc.).
G Linked Kinematic (LK):
Basic function of geometric coupling (master/slave function). The base reference is
transferred to another robot (or external axis) for the duration of the geometric coupling.
G MotionSync:
Basic function for synchronization of motion blocks. It makes it possible to add a SYNC
command to a LIN or CIRC motion block. The synchronized motion block forces all the
robots involved to work with the same motion time for the subsequent motion.
G Work Cell Diagram (WCD):
Configuration program with its own user interface displaying directories and data lists.
Here, the robots, tools and geometric dependencies are defined.

4 The KUKA.CR concept (continued)
4.2 CR controller concept

The controllers exchange in real time, via network connections, all data required for synchro-
nization and geometric coupling and any relevant safety data. If the data connection is broken
or if safety--relevant data are communicated, the entire control system is switched to a safe
state.
The controller concept is expandable. Subgroups are possible, and individual robots can be-
long to more than one group.
Network features:
G The system is operated using a single KCP (KCP2--SP).
G Control cabinet (KR C2 edition05 or later) with Safety Selection Board for safe selection
of drives.
G CR cabling separate from the rest of the network cabling.
G A fully configurable switch with separate areas for the VxWorks network and the Win-
dows network. Alternatively, a standard switch for each network.
4
3
5
2
1
2 2 2
6 6
(1) Shared pendant (KCP2--SP)

(2) KR C2 edition05 with Safety Selection Board
(3) Windows network
(4) Fully configurable switch
(5) VxWorks network
(6) CR cabling
Fig. 15 Controller concept
4.2.1 Shared pendant (KCP2--SP)

The shared pendant is the hardware component of the module of the same name.
Range of functions:
G Operator control of multiple controllers.
The controllers of all the robots to be used together in cooperating mode are configured
and operated using a shared pendant.
G Management of all controllers via the Terminal Client Server software.
The shared pendant can be used to access the cell configuration of every controller
(Terminal Client Server). The group structure of the cooperating robots can be defined
here according to the system concept.

G Cell configuration.
All operator control steps that are carried out separately for each individual controller,
in the case of singly networked controllers, for example, are grouped together using
this software concept via the common user interface cell configuration (Cell Map).
G Activation of the drives via the Safety Selection Board user interface.
The Safety Selection Board present in all control cabinets contains the shared user in-
terface SSB--GUI. This can be used to display and control the operating state of the
robot drives.
4.2.2 Control cabinets

The KR C2 control cabinet (KR C2 edition05 or later) is used with Safety Selection Board.
This additional hardware is used to process and forward safety data (E--Stop, power failure,
etc.) immediately to all controllers.
4.2.3 Networking in Windows XP

The devices in the CR group are networked via a standard switch.
4.2.4 Networking in VxWorks

Networking in VxWorks allows transmission of the real--time data. A standard switch is used
for this.
4.2.5 CR cabling
The CR cabling allows transmission of the following data:
G Time pulse from the host controller.
G ESC safety signals.
G Switch signals for robot drives.
4.2.6 Safety Selection Board user interface (SSB--GUI)

The SSB--GUI is used to select the robots in the CR group and activate the drives. When
a robot is switched to active, a signal lamp lights up on the robot in question.
Each controller can be assigned a color via the cell configuration.

4 The KUKA.CR concept (continued)
Fig. 16 SSB--GUI


5 Installation checklist
5 Installation checklist
The KUKA.CR Motion Cooperation technology package consists of the individual modules
Shared Pendant, Program Cooperation and Motion Cooperation.
Depending on the scope of supply, the following steps must be carried out:
(1) Record all the required data for the controllers concerned in a commissioning checklist.
Robots Computer/ Kernel sys- Windows IP KCP client Clock- Color

robot
b name tem IP *2 S
Sync
*1
Con- No
KCP master
nected KCP
KPR5--03 RT1 192.0.10.1 170.170.6.1 X X Red
KPR5--04 RT2 192.0.10.2 170.170.6.2 X Green
KPR5--07 RT3 192.0.10.3 170.170.6.3 X Orange
KPC--01 RT4 192.0.10.4 170.170.6.4 X Magenta
KPC--02 RT5 192.0.10.5 170.170.6.5 X Yellow
*1 For the sake of clarity, the designations for the computer name, robot name and KRC name (cell configu-
ration) should be the same.
*2 The controller with the shared pendant should have the lowest IP address.
Table 1 Sample commissioning list
(2) Install the operating system and KSS. Install the KUKA.CR Motion Cooperation
technology package. At the start of the installation process, enter the IP address for the
VxWorks network.
(3) Enter IP address and computer name in the Windows network.
(4) Set up the cell configuration and set the option Force cold start. Switch off the control-
ler and remove the KCP. Carry out steps (2) ... (4) for all controllers.
(5) Connect CR cables and terminating resistors (X70/71).
(6) Connect network cables (X17/18).
(7) Connect signal lamp to axis 3 of the robot (XP3--L). Connect lamp to RDC with RDC
cable. Only use a fully wired RDC cable.
(8) Connect a shared pendant to the host controller (connected KCP). Switch all controllers
on.
(9) Check the network connections in the cell configuration on the host controller. The icons
for the kernel system and operating system must indicate a connection (yellow dot) for
every controller.
(10) Using the keyboard shortcut SYM + Window selection key, toggle to each controller
in the group.

(11) Switch on SSB--GUI using pushbutton and carry out lamp test. Activate the drives of
each robot and execute a test run with each robot.
(12) Call WCD (Work Cell Diagram) on every controller and enter mechanisms and tools.
Additionally, define a base on every master.
(13) With each robot, carry out a tool calibration (4--point) with a suitable tool (e.g. reference
pin).
(14) Calibrate the master as an external machine on every slave (Root).
(15) Test the geometric coupling. To do so, call the status window for the current tool/base
on the slave. Specify the base system as the base for the master. The base of the mas-
ter does not need to be calibrated (null frame). When the master is jogged, the slave
follows its motions.

6 Installation
6 Installation
6.1 System requirements
Software
G KUKA System Software 5.3, 5.4, 5.5 and 5.6
G KUKA.CR Motion Cooperation 2.x
Hardware
G Industrial robot from KUKA Roboter GmbH with signal lamp
G KR C2 edition 05 control cabinet for KUKA.CR (with the option SSB (Safety Selection
Board))
G A fully configurable switch (manageable switch) with separate areas for the VxWorks
network and the Windows network. Alternatively, one standard switch each for the
VxWorks network and the Windows network. For two controllers, a crossed network
cable without a switch can be used.
G CR connecting cables
6.2 Software
6.2.1 Installing the software
It is assumed that the KUKA.CR Motion Cooperation technology package has been pre--
installed.
If the technology package has not been installed, this must be downloaded from the CD--
ROM.
In the case of uncertainty, please do not hesitate to contact the Customer Support depart-
ment at KUKA Roboter GmbH.
The installation procedure is the same for all technology packages and is described in a sepa-
rate documentation module.
Basic information about the installation of technology packages can be found in the docu-
mentation [Installation / Uninstallation / Update of Tech Packages].
6.2.2 Updating the software

Updates are loaded with the Windows operating system running.
(1) Place the update CD in the CD--ROM drive.
(2) In Windows Explorer:
run CD--ROM drive:\ KUKA.CR--MC\ Setup.exe.
6.2.3 Uninstalling the software

Uninstallation is carried out as follows:
(1) Disconnect the controller concerned from the networks and CR cabling.
(2) Connect KCP2--SP or KCP2 to the controller.
(3) Switch to the Windows user interface and then, in Windows Explorer:
run C:\ KRC_OPTION\ MOTIONCOOP\ UNINST\ UnInstall.exe.
(4) Switch the controller off and back on again.

6.3 Hardware
6.3.1 Operating system network cabling
The cabling of the network for the Windows and VxWorks operating systems must be carried
out as illustrated in the example in Fig. 17. The shared pendant or any standard KCP can
then be connected to any controller (e.g. during cell configuration).
RT1 RT2 RT3
(1) Windows network (on--board)

(2) Shared memory
(3) VxWorks network (additional plug--in card)
(4) Standard switch
(5) Standard switch
Fig. 17 Operating system network cabling
If there are two controllers, a crossed--cable connection suffices.

Both networks can also be networked using a shared configurable switch with separate
areas. In this case, the switch must support VLANs and be configured accordingly.

6 Installation (continued)
6.3.2 CR cabling
The CR cabling and the connection of the shared pendant are not carried out until
after completion of the Windows and VxWorks network configuration.
The CR cabling of the control cabinets must carried out as illustrated in the diagram (Fig. 18):
1 2
CR--OUT CR--OUT CR--OUT

CR--IN CR--IN CR--IN
X19
3
5
4
(1) Start of the CR cabling at the control cabinet with the shared pendant
(2) End of the CR cabling
(3) X71 terminating resistor CR--IN
(4) CR connecting cable
(5) X70 terminating resistor CR--OUT
Fig. 18 CR cabling
The vacant slots X71 / X70 must always be fitted with appropriate terminating resis-
tors.
The first control cabinet is the one with the shared pendant connected.
1 2

Fig. 19 Terminating resistors X70/71


7 Commissioning
7 Commissioning
In order to achieve a precise geometric coupling of the robot, the following checks and set-
tings must be carried out in the specified sequence.
(1) Positional accuracy
(2) Mastering
(3) Calibration
General information can also be found in the Operating Handbook, in the chapter
[Start--up].
7.1 Positional accuracy/installation type

The property Positionally accurate robot can be checked via the Help menu.
(1) Open the menu [ Help Info Robot ].
A text window appears in which the information can be read. If this window contains any
other entry, please contact KUKA Roboter GmbH Technical Support.
(1) Installation type

(2) Robot type
Fig. 20 Info window: Robot

(2) Check the factory setting for the installation type.

The following factory settings are possible:
-- FLR Floor--mounted
-- W Wall--mounted
-- K Shelf--mounted
-- C Ceiling--mounted
Because of the risk of injury or material damage, no changes may be made without
consulting KUKA.

7 Commissioning (continued)
7.2 Mastering
All cooperating robots must be mastered, even in the absence of supplementary loads.
7.2.1 EMT mastering

The mastering procedure to use is EMT mastering with load correction.
Using this method, the load data (weld gun, etc.) can be corrected. Mastering is carried out
in the following steps:
First mastering
(1) Remove load (e.g. weld gun).
(2) Open the menu [ Setup Master EMT With load correction First mastering ].
(3) Carry out mastering.
Teach offset
(4) Attach load (e.g. weld gun).
(5) Open the menu [ Setup Master EMT With load correction Teach offset ].
(6) Carry out mastering and calculate load data.
Load mastering
(7) In the menu [ Setup Master EMT With load correction Master load ], select one
of the processes.
In both cases, possible errors from the first mastering are eliminated.
-- With offset
The existing load remains mounted. This type of mastering is required after a collision
or exchange of a drive motor.
-- Without offset
Any load can be mounted. This type of mastering is error--free if no subsequent me-
chanical modifications have been made to the robot (exchange of motor or compo-
nents).

7.2.2 Load data

The load data of the tool used are entered in the Load tab of the WCD.
Fig. 21 Load data entry
In order to prevent unexpected robot motion and thus avoid the possible risk of
injury or material damage ...
1. all load data (including the factory settings) must be set to zero if there is no load
present.
2. load data must always be entered if there is a load present.
7.2.3 Supplementary load data

If there is no supplementary load present, all factory settings for the supplementary load on
axis 3 must be reset to zero. Otherwise, the accuracy of the CP motions could be limited.
(1) Open the menu [ Setup Measure Supplementary load data ].
(2) Set all boxes to zero, including the box M[kg].
Fig. 22 Supplementary load data for axis 3 if no supplementary load is present
If there are supplementary loads present, these must be specified in the dialog window
(Fig. 22). If the box M[kg] contains the entry --1, the predefined factory settings are used.

7.3 Calibration
7.3.1 Calibration of tools/base
The positional accuracy of cooperating robots requires the following:
G Every tool or base must be created in the Work Cell Diagram and assigned the correct
load data.
General information on this topic can be found in the chapter [Operator Control].
G Each tool must be calibrated. The XYZ 4--Point method is generally used for this.
General information about calibration can be found in the Operating Handbook, in the chap-
ter [Start--up].
7.3.2 Calibration of robots relative to one another

In the case of geometric coupling between two robots, the distance between the robot root
points must be known to the controllers. The two robots can then be coupled to form a closed
kinematic chain.
The slave robot must be informed of the position of the master robot.
The following calibration programs are available:

G [ Setup Measure External Machine Root ]
The location of the external robot (here: external machine) is determined using the cal-
culation functions of the local robot.
G [ Setup Measure External Machine Root -- Numeric Entry ]
The location of the external robot has already been calibrated and is communicated to
the local robot by entering data directly.

Root
In Fig. 23, the external robot RT1 (master) is to be calibrated by the local robot RT2 (slave).
The measuring tip of RT1 is moved to four different positions, and the measuring tip of RT2
is moved to it in each of these positions.
Both robots are to be moved during the calibration procedure.
RT2 (slave)
RT1 (master)
1
2
(1) Measuring tip of RT1

(2) Measuring tip of RT2
Fig. 23 Calibration of RT1 by RT2
Preparatory work
1. Installation of the measuring tips on both the external and the local robot.
2. Creation of all tools in the Work Cell Diagram.
Measurement procedure
You are working with the user interface of the local controller of RT2.
(1) Open the menu [ Setup Measure External Machine Root ].
(2) Select the external robot RT1 using the status key [ # ].
Fig. 24 Selecting the external robot

(3) Press the softkey [ OK ]. This starts the calibration.

(4) Select the external measuring tool then the local measuring tool by pressing [ OK ].
OK OK
Fig. 25 External and local measuring tools
(5) Switch to this window for the local controller of RT1.

(6) Move the measuring tip of robot RT1 to the first position.
The first measurement commences.
(7) Return to the local controller of RT2 and move the measuring tip of the local robot to
that of the external robot.
(8) Press the softkey [ OK ].
The first measurement is now complete. A message is displayed prompting you to carry
out the second measurement.
In order to optimize the results of the measurements, the points selected should be as far
apart as possible.
(9) Repeat steps (6) to (8) three more times.

On completion of the series of measurements, a data window appears in which the calculated
location data of external robot RT1 are displayed. The data refer to the world coordinate sys-
tem of the local robot.
Calibration errors
In the event of calibration errors, corresponding message windows are displayed. The mea-
surement procedure can then be repeated, either fully or partially.
1. Calibration error after measurement too great:
Fig. 26 Measurement error too big
2. Calibration points during measurement too close together:
Fig. 27 Calibration points too close together

Checking the geometric coupling:

Finally, a check is made to see if the two robots can be geometrically coupled with RT1 as
the master and RT2 as the slave.
(1) Select the controller of the slave RT2 as the local controller.
(2) Open the menu [ Configure Cur. tool/base ].
The tool of the slave RT2 still refers to the world coordinate system as its base (null
frame).
(3) Select the base of the master RT1 as the new base using the status key [ # ].
In the example, the base of RT1 (here: B_RT_1) has been created under base no. 1.
Fig. 28 Base selection

The two robots are now geometrically coupled.
(5) Switch to controller RT1 as the local controller and jog RT1.
The slave now follows the motions of the master.

Root -- Numeric Entry

In the example, the location of the external robot RT1 has already been calibrated and is com-
municated to the local robot RT2 by entering data directly.
You are working with the user interface of the local controller of RT2.
(1) Select the controller of robot RT2 as the local controller.
(2) Open the menu [ Setup Measure External Machine Root -- Numeric Entry ].
(3) Select the external robot RT1 using the status key [ # ].
The corresponding position and orientation values can be entered directly.
Fig. 29 Numeric entry
(5) Save the entered values by pressing the softkey [ OK ].

8 Shared pendant (KCP2--SP)
8 Shared pendant (KCP2-- SP)

The shared pendant (KCP2--SP) allows the operator control, programming and configuration
of several robot controllers in a CR group using a single KCP.
3 4
2
1
(1) Mode selector switch

(2) Drives ON
(3) SSB--GUI
(4) EMERGENCY STOP
Fig. 30 Shared pendant (KCP2--SP)
The shared pendant offers the following options:

G All functions of the standard KCP
G Management of all robot controllers
G Cell configuration via Cell Map user interface
G Activation of drives via SSB--GUI

8.1 Signal lamps

Each robot has a signal lamp (Fig. 32). This lamp is switched on in T1/T2 mode and switched
off in Automatic mode.
The lamp test checks whether or not the lamp is functioning correctly. The drives cannot be
activated if the lamp is defective.
If a lamp defect occurs in Automatic mode, the safety circuit is not broken and the production
process can continue uninterrupted.
1 2 3 4
1 2
(1) Resolver connection, axis 3 (XP3)

(2) Connection for RDC cable (XP3--L)
(3) Signal lamp
(4) Fully wired RDC cable
Fig. 31 Signal lamp with connection for axis 3

8 Shared pendant (KCP2--SP) (continued)
(1) Signal lamp on robot
Fig. 32 Robot fitted with signal lamp

8.2 Network
The controllers exchange all required data via network connections. If the data connection
is broken or if safety--relevant data are communicated, the entire control system is switched
to a safe state.
The controller concept is expandable. Subgroups are possible, and individual robots can be-
long to more than one group.
Network features:
G The system is operated using a single KCP (KCP2--SP).
The KCP is connected to the control cabinet at which the CR cabling starts.
G Control cabinet with Safety Selection Board for safe selection of drives.
G CR cabling, separated from the rest of the network cabling, for the transfer of time
pulses, safety--related signals and switch signals for robot drives.
G A fully configurable switch with separate areas for the VxWorks network and the Win-
dows network. Alternatively, one standard switch each for the VxWorks network and
the Windows network. Crossed network cables if two control cabinets are being used.
Only use network components recommended by KUKA Roboter GmbH. More detailed in-
formation is available from the KUKA hotline.
8.2.1 Network connection types:

G Networking using crossed network cables. The system cannot be integrated into the
company network.
3
1
2 2

(2) KR C2 with Safety Selection Board
(3) Windows network (crossed network cable)
(4) VxWorks network (crossed network cable)
(5) CR cabling
Fig. 33 Two controllers without a switch

G Networking using a fully configurable switch with two separate areas (recommended).
The system can be integrated into the company network via the Windows network area.
4
3
5
2
1
2 2 2
6 6

(3) Windows network
(4) Fully configurable switch
(5) VxWorks network
(6) CR cabling
Fig. 34 Controllers with a fully configurable switch
G Networking using two standard switches. The system can be integrated into the com-
pany network via the Windows network switch.
3 4
5 6
1
2 2 2
7 7

(3) Windows network
(4) Standard switch
(5) VxWorks network
(6) Standard switch
(7) CR cabling
Fig. 35 Controllers with more than one switch

8.2.2 Network class and subnet mask

The network class determines the maximum possible number of computers in a network.
A distinction is made between A--, B-- and C--class networks.
The subnet mask determines which computers within the same network class can access
one another. Only computers with the same subnet mask and matching IP addresses can
communicate with one another.
Windows network (LAN)

A B--class network is set as standard (IP address range 128.0.0.0 to 191.255.255.255).
The subnet mask is set to the default value 255.255.0.0. The first two IP fields must therefore
be the same for every computer in this network (e.g. 170.170.xxx.xxx).
The IP address and subnet mask are set via the Windows Control Panel.
VxWorks network
A C--class network is set as standard (IP address range 192.0.0.0 to 223.255.255.255).
The subnet mask is set to the default value 255.255.255.0. The first three IP fields must
therefore be the same for every computer in this network (e.g. 192.0.10.xxx).
The settings for the VxWorks network can be accessed via the cell configuration.
Shared memory network (SM)

C--class network (IP address range 192.0.1.xxx).
The subnet mask is set to 255.255.255.0.
The addresses for the shared memory were already entered automatically during installation
of the system software.
Do not change the settings for the shared memory network! They are purely for in-
formation purposes.
Do not use the IP address range of the shared memory network for other networks.

8.2.3 Windows network

The Windows network must be configured on each of the controllers in the cooperating robot
group. Configuration can then be carried out by connecting a shared pendant or a standard
KCP. The preconditions for this are networking in the operating system and installation of the
KUKA.CR Motion Cooperation technology package on each controller.
Before commencing with the configuration, the following information should be available:
G Unique computer names for the controllers
G IP addresses for the cooperating robot controllers. The addresses must always belong
to the same network class.
G DNS (optional)
G WINS (optional)
G Standard gateway (optional)
G Alternatively, the configuration can be carried out using a DHCP server. This automati-
cally sets the required network parameters (IP, DNS, WINS and gateway). The corre-
sponding parameters depend on the specific company network.
Incorrect configuration can cause serious damage to machinery and constitutes a

risk of danger to life and limb.
8.2.3.1 IP addresses in the Windows network

The following addresses, for example, could be issued to the individual controllers:
Controller IP address Subnet mask Name
1: 170.170.6.1 255.255.0.0 RT1
2: 170.170.6.2 255.255.0.0 RT2
3: 170.170.6.3 255.255.0.0 RT3
... ... ... ...
These IP addresses can be used to identify the Windows network card of each controller.
The lowest IP address must be assigned to the KCP master with the shared pendant. In the
example, this is controller RT1.

The following steps must be carried out:

(1) After booting the controller, minimize the user interface of the system software and re-
turn to the Windows interface.
(2) Select the network connections in the Windows Control Panel. Call up the LAN network
connection properties via the menu bar or the pop--up menu.
Fig. 36 LAN network connection (Windows network)
(3) Select the Internet Protocol (TCP/IP) and open the Properties box.
(4) Enter IP data for the currently selected controller. Enter the data for the standard gate-
way and DNS server if required for the current network.
Fig. 37 Network addresses
Advanced DNS and WINS data are accessed by pressing the Advanced key.

8.2.3.2 Assigning the computer name

The following steps must be carried out:
(1) Open the System Properties window via the Start menu.
(2) Open System and select the Computer name tab.
(3) Press [ Change... ] and enter the desired computer name in the dialog window.
(4) Accept the computer name by pressing [ OK ], but do not yet reboot the system.
8.2.3.3 Terminating the Windows network configuration

To ensure that the entered values are applied, the following must be taken into consideration
when terminating the configuration:
(1) Check whether the option Cold restart is set for all controllers. If necessary, return to
the user interface and set this option via the menu [ Configure On/Off Options Force
cold start ].
(2) Shut down the controllers and perform the cold restarts. This completes the Windows
network configuration.

8.2.4 VxWorks network (cell configuration)

What preconditions must be met?
G The controllers must be networked using crossed cables, standard switches or a fully
configurable switch.
G Each controller is configured in the Windows network.
G All controllers must first have been booted using a cold restart.
On which controllers is configuration carried out?

On all controllers, one after the other, using a standard KCP or KCP2--SP.
Configuration is started on the controller designated in advance as the host controller, which
permanently retains this status both during and after configuration. Following completion of
the configuration and CR cabling, the shared pendant (KCP2--SP) is connected to this con-
troller alone.
Which menu is used to carry out the configuration?

The Cell configuration menu.
Here you will find a table of all the cooperating robots with their names, IP addresses, etc.
What is the procedure for the configuration of, say, three cooperating robots?
The overall configuration is carried out in two sections and comprises the following steps:
G Configuration of the controllers
Host controller
(1) A KCP is connected to a controller designated in advance as the host controller. Config-
uration commences with this controller. The remaining controllers are listed in the table
as client controllers.
(2) All configuration data are entered for each controller, one after the other.
(3) On completion of this configuration, the host controller is shut down and a cold restart
carried out. All data are applied. The KCP is removed.
1st client controller
(4) The KCP is connected to the first client controller and steps (2) -- (3) are repeated for
this controller.
2nd client controller
(5) The KCP is connected to the second client controller and steps (2) -- (3) are repeated
for this controller.

G CR cabling and final SSB test

(1) All controllers are shut down. The CR cabling is carried out and the shared pendant is
connected to the host controller.
(2) All controllers are booted. The SSB user interface is activated and its functions are
checked (lamp test, activation of the drives).
(3) The SSB user interface is closed. The operator toggles to the user interface of each
controller in turn and carries out trial jogging of the drives that have been activated be-
forehand.
(4) The cooperating robot system is configured for Automatic mode.
Schematic overview:
The starting point for the configuration is the host controller, which is also a local controller.
Following data entry, the KCP is moved to a different controller, thereby selecting the new
controller as the local controller, etc.
RT1 RT1 RT1
RT2 RT3 RT2 RT3 RT2 RT3

4 4 4
5 5
1 2 3
(1) Configuration of the KCP master (host controller)
(2) Configuration of the first client controller
(3) Configuration of the second client controller
(4) Switch (standard or fully configurable)
(5) Local controller
Fig. 38 VxWorks network configuration diagram
The host controller should always have the lowest IP address (e.g. 170.170.6.1)
Detailed information on configuration with three controllers can be found in Section 8.6.

8.3 Cell configuration

The cell configuration serves to define the group structure of cooperating robots. During
system configuration, calling the user interface CellMap Configuration causes the
outstanding administration data (controller name, kernel system IP, status of the controller
as host or client, etc.) for the VxWorks network to be entered. This is done separately for each
controller using a standard KCP or the relevant shared pendant.
Open the menu [ Setup Cell configuration ].
1 2
3 x
(1) Status window: Display and status of the controllers

(2) Address window: IP addresses of the controller and information about the shared pendant
(3) Softkey bar
Fig. 39 Cell configuration graphical user interface

8.3.1 Status window

1 2 3 4
8
5 6 7
(1) Local KRC name (5) Status of the VxWorks network

(2) Remote KRC name (6) KCP clients
(3) Color of the local controller (7) Status of the Windows network
(4) Synchronization via master (8) Host controller
Fig. 40 Status window
Local KRC name:

The Local KRC name is the same as the robot name in the status bar of the corresponding
robot.
If the local controller is changed, the robot name (Fig. 41) of the new controller appears in
the box Local KRC name. The data set for this controller is displayed in the right--hand area
of the window.
Fig. 41 Robot name
Remote KRC name:

Lines 2--16 indicate the robot names of the non--local controllers. If these lines are high-
lighted, the relevant data set appears in the right--hand area of the window.

Color:
The individual controllers are assigned colors to aid visual identification.
Clock Sync Master:

This box must be checked if the local controller in question is to serve as a timer (clock mas-
ter) for other controllers. This controlling time pulse is necessary in the case of synchronized
motion sequences.
The clock master is generally the host controller. Exceptions are possible!
Checking / unchecking:
Press the softkey [ Clock Sync ]. Pressing the softkey again deletes the check mark.
Status of the VxWorks network:

The icon indicates the status of the VxWorks network (kernel system):
1
2
(1) Yellow dot: VxWorks network connection active.

(2) Red dot: VxWorks network connection broken.
Fig. 42 VxWorks network
A broken network connection can have the following causes:

G Controller not switched on.
G Network cable defective or not correctly connected.
G No connection between network card and connector (X18).
G Connector (X18) or network card defective.
G Incorrect data in the cell configuration (incorrect name or IP address).
G Incorrect IP address during installation of shared pendant.
In the case of a broken network connection, check first whether the controller in question
is switched on. Check the cables, connectors and switch, if applicable. If a fully configurable
switch is being used, check its configuration also.

KCP Clients:
This check box is displayed on the host controller. If the box is checked, the controller in ques-
tion has its own KCP. In this case, the status of the Windows network is displayed.
No KCP may be connected to controllers for which the KCP Clients box is checked.
If the box is not checked, the controller in question must have its own KCP.
Checking / unchecking (Fig. 43):

Position the focus on the desired box and press the softkey [ Check ]. Pressing the softkey
again deletes the check mark.
1 Not marked: A separate KCP is connected to this controller.

2 Marked: No KCP is connected to this controller.
Fig. 43 Checking / unchecking
Status of the Windows network:

The icon indicates the status of the Windows network (operating system):
(1) Yellow dot: Windows network connection active.

(2) Red dot: Windows network connection broken.
Fig. 44 Windows network
A broken network connection can have the following causes:

G Controller not switched on.
G Network cable defective or not correctly connected.
G No connection between network connection and connector (X17).
G Connector (X17) or on--board network chip defective.
G Incorrect Windows network settings.
G Incorrect data in the cell configuration (name or IP address).

In the case of a broken network connection, check first whether the controller in question
is switched on. Check the cables, connectors and switch, if applicable. If a fully configurable
switch is being used, check its configuration also.
Host controller:
The host must be specified on every client controller.
8.3.2 Address window
(1) KRC name of the controller

(2) IP address of the VxWorks network (kernel system)
(3) Color of the selected controller
(4) Computer name or IP address of the Windows network
(5) KRC type
Fig. 45 Address window

KRC Name:
Entry of a symbolic name for the controller.
The entry can be deleted by pressing the softkey [ Delete ].
Kernel IP Address:
Entry of the VxWorks kernel system address for the controller.
Color:
Pressing the softkey [ Color ] allows you to select a background color for the selected control-
ler. This also appears on the SSB user interface.

Windows Name/IP Address:

The computer name assigned during configuration of the Windows network appears here
or the Windows IP address.
KCP type:
Each local controller requires information about the shared pendant:
Shared KCP: The shared pendant (KCP master) is connected to this controller.
The shared pendant can be used to operate the controllers that
have no KCP of their own.
KCP: A separate KCP is connected to this controller. This controller can-
not be operated using the shared pendant. This KCP type can be
selected for commissioning and test purposes.
No KCP: No KCP or shared pendant is connected to this controller. The
controller is operated via the shared pendant connected to the
KCP master.

8.4 Activation of CR simulation (CellMap Simulation)

CellMap simulation is used to simulate synchronization signals of other cooperating control-
lers and synchronize controller actions. This makes it possible to create and modify pro-
grams and carry out test runs in the absence of the controllers involved.
The following options are available:

[ SCS ] Simulates the synchronization commands for the selected controllers. These
include Program start forwards, the Stop key, the program override and the
program run mode.
[ CAS ] Synchronizes the controller actions with the selected controllers. This includes
program and motion synchronization.
4
3
1 2
(1) Controller number.

(2) Controller name as defined in the cell configuration. The local controller is always listed first.
(3) Simulates the synchronization commands.
(4) Synchronizes the controller actions.
Fig. 46 CellMap simulation dialog window
Peculiarities of CAS:
Program override: if different program override values are set on the controllers in-
volved, the value on the current controller is valid in the case of
[ Start+ ] and activated CAS. Changing the program override dur-
ing program execution changes the value for all the controllers in-
volved.
Program run mode: if different program run modes are set on the controllers involved,
the program run mode on the current controller is valid in the case
of [ Start+ ] and activated CAS.
Execution:
(1) Open the menu [ Monitor > CellMap Simulation ].
(2) Set the options [ SCS ] and [ CAS ] using the corresponding softkey.
Following modifications in the CellMap simulation, a selected program must be reset.

8.5 Safety Selection Board (SSB)

Each controller is fitted with an SSB logic and the shared SSB--GUI user interface. The SSB--
GUI can be used to display and control the operating state of the robot drives.
Fig. 47 SSB--GUI pushbutton
Range of functions:
G Activation / deactivation of the drives in T1/T2 mode
G Deactivation of all controllers if fault detected
G Signal lamp function
If the CR cabling is in place and the pushbutton is pressed (Fig. 47), the operator control func-
tions of the SSB--GUI are available to the user.
Here the user can obtain an overview of all the cooperating robots and activate their drives.
Each controller is indicated in the color selected during cell configuration. The first entry indi-
cates the KCP master with the shared pendant.

1 2 3 4
6 7 8 9
(1) Selected robot (6) Activate drive of the selected robot

(2) Status of the drives (7) Deactivate drive of the selected robot
(3) Status of the lamps (8) Lamp test of all robots
(4) Robot names and colors (9) Display Help screen
(5) Help screen
Fig. 48 SSB--GUI with Help screen

8.5.1 Lamp test

Press the softkey [ Lamp test ].
The signal lamps of all the cooperating robots light up briefly.
In the user interface, the correct functioning of these lamps is indicated by the corresponding
symbol. This screen remains displayed until the user interface is switched.
Fig. 49 SSB--GUI during the lamp test
A defective lamp is indicated.
Fig. 50 SSB--GUI display in the case of a defective signal lamp
8.5.2 Switching drives on/off

The drives of individual robots can be activated/deactivated using the pushbutton.
Drives ON
(1) Select a controller and press the softkey Drives on.
The drives of the robot in question are ready for operation. The signal lamp of the robot
lights up in T1 and T2 modes.
(2) Press the pushbutton.
The user interface of the currently selected controller appears.
The robot drives are now switched on and can be jogged.
Drives OFF
(1) Call the user interface by pressing the pushbutton.
(2) Select the controller in question and press the softkey Drives off.
The robot drives are switched off. The signal lamp is not lit.

8.6 Configuration of the controllers

8.6.1 KCP master
Data for the KCP master and both client controllers must be entered in the cell configuration
of the KCP master.
RT1
RT2 RT3
2 3
(1) KCP master: Name RT1 IP 192.0.10.1

(2) First client controller: Name RT2 IP 192.0.10.2
(3) Second client controller: Name RT3 IP 192.0.10.3
Fig. 51 Names and IP addresses in the VxWorks network
KCP master data entry
2
4
Fig. 52 KCP master (RT 1) cell configuration user interface
(1) Open the menu [ Setup Cell configuration ].

(2) Enter the KCP master as the clock master (softkey [ Clock Sync ]).
(3) Enter the name of the controller (robot name).
(4) Enter the IP address of the VxWorks network.
(5) Select the color for the controller by pressing the softkey [ Color ].
(6) Enter the computer name or IP address in the Windows network
(7) Select Shared KCP using the softkey [ KCP type ].
(8) Confirm the entries by pressing the [ OK ] softkey.

Data entry for the first client controller
1
3
6
4
Fig. 53 KCP master (RT 2) cell configuration user interface
(1) In the status window, select the first line of the remote controller and press the [ Modify ]
softkey.
(2) Enter the name of the controller (robot name).
(3) Enter the IP address of the VxWorks network.
(4) Select the color by means of the corresponding softkey.
(5) Enter the computer name or IP address of the Windows network.
(6) Set the option KCP Clients using the softkey Check.
The first client controller is now also registered as a client.
Data entry for the second client controller

Data entry must be carried out as for the first client controller.
Finally, the KRC master is to be shut down using the option Force cold restart.

8.6.2 First client controller

of the first client controller.
RT1
RT2 RT3
2 3

Connect the KCP to the first client controller and switch on the controller.
Data entry for the first client controller
(3)
Fig. 55 Cell configuration user interface of the first client controller (RT2)
(1) Open the menu [ Setup Cell configuration ].

(2) Data entry is carried out as described in Section 8.6.1.
(3) Select the option No KCP using the softkey [ KCP type ].
(4) Terminate the entries by pressing the softkey [ OK ].

KCP master data entry
Fig. 56 Cell configuration user interface of the first client controller (RT2)
(1) In the status window, select line 2 and press the [ Modify ] softkey.
(2) Enter valid data for the host controller.
(3) Check the box KCP Host using the softkey [ Check ].
This informs the first client controller which controller is addressed as the host.
Data entry for the second client controller

(1) Select line 3 in the status window.
(2) Enter valid data for the second client controller.
Finally, the client controller is to be shut down using the option Force cold restart.

8.6.3 Second client controller

of the second client controller.
RT1
RT2 RT3
2 3

Connect the KCP to the second client controller.
Data entry
Data entry is carried out as described in Section 8.6.3.
Finally, the client controller is to be shut down using the option Force cold restart.

8.6.4 CR cabling and final SSB test

(1) Shut down all controllers using the option Force cold restart.
(2) Disconnect KCP.
(3) Carry out the CR cabling and connect the shared pendant to the host controller.
(4) Switch all controllers on.
(5) Press the pushbutton to switch to the SSB--GUI.
Fig. 58 SSB--GUI
(6) Check that the colored marking for each controller matches the color that was set during
cell configuration.
(7) Press the softkey Lamp test.
Do the signal lamps of all the cooperating robots light up briefly?
Is the lamp display in the SSB--GUI correct?
Fig. 59 Lamp test

(8) Activate all the drives in sequence by pressing the softkey Drives on.
Fig. 60 Drive activated
(9) Close the SSB--GUI by pressing the pushbutton on the shared pendant.
(10) Jog the enabled robot RT1.
(11) Press SYM + Window selection key on the shared pendant to toggle to the user inter-
face for controller RT2 or controller RT3.
(12) Jog this robot, too.
(13) On completion of this system test, all robot controllers are ready for operation in Auto-
matic mode.
No signal lamp is lit in Automatic mode. A defective signal lamp does not result in a program
stop or deactivation of the drives in AUT mode. All safety--related signals are routed via
the Safety Selection Board, however, and stop operation in the event of a fault.

8.7 Decoupling a controller

If a controller is to be decoupled from the cooperating robot group, its status as host or client
controller must be taken into consideration.
8.7.1 Client controller

In the following example, client controller RT2 is decoupled.
Host Client Client
RT1 RT2 RT3
Fig. 61 Decoupling a client controller
Cancel running programs on all controllers and select the cold restart option for each control-
ler. To do this, it is necessary to be logged on to each controller at Expert level.
8.7.1.1 Carry out cell configuration

(1) Toggle to the user interface of controller RT2 by pressing SYM + Window selection
key.
(2) In the cell configuration menu, change the KCP type from No KCP to KCP.
A message window appears with the information that these changes will not take effect
until after a cold restart.
(4) Toggle to the user interface of controller RT1.
(5) Delete the client status entry for RT2 in the cell configuration menu.
8.7.1.2 Carry out cold restart
(1) On controller RT2, the option Force cold restart must be set.
(2) Switch off all controllers and open control cabinets for visual inspection.
All LEDs in the control cabinet must be out, otherwise switching the system back
on could result in extensive material damage!
The change has now been accepted by all controllers.

8.7.1.3 Change the cabling
Under no circumstances may any cabling be disconnected during operation, as ex-

tensive material damage may otherwise result!
(1) Remove the cables leading to control cabinet RT2.

(2) Plug in the CR connecting cable as illustrated in the diagram.
RT1 RT3
CR--OUT CR--OUT
CR--IN CR--IN
3
1
2
Fig. 62 CR cabling after decoupling a client controller
8.7.1.4 Lamp and motion test

The SSB--GUI must be displayed as illustrated when the two controllers are switched on.
Fig. 63 SSB--GUI
Carry out a lamp and motion test.

8.7.2 Host controller

In the following example, host controller RT1 is decoupled.
Host Client Client
RT1 RT2 RT3
Fig. 64 Decoupling a host controller
On all controllers, deselect any programs that are running.
8.7.2.1 Carry out cell configuration

(1) Toggle to the user interface of controller RT1 by pressing SYM + Window selection
key.
(2) In the cell configuration menu, change the KCP type from Shared KCP to KCP.
A message window appears with the information that these changes will not take effect
until after a cold restart.
(5) Change the KCP type from No KCP to Shared KCP and delete the host status entry
for RT1.
(7) Change the host status entry from RT1 to RT2 in the cell configuration menu.
8.7.2.2 Carry out cold restart
(1) On controllers RT1 and RT2, the option Force cold restart must be set.

8.7.2.3 Change the cabling
Under no circumstances may any cabling be disconnected during operation, as ex-

tensive material damage may otherwise result!
(1) Remove the cables leading to control cabinet RT1.

(2) Plug in the CR connecting cable as illustrated in the diagram.
RT2 RT3
CR--OUT CR--OUT
CR--IN CR--IN
3
1 2
Fig. 65 CR cabling after decoupling a host controller
8.7.2.4 Lamp and motion test

The SSB--GUI must be displayed as illustrated when the two controllers are switched on.
Fig. 66 SSB--GUI
Carry out a lamp and motion test.

8.8 Coupling a controller

If a controller is to be coupled in the cooperating robot group, its status as host or client con-
troller need not be taken into consideration.
Only controllers with SSB can be coupled! The option Force cold restart must be set on all
controllers before they are switched off.
In the following example, client controller RT2 is coupled.
Host Client
RT1 RT3
RT2
Fig. 67 Coupling a client controller
8.8.1 Install the software

A standard KCP must be connected to controller RT2 and the KUKA.CR Motion Coopera-
tion technology package must be installed.
8.8.2 Carry out cell configuration

Carry out the configuration as described in Section 8.6.1 or 8.6.2, according to whether the
controller is a host controller or a client controller.
8.8.3 Carry out cold restart

(1) On controller RT2, the option Force cold restart must be set.

8.8.4 Remove standard KCP

Once the controller has been switched off and the LEDs have gone out, remove the KCP.
Under no circumstances may the KCP be removed later, as this may result in con-
siderable material damage!
8.8.5 Carry out cabling

The cabling of three cooperating robot controllers can be taken as an example here.
8.8.6 Carry out cold restart
(1) Set the option Force cold restart on all controllers.

All LEDs must be out, otherwise switching the system back on could result in exten-
sive material damage!
8.8.7 Test
Once all the controllers have been switched on, the SSB--GUI must display a complete pic-
ture of all the controllers.
Fig. 68 SSB--GUI

9 Program Cooperation
9 Program Cooperation
The Program Cooperation module consists of the function blocks:
G Cell Map (cell configuration)
Cell Map is used to register/unregister, configure and manage all cooperating control-
lers.
Information about cell configuration can be found in Section 8.3.
G Program synchronization (PROGSYNC)

Synchronizes programs of different controllers.
G Shared workspaces (Workspace Sharing)
Management of shared workspaces (creation, enabling, disabling and monitoring).
G Program control (Remote Command)
Used to control programs of the robots involved.
The user interface menus have been expanded to include the following components:
Monitor Setup Commands
I/O Measure Last command

Rob. Position Master Motion
Variable UnMaster Motion parameters
Diagnosis Software Update Logic
Windows Service Analog output
1 Cell configuration Robot Data Comment
Hardware Info Inst. addit. software 6 Program Cooperation
2 CellMap Simulation 4 Workspace
3 Workspace 5 Cell configuration
1. Display current state of the cell configuration.

2 Assign controller actions.
3 Display current state of the workspaces.
4. Configure workspaces.
5. Configure network connections.
6 Set program commands (PROGSYNC, REMOTE START, etc.).

9.1 Program synchronization

Irrespective of what motions they have been executing before, program synchronization
forces a simultaneous motion start for all involved robots at synchronization point tx. The con-
trollers then resume execution of their programs.
The example in Fig. 69 illustrates two synchronization points t1 and t2 created using the
PROGSYNC command:
t R1 R2 t
3
t2 1 3 2 3 1
LIN
3 4
LIN 3 2
3 CIRC
CIRC
3 3
CIRC
LIN
3 PTP 3
3
PTP
PTP
t1 1 3 2 3 1
4
3
3 2
3
3
(3) Point on path
(4) Wait
Fig. 69 Program synchronization at t1 and t2

9 Program Cooperation (continued)
9.1.1 The PROGSYNC command

The PROGSYNC command makes it possible to start the CP motions of cooperating robots
simultaneously.
Open the following inline form via the menu [ Commands Program Cooperation Program
sync ]:
1 2 3 4
(1) Command name
(2) Controller box
(3) WAIT option
(4) NO WAIT option
Fig. 70 Inline form for the PROGSYNC command
G Enter the command name.

The name of the command may consist of up to 24 characters and is to be used in all
programs. No distinction is made between uppercase and lowercase letters.
Permissible characters are: a...z, A...Z, 0...9, _
G Position the focus on the controller box.
A list of the controllers involved is opened. Individual controllers can be selected by set-
ting TRUE or FALSE.
1 2
(1) Controller names corresponding to the cell configuration.

(2) Activate or deactivate synchronization for the controllers involved.
Fig. 71 Controller selection

The controllers to be synchronized are listed in the controller box. The controller names
are assigned automatically by the system and correspond to the order in the cell config-
uration. The local controller is always assigned the designation R1. The first remote
controller receives the designation R2, the second R3, and so on.
G Enter the option WAIT / NO WAIT for the local controller.
9.1.1.1 WAIT option

The WAIT option causes the robot to wait, on reaching the PROGSYNC command, until all
robots have reached this program command.
The advance run of the program interpreter is stopped.
Once this moment has been reached, program synchronization is deemed to have been
achieved. All program interpreters resume their processing as before.
9.1.1.2 NO WAIT option

The NO WAIT option causes the robot not to wait, on reaching the PROGSYNC command,
but merely to communicate its arrival to the other robots. The robot continues its path motion
without interruption.
The advance run of the program interpreter is not stopped.

9.2 Shared workspaces
See also the documentation [KUKA Workspace Sharing] and [Program Cooperation
Package].
9.2.1 Functional principle

Monitored shared workspaces reduce the risk of a collision. The workspaces are defined and
then managed by one of the robots in the group.
Fig. 72 Shared workspace

Fig. 73 illustrates a shared workspace in which collisions would normally be inevitable. Such
collisions can be prevented by means of appropriate access commands.
R1 R2
R1
Fig. 73 Uncontrolled use of a shared workspace
The access commands for a shared workspace are:
G ENTERSPACE (enter)
Permits the robot that is approaching the workspace most quickly to enter it. Slower
robots are stopped.
G EXITSPACE (exit)
Orders the robot that is in the workspace to leave it and enables the workspace. The
next robot in a defined sequence is granted permission to enter.
Fig. 74 illustrates the behavior once the access commands have been set:
R1, as the faster robot, enters the shared workspace first, executes its curved path and en-
ables the workspace again on leaving it.
R2 is stopped before it reaches point P1 on the path (see stop mark) and cannot resume its
motion until R1 has enabled the workspace.

ENTERSPACE
R1 P0
P0
P1 R2
P1
STOP
P2
P2
P3
EXITSPACE P3
P4 P4
Fig. 74 Controlled use of a shared workspace
While waiting, logic, calculation and I/O functions can be carried out.

9.2.2 Setting up and configuring workspaces

A maximum of 32 workspaces are possible. The workspaces can be assigned to different
controllers (see example in Fig. 75). Each controller manages the enabling and disabling of
its workspace during program execution.
R1 R2 R3
1 2 3 4 5
Fig. 75 Assignment of workspaces 1 -- 5
Only a controller that has been registered in the cell configuration can be used to manage
a workspace.
The workspaces must be entered in the same way in all the robot controllers involved.
(1) Select the user group Expert and open the menu [ Setup Workspace ].
(2) Use the status key [ WS # ] to select the workspace and then press the softkey [ WS
OK ].
(3) Enter the name of the workspace and the program--specific access sequence. If the
workspace is to be managed by the current local controller enter Local KRC. Other-
wise, select Remote KRC and specify the name of this controller.
Fig. 76 Configuring workspaces

(4) Save the entries.

9.2.3 Displaying the status of a workspace

(1) Open the menu [ Monitor Workspace ] and select the desired workspace by means
of the status key [ WS # ].
The window Workspace State appears and displays the status of the robots.
3 4 5 ? 6
(1) Display for the local controller

(2) Display for the remote controllers
(3) Robot located in the workspace
(4) Robot waiting for workspace to be enabled
(5) Deadlock of the workspace
(6) Unknown status; possible connection problems
Fig. 77 Status of a workspace
Depending on the user group, the following softkeys are available:
Softkey Function
Enter* Enter the workspace
Debug On* Activate automatic deadlock check
Debug Off* Deactivate automatic deadlock check
Find Trigger deadlock check
Force* Cancel disabling of workspace
Close Close window
*Only user group Expert
Table 2 Available softkeys

9.2.4 Restoring the status of a workspace

The status of the workspaces is not normally restored following a cold restart. If the local con-
troller is to be restored, the variable $WORKSPACERESTOREACTIVE must be set to TRUE.
The restore function is normally carried out automatically by means of a file. If this is not pos-
sible, the controller determines the status by means of communication with the other control-
lers. Finally, a corresponding query appears in the message window. The following softkeys
are available:
Softkey Function
Accepts the current controller settings without further query. The
No
status is not restored.
Repeat Repeats the interrogation of the controllers.
Yes Opens the window [ Monitor ] [ Workspace ] for the status of the
workspaces.
Local control* Assigns the selected workspace to the local controller
(Enterspace).
Accept* Accepts the setting as displayed.
Close Closes the window.
* Only available for the assigned workspaces of the local controller.
Table 3 Available softkeys
The workspaces assigned to the local controller must be confirmed on it (Accept or Local
control). Workspaces that are not confirmed remain disabled.

9.2.5 Setting the commands ENTERSPACE and EXITSPACE

The commands ENTERSPACE/EXITSPACE only function if all workspaces have been con-
figured on the cooperating controllers!
9.2.5.1 ENTERSPACE
This command permits the robot that is approaching the workspace most quickly to enter it.
Slower robots are stopped.
The ENTERSPACE command must always be set before the workspace is entered.
(1) Select the program and open the following inline form via the menu [ Commands Pro-
gram Cooperation Enter Workspace ]:
2
1
(1) Workspace
(2) Approximate positioning function
(2) Before selecting the workspace, enter the sequence in which the robot may enter the
workspace.
If, for example, a program requires two workspaces, the workspace with the lower se-
quence number (e.g. 2) must be selected first. Only then may the next workspace (e.g.
5) be requested.
Observation of this basic rule prevents deadlocks from occurring during subsequent
program execution.
(3) Select the workspace.
(4) Decide whether the point entered previously is to be approximated.
This function is only executed if the workspace is already occupied, forcing the robot
to wait.
9.2.5.2 EXITSPACE
EXITSPACE orders the robot to leave the workspace and at the same time enables the work-
space.
(1) Select the program and open the following inline form via the menu [ Commands Pro-
gram Cooperation Exit Workspace ]:
2
1
(1) Workspace
(2) Enabling of all workspaces
(2) Select, for example, Workspace 1, thus enabling it.

Selecting Release All enables all previously used workspaces. This option is suitable
for initialization at the start of the program.

9.2.6 Entry of actions running in parallel

Logic, calculation, and I/O actions may be carried out in parallel with motion and in parallel
with waiting for workspaces.
In the following example a green lamp is switched on when the robot stops at P1, irrespective
of the command ENTERSPACE. If the red lamp is switched on, this indicates that the robot
has entered the workspace; the lamp is not switched on until the robot passes point P3 on
the path.
LIN P1 Cont
P0
$Out[Green] = TRUE
LIN P2 Cont
P1
P2 ENTERSPACE Workspace 1 Cont
;Stop if not available
P3 LIN P3 Cont
$Out[Red] = TRUE
P4
LIN P4
Fig. 78 Switching action following entry into the workspace
9.2.7 Simulating workspaces

If a program requires entry to a workspace for test purposes, this can be set up while the
program is running.
(1) Set test mode T1 or T2.
(2) Open the menu [ Monitor Workspace ].
(3) Select the command ENTERSPACE.
Entry to the workspace is denied, as it is currently being used in another program.
(4) Press the [ Start + ] key and hold it down.
(5) Press the softkey [ Simulate ].
The program is resumed and entry of the robot into the previously disabled workspace
can be simulated.

9.3 Program control (Remote Command)

Similar to a PLC, the function module Remote Command offers the possibility of external
program control. The commands REMOTE_READ, REMOTE_START and
REMOTE_WAIT can be used to control programs of cooperating robots.
9.3.1 RemoteRead()
RemoteRead allows the variable values of cooperating controllers to be polled. The function
gives the same results as the variable display function on the remote controller. The return
value takes the form of a string variable.
Declaration:
CHAR[256] RemoteRead(CHAR IP_ADDR[15], CHAR VARIABLE[128], INT ERROR)
RemoteRead(): Variable value of the remote controller as a string variable.

IP_ADDR[ ]: IP address of the controller being called (e.g. 192.0.10.2).
VARIABLE[ ]: The variable whose value is being polled.
ERROR: Return value about the success of the polling.
0: Polling successful.
>0: An error with the corresponding KRL message number
occurred (e.g. 2047: Object not available).
--1: No return value was sent within the timeout time.
KRL command line:

RemoteRead(IP_ADDR, VARIABLE, ERROR)
Limitations:
G RemoteRead cannot be used for the local controller.
G RemoteRead is only possible for controllers that are entered in the $COOP_KRC list.
Example
DEF MAIN( )
DECL CHAR strVar[128]
DECL INT Err
DECL FRAME remToolData
DECL FRAME copyIndex
Err=0
strVar[]=RemoteRead(192.0.10.2,ToolData[1],Err)
IF (Err>0) THEN
ErrMsg(Read tool data)
ELSE
IF StrToFrame(strVar[], remToolData) THEN
TOOL_DATA[copyIndex]=remToolData

ELSE
ErrMsg(Conversion not possible)
ENDIF
ENDIF
9.3.2 REMOTE START

Within the cooperating robot group, programs of other controllers can be used. They are
accessed using the program commands REMOTE START and REMOTE WAIT.
The REMOTE START command is communicated to a selected controller by means of a
variable and causes a specific program to be executed by this controller.
(1) Check whether Coop If or Coop Wait template has been selected and configured on
the selected controller.
(2) Open the following inline form via the menu [ Commands Program Cooperation
Remote Start ]:
1 2
(1) Controller selection
(2) Name of the program to be called
(3) Select the controller to be used for program execution. The controller names corre-
spond to the entries in the cell configuration.
(4) Enter the name of the program.
(5) Complete the entry by pressing the softkey [ Cmd Ok ].
9.3.3 REMOTE WAIT

Within the cooperating robot group, programs of other controllers can be used. They are
accessed using the program commands REMOTE START and REMOTE WAIT.
The REMOTE WAIT command is set on the calling controller immediately after REMOTE
START. Program execution cannot be resumed until the program execution on the called
controller has been completed.
(1) Open the following inline form via the menu [ Commands Program Cooperation
Remote Wait ]:
1
(1) Controller selection
(2) Select the controller to be used for program execution. The controller names corre-
spond to the entries in the cell configuration.
(3) Complete the entry by pressing the softkey [ Cmd Ok ].

9.3.4 Templates for polling REMOTE commands

The REMOTE commands addressed to a master controller by another controller can be
polled by means of templates.
These templates are implemented by a KRL program template and have neither inline forms
nor any other program commands.
(1) Select the file list box and then press the softkey [ New ].
(2) Select the template, give it a name and call it.
Coop If
This template checks, at regular intervals, whether there is a REMOTE command present
from another controller.
LOOP
;FOLD IF COOP_TASK[]<>#IDLE ;%{PE}
IF (StrComp(COOP_TASK[],#BLOCKED,#NOT_CASE_SENS)) THEN
getTask()
IF (StrComp(MyToDo[],#IDLE,#NOT_CASE_SENS)) THEN
bStrFctRet=StrCopy(COOP_TASK[],#IDLE)
ELSE
bWrongTask=TRUE
;ENDFOLD
; --- Task from a remote controller ---

IF StrComp(MyToDo[],WELD,#NOT_CASE_SENS)==TRUE THEN
bWrongTask=FALSE
WELD ()
ENDIF
IF StrComp(MyToDo[],FETCH,#NOT_CASE_SENS)==TRUE THEN
bWrongTask=FALSE
FETCH ()
ENDIF
IF StrComp(MyToDo[],SERVICE,#NOT_CASE_SENS)==TRUE THEN
bWrongTask=FALSE
SERVICE ()
ENDIF
IF bWrongTask==TRUE THEN
BAS_MSG (WrongTaskValue)
ENDIF
;FOLD ELSE ;%{E}

ENDIF
ELSE
;ENDFOLD
; --- Some other tasks ---
;EXAMPLE( )
;FOLD ENDLOOP ;%{PE}

ENDIF
WAIT FOR TRUE
ENDLOOP

Coop Wait
This template waits for the corresponding REMOTE command from another controller.
LOOP
;FOLD Wait for COOP_TASK[]<>#IDLE ;%{PE}
bStrFctRet=StrCopy(COOP_TASK[],#IDLE)
WAIT FOR NOT(StrComp(COOP_TASK[],#IDLE,#NOT_CASE_SENS))
bStrFctRet=StrCopy(My_To_Do[],COOP_TASK[])
bStrFctRet=StrCopy(COOP_TASK[],#BLOCKED)
INTERRUPT ON 31
WHILE NOT StrComp(MyToDo[],#IDLE,#NOT_CASE_SENS)
bWrongTask==TRUE
;ENDFOLD
IF StrComp(MyToDo[],WELD,#NOT_CASE_SENS)==TRUE THEN
bWrongTask=FALSE
WELD ()
ENDIF
IF StrComp(MyToDo[],FETCH,#NOT_CASE_SENS)==TRUE THEN
bWrongTask=FALSE
FETCH ()
ENDIF
IF StrComp(MyToDo[],SERVICE,#NOT_CASE_SENS)==TRUE THEN
bWrongTask=FALSE
SERVICE ()
ENDIF
ENDIF

getTask()
ENDWHILE
INTERRUPT OFF 31
WAIT FOR TRUE
ENDLOOP
The program names (WELD, FETCH, SERVICE) listed here must all be declared in
the respective programs themselves or in the $Config.dat file.

9.4 Programming
9.4.1 SyncCmd()
SyncCmd enables program and motion synchronization.
Declaration:
ENUM SYNCTYPE PROGSYNC, MOTIONSYNC
EXTP SYNCCMD (SYNCTYPE SYNC_T, CHAR ID_NAME[64], INT COOP_LIST)
SYNC_T Type of synchronization:

# ProgSync = Program synchronization
# MotionSync = Motion synchronization
ID_NAME Character string to assign the synchronization point to a program.
COOP_LIST Describes all the controllers involved in the synchronization.
COOP_LIST is present as a bit array that refers to $COOP_KRC. The
bit with the lowest value is always index one of $COOP_KRC.
Example:
COOP_LIST=3 => #B0011. Controllers $COOP_KRC[1] and
$COOP_KRC[2] are synchronized.
9.4.2 RemoteCmd()
RemoteCmd makes it possible to send commands to other controllers. Command execution
on the local controller is interrupted for the duration of execution on the remote controller.
The following commands are permissible:
G Cancel
G Reset
G Stop
G Run
G Assignment of global variables
G Wait for
Declaration:
EXTFCT BOOL RemoteCmd (CHAR IP_ADDR[15], CHAR CMD[128])

RemoteCmd(): Executes a command on a remote controller. Sends a return value about

the success:
TRUE: Command successfully executed.
FALSE: Command not successfully executed.
IP_ADDR[ ] IP address of the remote controller (e.g. 192.0.10.2).
CMD Description of the command to be executed, e.g.:
RUN/R1/Cell ( )
$Flag[44]=TRUE
Wait for $ON_PATH
9.4.3 StrTo...()
Conversion of a string variable to a different data type. A number of different conversion
options are available.
Declaration:
BOOL StrToAxis(CHAR strValue[256], AXIS VALUE)
BOOL StrToBool(CHAR strValue[256], BOOL VALUE)
BOOL StrToE3Axis(CHAR strValue[256], E3AXIS VALUE)
BOOL StrToE6Axis(CHAR strValue[256], E6AXIS VALUE)
BOOL StrToE3Pos(CHAR strValue[256], E3POS VALUE)
BOOL StrToE6Pos(CHAR strValue[256], E6POS VALUE)
BOOL StrToFrame(CHAR strValue[256], FRAME VALUE)
BOOL StrToINT(CHAR strValue[256], INT VALUE)
BOOL StrToPos(CHAR strValue[256], POS VALUE)
BOOL StrToReal(CHAR strValue[256], REAL VALUE)
BOOL StrToString(CHAR strValue[256], STRING VALUE)
StrTo...(): Type of conversion. Sends a return value about the success of the con-
version:
TRUE: Conversion successful.
FALSE: Conversion not successful (e.g. wrong data type).
strValue[ ]: String variable to be converted to a different data type.
VALUE: Converted string variable.
KRL command line:

StrTo...(strValue[256],VALUE)

The following must be taken into consideration for the conversion of the data type:
G Conversion is only possible with compatible data types. Otherwise, the return value is
FALSE.
Example: DECL BOOL B1
StrToBool(TRUE,B1) => B1=TRUE
StrToBool(1,B1) => Error
G If components are missing in structures, their initialization is deleted.
Example: FRAME f = {X 0, Y 0, Z 0, A 0, B 0, C 0}
StrToFrame({X 0,Z 0,A 0,C 0},f) => f={X 0, Z 0, A 0, C 0}
The initialization of the components Y and B is deleted.
G At least one component in an aggregate must be initialized.
Example: StrToAxis(A1 10.0,MyAx) => myAx={A1 10.0}
StrToAxis(E1 0.0,MyAx) => Error, as E1 is not a component
of Axis.
StrToAxis(A1 1, E1 7,MyAx) => myAx={A1 1}
9.4.4 CancelProgSync()
Cancels active ProgSync commands using the option No Wait. The command is only valid
for the current controller. It can be used to cancel the current program execution and move
the robot to the home position, for example.
CancelProgSync() normally triggers an advance run stop. When the main run pointer
reaches this position, the advance run buffer is empty and the command is executed.
No advance run stop is triggered by calling an interrupt or the Submit interpreter. In these
cases, the CancelProgSync() command is executed when it is reached by the advance run
pointer. To prevent this, place a command with advance run stop before it (e.g. Wait For).
Then resume program execution by means of Resume. This ensures that the advance run
buffer is empty.
If the CancelProgSync() command is triggered by the advance run, the motion

commands in the advance run buffer are no longer executed. This can result in a
robot collision caused by subsequent motion comands.
Declaration:
EXTFCTP RET_C_PSYNC_E CancelProgSync(CANCEL_PSYNC_E CDM, CHAR ID-NAME[64])
CancelProgSync(): Cancels active ProgSync commands. Sends a return value about

the success:
CANCEL_OK: Command successfully executed.
ID_INVALID: The specified ProgSync name is invalid.
CANCEL_ERROR:ProgSync command not canceled, as errors occurred
(e.g. network problems).
NOT_NO_WAIT: The name does not belong to a ProgSync command with the
NO WAIT option.

NO_SYNCS: With CDM option CANCEL_ALL.

UNKNOWN: Cancellation in progress.
RET_C_PSYNC_E: Enum variable with the permissible return values. Used for polling.
CMD: Type of cancellation:
#CANCEL_ID: Cancels the ProgSync command with the name specified.
#CANCEL_ALL: Cancels all ProgSync commands.
ID_NAME[ ]: Name of the ProgSync command in question.
KRL command line:

CancelProgSync(CDM, ID-NAME)
Example
DEF MAIN( )
DECL RET_C_PSYNC_E retVal
...
;Only cancel specified ProgSync command
retVal=CancelProgSync(#CANCEL_ID,Sync001)
...
;Cancel all ProgSync commands
retVal=CancelProgSync(#CANCEL_ALL, )
...

9.5 System variables

9.5.1 $COOP_KRC[ ]
$COOP_KRC describes all the cooperating robots in a cell.
Declaration:
STRUC COOP_KRC CHAR IP_ADDR[15], CHAR NAME[24]
IP_ADDR[ ]: IP address of VxWorks.
NAME[ ]: Symbolic controller name that is used in error messages
and wait commands.
The assignment of the values is carried out via the cell configuration and is contained in
$Custom.dat.
DECL COOP_KRC $COOP_KRC[16]
$COOP_KRC[1]={IP_ADDR[] 192.0.10.1,NAME[] RT1}
$COOP_KRC[2]={IP_ADDR[] 192.0.10.2,NAME[] RT2}
...
9.5.2 $PINGCOOPKRC
Specifies the controllers currently accessible. During program execution, status signals are
received from the participating controllers via the VxWorks network at regular intervals. The
absence of a signal indicates that the controller concerned is no longer accessible in the net-
work.
Declaration:
INT $PINGCOOPKRC
If there are five cooperating robots, the variable has a value of 30. This is made up as fol-
lows:
R1 R2 R3 R4 R5 Robot
20 21 22 23 24 Binary coded
1 2 4 8 16 Decimal value
2 + 4 + 8 + 16 = 30 Variable display
Local controller R1 is not taken into consideration in the variable display.

9.5.3 $LOCAL_NETWORK_OK
Status of the local network configuration (VxWorks).
The declaration is made in $Machine.dat:
SIGNAL $LOCAL_NETWORK_OK $OUT[965]
Return value:
TRUE The local network configuration is OK. There is a connection to at least one
other controller.
FALSE The local network configuration is faulty or there is no connection to any other
controller.
The signal is deactivated (SIGNAL $LOCAL_NETWORK_OK FALSE).
9.5.4 $COMPLETE_NETWORK_OK
Status of the VxWorks network configuration. The controllers involved are stored in the sys-
tem variable $COOP_KRC[ ].
The declaration is made in $Machine.dat:
SIGNAL $COMPLETE_NETWORK_OK $OUT[966]
Return value:
TRUE The local network configuration is OK. Cooperation is possible with all control-
lers.
FALSE The local network configuration is faulty or there is not a connection to all partici-
pating controllers.
The local network card is deactivated (SIGNAL $COMPLETE_NET-
WORK_OK FALSE).
9.5.5 $WORKSPACERESTOREACTIVE
Restores the status of the workspaces on the controller in question following a cold restart.
First, the controller checks whether the file C:\ KRC\ Roboter\ Init\ WSRestore.ini exists.
This file is automatically generated when the controller is shut down (cold restart). The con-
troller uses this file to restore the status of the workspaces.
If the file WSRestore.ini does not exist, the workspaces of all participating controllers are
polled. These data can be used to reconstruct the workspaces for the current controller.
A complete reconstruction by polling the participating controllers cannot be guaranteed.

The status of each workspace must therefore be checked and, if necessary, corrected.
The declaration is made in $Custom.dat:

BOOL $WorkspaceRestoreActive=FALSE
Value of variable:
FALSE Do not restore the status of the workspaces.
TRUE Restore the status of the workspaces.

9.6 Program examples

9.6.1 Workspaces
An example program with two defined workspaces:
1 INI
2
3 PTP HOME Vel=100 % DEFAULT
4 EXITSPACE Release All
5 LIN P1 CONT Vel=2 m/s CPDAT1 Tool[1] Base [0]
6 ENTERSPACE WORKSPACE_1 CONT
8 ENTERSPACE WORKSPACE_2 CONT
10 EXITSPACE WORKSPACE_1
14 EXITSPACE WORKSPACE_2
16
Program line:
4 Enabling of all previous workspaces.
This command line should always be situated at the start of the program.
6 Entry to workspace 1.
8 Entry to workspace 2.
10 Exit from and enabling of workspace 1.
14 Exit from and enabling of workspace 2.

9.6.2 REMOTE commands

In this example, controller R1 alternately starts programs on controllers R2 and R3:
1 INI
2
4
5 REMOTE START Rob_2 Loadsharing
6 REMOTE START Rob_3 Loadsharing
7 REMOTE WAIT Rob_2
8 REMOTE WAIT Rob_3
9
10 REMOTE START Rob_2 External_axis
11 REMOTE START Rob_3 External_axis
12 REMOTE WAIT Rob_2
13 REMOTE WAIT Rob_3
19
Program line:
5 Program call of the program Loadsharing on controller R2.
The template Coop Wait installed on this controller registers the start request
and starts the program Loadsharing.
7 Controller R1 stops its program execution and waits for the called program to be
completed.
The polling routine Coop Wait:

LOOP
;FOLD Wait for COOP_TASK[]<>#IDLE ;%{PE}
IF StrComp(MyToDo[],Loadsharing,#NOT_CASE_SENS)==TRUE THEN
bWrongTask=FALSE
serviceprog ()
ENDIF
IF StrComp(MyToDo[],External_axis,#NOT_CASE_SENS)==TRUE
THEN
bWrongTask=FALSE
service2ms()
ENDIF
ENDIF
The program names (Loadsharing, External_axis) must be declared in the respec-

tive programs themselves or in the $Config.dat file.

10 Motion Cooperation
10 Motion Cooperation
The main area of application for Motion Cooperation is with technology packages such as
arc welding, spot welding, laser welding or adhesive bonding technologies. Motion Coopera-
tion offers the following extra functions:
G Work Cell Diagram (WCD)
The Work Cell Diagram function module makes it possible to create robots and tools,
etc., in a separate user interface where their assignments can be displayed graphically.
G CellMap simulation
CellMap simulation is used to simulate synchronization signals of other cooperating
controllers and synchronize controller actions.
G LK function
The LK function (Linked Kinematic) allows the geometric coupling of robots.
Motions of external robots are adapted to those of the local robot.
G MotionSync
The PROGSYNC function module is expanded to include the MotionSync function.
This makes it possible not only to synchronize the motion start, but also to process
coupled and synchronized motion blocks. For this purpose, Motion Cooperation pro-
vides the command component SYNC within LIN and CIRC motion commands.

10.1 Motion synchronization

10.1.1 Synchronization
The Motion Cooperation module enables two types of synchronization:
G Program synchronization
The PROGSYNC command (Section 9.1.1) enables the synchronization of motion starts.
G Motion synchronization
The command extension SYNC in LIN or CIRC commands enables the synchronization of
motion blocks.
The following example illustrates synchronized motion blocks of robots R1 and R2. The syn-
chronization covers synchronization periods t1 to t5.
t R1 R2 t
3
3
3 3
t5 CIRC SYNC LIN SYNC
1
3 3
t4 CIRC SYNC CIRC SYNC
1
3 3
t3 LIN SYNC CIRC SYNC
1
3 3
t2 1 LIN SYNC LIN SYNC
3 3
t1 LIN SYNC LIN SYNC
1
3 3
2
3
3
3
3
(1) Synchronization period
(2) Wait
(3) Point on path
Fig. 79 Motion synchronization over several motion blocks

10 Motion Cooperation (continued)
10.1.2 Geometric coupling
Exact geometric coupling is only possible if the following configuration work is carried out
with great care:
G Calibration of the tools
G Coordinated calibration of the robots in relation to one another
G Load specifications
Motion Cooperation enables two types of geometric coupling:
Direct geometric coupling

The slave robot follows the motions of the master robot, without executing motion blocks of
its own. This form of motion is used in load sharing.
Indirect geometric coupling

The slave robot follows the basic motions of the master robot, but also executes motion
blocks of its own. This form of motion is used in process--dependent mode.

10.2 Work Cell Diagram (WCD)

The Work Cell Diagram indicates the cooperation structure.
In the Work Cell Diagram you can create or modify the typical cooperation structure for each
controller graphically or by means of data. The assignments between the kinematic systems,
tools, base coordinate systems and position points are made in a tree structure. The corre-
sponding transformation data are displayed in the parallel window. The user can enter values
here.
Fig. 80 User interface of the Work Cell Diagram
The local robot can be simulated in order to run program sequences without robot motions
during troubleshooting.

The WCD interface is opened via the menu [ Monitor WCD Show ].
If an existing directory appears here, individual components of the directory tree can be de-
leted using the [ DEL ] key in the numeric keypad.
When the menu [ Monitor WCD ] is opened once again, the whole range of Work Cell Dia-
gram functions is available.
I/O
Rob. Position
Variable
Diagnosis
Windows
WCD Show
Cell configuration Refresh
Hardware Info Add
CellMap simulation Copy
Workspace Cut
Paste
Mirroring
Fig. 81 WCD functions
G Refresh Updates the input data.

G Add -- Mechanism: kinematic system
-- Base
-- Tool
-- Fixed Tool
G Copy Saves base coordinate systems, tools and position points to the
clipboard, from where they can be pasted back in elsewhere in
the WCD. It is possible to copy several objects, including objects
from another cooperating controller.
G Cut Saves base coordinate systems, tools or position points to the
clipboard and deletes them from their current position. They can be
reinserted elsewhere in the WCD.

G Paste Inserts copied or cut coordinate systems, tools or position points

at the current position. It is also possible to paste into the WCD
of another controller.
-- Object: Pastes the objects from the clipboard at the current
position, complete with their associated data.
-- Data: Pastes only the data of a previously copied object at
the current position.
-- Relative: The base coordinates of a position remain unchanged.
The world coordinates are adapted accordingly.
-- Absolute: The world coordinates of a position remain
unchanged. The base coordinates are adapted accordingly.
Absolute pasting is only possible within the same mechanism!
G Mirroring This function can be used if two robots are working with a
symmetrical workpiece according to the master/slave principle.
-- Axis: Mirroring on the axes of the local base coordinate system.
-- Geometric: Position points taught on the master can be adopted
directly by the slave by mirroring them in a plane of symmetry.
The points do not need to be taught separately on the slave side
of the workpiece. Loading and saving different mirror frames.
10.2.1 Graphical user interface

The user interface is subdivided into the following areas:
1
2
(1) Directory window

(2) Form window
Fig. 82 WCD user interface
G Directory window
Kinematic systems, tools, base coordinate systems and position points are displayed
in a tree structure.
G Form window

Kinematic systems, tools, base coordinate systems and position points are specified
with names and transformation data. The values can be modified directly.
The names of the WCD components should be assigned with care. Changes to these
names only apply to newly created commands.
Names in existing programs are not changed. The corresponding commands must be
called first via the softkey [ Change ] and then confirmed.
Directory window icons:
World coordinate system

The world coordinate system is the absolute reference base.
Mechanism
Mechanisms available for selection can include any kind of kine-
matic system, such as robots and external kinematic systems (turn-
table, two--axis positioner, etc.).
Tool
Tools can include grippers, adhesive nozzles, etc.
Base
A base coordinate system can be created under a mechanism or
under the world coordinate system.
Fixed tool
A fixed tool can be created either under its icon or under the base
icon.
Position point
When a program is called, all the motion blocks in the program are
represented by position points.

10.2.2 Mechanism
(1) Open the menu [ Monitor WCD Add ] and create a mechanism.
(2) Switch to the form window Mechanism using the softkey [ Parameter ].
1 2
4
3
(1) The robot, frame and tools can be addressed by this name in the inline forms and
menu entries.
(2) Robots or external kinematic systems.
(3) Transformation data of the kinematic system.
(4) Form for checking the controller name and IP address.
Fig. 83 Form window: Mechanism
(3) Assignment of name to robot, frame or tool.

(4) Selection of a robot or an external kinematic system. Selection is made using the ar-
row keys.
(5) Transformation data:
The softkeys [ To Global / to local ] can be used to switch from the world coordinate
system (WORLD) to the robot coordinate system (ROBROOT).
(6) Verification of the controller name:
This window is accessed by pressing [ Tab + ]. No changes can be made here, as
these designations are defined beforehand during cell configuration.
Simulation
(1) Position the focus on the relevant mechanism name in the directory window.
(2) Press the softkey [ Simulate ].
A note appears in the form window to the effect that this mechanism is simulated.
Simulation can be reset by pressing the softkey [ Un--simulate ].

10.2.3 Frame
(1) Open the menu [ Monitor WCD Add ] and create a base.
(2) Switch to the form window Frame using the softkey [ Parameter ].
(1) Name of the base coordinate system in the WCD.

(2) Frame with transformation data.
Fig. 84 Form window: Frame
(3) Assignment of the name for the frame.

10.2.4 Tool
(1) Open the menu [ Monitor WCD Add ] and create a tool.
(2) Switch to the form window Tool using the softkey [ Parameter ].
1
(1) Tool name.

(2) Tool with transformation data.
(3) Load data.
Fig. 85 Form window: Tool

(3) Assignment of the name for the tool.

(5) Form window for entering load data. Tool with transformation data.
Make sure the load data are entered correctly.

If the load data are known, they must be entered numerically. Estimates are permissible
for tools with low inertia and mass values (e.g. measuring tips). Where possible, the values
should be provided by the manufacturer or determined by means of load data calculation.
10.2.5 Fixed tool

(1) Position the focus on the world coordinate system icon.
(2) Open the menu [ Monitor WCD Add ] and create a fixed tool.
(3) Switch to the form window Frame using the softkey [ Parameter ].
1 2
(1) Tool name.

(2) Stationary tool.
(3) Fixed tool with transformation data.
Fig. 86 Form window: Frame
(4) Assignment of the name for the tool.

(5) In the case of a stationary tool, change of icon in the directory window.

10.2.6 Position points

(1) Call a program with corresponding motion blocks.
(2) Open the menu [ Monitor WCD Show ].
The position in which the position points are displayed in the directory window depends
on the base reference of the motion blocks.
(3) Position the focus on a positioning point.
The form window Position appears.
(4) Switch to the form window Position using the softkey [ Parameters ].
1 2
(1) Designation of the position point.

(2) Program name.
(3) Transformation data of the position point with the additional specification of Status and
Turn.
(4) Axis values of the external axes.
Fig. 87 Form window: Position
(5) The position point can only be modified by editing it in the program.
Position points can be cut and pasted under a different mechanism or a new frame.

10.2.7 Mirroring position points

Position points taught on symmetrical workpieces can be mirrored on the opposite side of
the workpiece by means of the Mirroring function. Two methods are available:
G Axis
G Geometric
When mirroring points, the following must be taken into consideration:

G Mirroring is carried out under the same base coordinate system.
G PTP motion blocks are not permissible.
G In the case of mirroring between several kinematic systems, only one shared coordi-
nate reference system may exist.
G The position of mirrored points must be checked. Inaccurate calibration (calibration of
robots relative to one another, tool calibration, etc.) may result in discrepancies.
10.2.7.1 Axis: Mirroring in the base coordinate system

Mirroring in the XZ plane of the base coordinate system used. The robots, tools and work-
pieces must be installed symmetrically. The workpiece, base and Robroot coordinate sys-
tems must be calibrated symmetrically.
1 Mirror frame (XZ plane of the base coordinate system)

P1 ... P3 Points to be mirrored
P1 ... P3 Mirrored points
Fig. 88 Mirroring of points P1 -- P3

Mirror a program as follows:

(1) Create a mirroring program and teach the points to be mirrored (e.g. P1 ... P3) on the
workpiece.
(2) Archive mirroring program and restore it on the second robot.
(3) Select the mirroring program on the second robot and call the menu item
[ Monitor WCD Mirror ] in the WCD.
(4) Select the relevant points and press the softkey [ Select ].
(5) Mirror the points by pressing the softkey [ Axis ].
10.2.7.2 Geometric: Mirroring using the 3--point method
(1) Mirror frame

(2) Auxiliary plane
(3) Mirrored and rotated auxiliary plane
(4) Workpiece 1
(5) Workpiece 2 (mirrored and rotated)
O1 ... O3 Original points on the auxiliary plane
M1 ... M3 Copied points on the mirrored auxiliary plane
P1 ... P3 Points to be mirrored
P1 ... P3 Mirrored points
Fig. 89 Mirroring of points P1 to P3 using the 3--point method
The process is broken down into the following steps:

1. Creating a mirror frame.
2. Mirroring position points.

Creating a mirror frame (3 points)

A mirror plane is to be created using the three reference points O1 to O3 and their mirrored
positions M1 to M3. This can then be used to mirror other points P1, P2, ...
Fig. 90 Created mirror plane
(1) Create a mirroring program (e.g. Plane_1).

(2) Teach reference points O1, O2 and O3 on the workpiece.
(3) On the symmetrical opposite side, teach the mirrored reference points M1, M2 and M3
(Fig. 92). Distances O1--O2 and M1--M2 must be the same, as must O1--O3 and
M1--M3.
(4) The program structure and the WCD directory window should be the same as those in
the example in Fig. 91.
2 1
1
2
(1) Reference points on the original side.

(2) Reference points on the mirrored side.
Fig. 91 Program structure and WCD directory after the auxiliary planes have been set
up

By teaching the mirrored counterparts of the three points in the plane, the program calculates
the mirror frame.
Mirroring position points

Position points taught freely in space are to be mirrored in the calculated reflection plane with-
out the need for further teaching.
Fig. 92 Points taught symmetrically on the workpiece
(1) Teach the position points P1, P2, P3 and P4 between the previously defined reference
points.
(2) Open the WCD directory window.
The program structure and the WCD directory window should be the same as those in
the example in Fig. 93.
3
1
2
3
(1) Reference points on the original side.

(2) Reference points on the mirrored side.
(3) Position points to be mirrored.
Fig. 93 Program structure and WCD directory after points P1 to P4 have been taught

(3) Select the menu [ Monitor WCD Mirror ].

(4) Select the position points P1 to P4 to be mirrored and press the softkey Select.
(5) Select the mirroring variant [ Geometric ].
(6) To create new reference data, press the softkey [ New ]. If there are already reference
data available, press the softkey [ Saved ], select the desired entry in the selection list
and proceed to step (14).
(7) If the orientation of both tools is symmetrical, select the option [ Yes ]. Otherwise, select
[ No ] and proceed to step (10).
Fig. 94 Tools with symmetrical orientation
(8) If the tool is symmetrical to the XZ plane of the flange, select [ Yes ] and proceed to
step (10). Otherwise, select [ No ].
Fig. 95 Tool with flange coordinate system and XZ plane

(9) Select the plane of symmetry of the tool (XY, XZ or YZ).
(1) Reference tool with flange coordinate system.

(2) Tool symmetrical to the XZ plane of the flange coordinate system.
(3) Tool symmetrical to the XY plane of the flange coordinate system.
(4) Tool symmetrical to the YZ plane of the flange coordinate system.
Fig. 96 Plane of symmetry of the tool
(10) Select the reference points from the original side (O1, O2 and O3) and press the softkey
[ Select ].
(11) Select the reference points from the mirrored side (M1, M2 and M3) and press the soft-
key [ Select ].

(12) Check that the original and mirrored points have been assigned correctly and make any
necessary corrections to the form entries using the selection list.
Fig. 97 WCD directory and form with positioning assignment
(13) If you wish to save the reference points to use again later, press the softkey [ Save ].
(14) Pressing the softkey [ OK ] causes the selected points to be mirrored.

10.3 Programming
10.3.1 Geometric coupling via $BASE (GEOLINK)
The GEOLINK command couples a robot (slave) with the base system of another robot
(master). When the master is jogged, the slave follows its motions.
Sequence:
G Both robots are situated in the start position from which they move together.
G The slave robot couples itself geometrically with the base system of the master.
G When the master executes its program, the slave follows its motions.
G The slave robot uncouples itself from the master. Both robots can now be moved sepa-
rately again.
Program the command with the same command name on all controllers:
(1) Open the following inline form via the menu [ Commands Program Cooperation Geo-
link ]:
2 3 4
1
(1) Master or slave robot
(2) Command name
(3) Controller box
(4) Base coordinate system
Fig. 98 Inline form for the GEOLINK command
(2) Select the robot type (master or slave)

(3) Enter the command name.
The name of the command may consist of up to 24 characters and is to be used in all
programs. No distinction is made between uppercase and lowercase letters. Permissi-
ble characters are: a...z, A...Z, 0...9, _
(4) Position the focus on the controller box.
A list of the controllers involved is opened. Individual controllers can be selected by set-
ting TRUE / FALSE.
Fig. 99 Controller selection

The local controller is always automatically indicated in the controller box as R1.
(5) Select the relevant base of the master robot. The motions of the slave robot will relate
to this coordinate system.
10.3.1.1 Functional principle in the KRL program

The geometric coupling of two robots is established by modifying the base reference of
motion blocks in the program of the slave robot.
The following example illustrates the required structure of the directory window and corre-
sponding motion blocks in the case of geometric coupling.
Directory window: Master

The entry for the tools and the base coordinate system M_BaseLoc are displayed here.
Fig. 100 Master WCD
Directory window: Slave

The master must also be entered here, including its base coordinate system S_BaseOnMas-
ter.
If a point is taught relative to this base, or if this base is selected via the menu Configure
/ Cur. tool/base, the geometric coupling is established.
Fig. 101 Slave WCD

Motion blocks: coupling / decoupling

If the geometric coupling is to be established, the following base reference must be made
in the slave program:
Fig. 102 Base reference S_BaseOnMaster
The base reference S_BaseOnMaster means that the slave is coupled to the motions of the
master.
If the geometric coupling is to be canceled, the original base reference S_BaseLoc must be
restored in a motion block of the slave.
A geometric coupling can be canceled by selecting any base reference that is not linked
to the master (e.g. NULLFRAME).
Fig. 103 Base reference S_BaseLoc
The slave executes motion blocks of its own, independently of the master.

10.3.2 Block--by--block synchronization (SYNC)

The command SYNC is used to synchronize individual motion blocks of cooperating control-
lers (MotionSync).
The motions of several robots can be synchronized so that each robot requires the same
amount of time for these motions.
The command SYNC is a supplementary component that can be called and added to a LIN
or CIRC motion block.
Calling the SYNC command:

(1) Select a motion block.
(2) Select a LIN or CIRC motion block.
(3) Press the softkey Syn/UnSyn.
The following inline form appears:

1
2 3
(1) Additional SYNC component.
(2) Synchronization name.
If this box is left blank, the point name is automatically used.
An unambiguous name ensures that only motion blocks of this name in the affected
programs are synchronized.
An error message is displayed if motion blocks of a different name are accessed.
(3) Selection of the controllers to be synchronized. R1 here always designates the first
controller.
By setting TRUE or FALSE, it is possible to activate/deactivate the synchronization
of individual controllers.

After confirmation of the entries:
The complete motion block contains information about the base reference system of the geo-
metric coupling.
The synchronization can be undone by pressing the softkey Syn/UnSyn.
The SYNC command is more important than the PROGSYNC command, which only
allows synchronization of the motion start.
10.3.3 LK function
The LK function (LK: Linked Kinematic) allows the coupling of separate kinematic systems.
The declaration is made in $Operate.src:

EXTFCT FRAME LK (FRAME ROOT, CHAR IP_ADDR[ ], FRAME OFFSET, ESYS EXKIN)
ROOT Frame between the root points of the kinematic systems.

IP_ADDR[] IP address of the kinematic system to be coupled.
OFFSET Base frame at the end of the kinematic system to be coupled.
EXKIN Type of kinematic system to be coupled
(#ROBOT, #EASYS, ..., EFSYS).

10.4 Program structures

10.4.1 Load sharing with GeoLink
1 3
(1) Master
(2) Slave
(3) Workpiece
Fig. 104 Load sharing
10.4.1.1 Solutions with GEOLINK

Def Master() Def Slave()
Init Init
PTP Home PTP Home
PTP P1 PTP P1
PTP P_Last PTP P_Last
;-- at workpiece -- ;- at workpiece..establish link --
GELOLINK MASTER Link1 -> R1_R2 GEOLINK SLAVE Link1 -> R1_R2 Base[1]
LIN P2
LIN P3
LIN P4 ;-- synchronous motion here --
LIN P5
LIN P6
LIN P7 ;-- Cancel link --
GEOLINK MASTER Link2 -> R1_R2 GEOLINK SLAVE Link2 -> R1_R2 Base[0]
PTP P1 PTP P1
PTP Home PTP Home

10.4.2 Solution with SYNCCMD(), LK() and zero block

Init Init
PTP Home PTP Home

PTP P1 PTP 1
;-- at workpiece -- ;- at workpiece..establish link --
SyncCmd(#ProgSync,AmBauteil,B0011) SyncCmd(#ProgSync,AmBauteil,B0011)
$Base=LK(Root,IP_Master,Offset,#Robot)
LIN P_Nullsatz
SyncCmd(#ProgSync,AmBauteil_1,B0011) SyncCmd(#ProgSync,AmBauteil_1,B0011)
LIN P2
LIN P3
LIN P4 ;-- synchronous motion here --
LIN P5
LIN P6
LIN P7 ;-- Cancel link --
SyncCmd(#ProgSync,AmZiel,B0011) SyncCmd(#ProgSync,AmZiel,B0011)
$Base=$Nullframe
LIN P_Nullsatz
SyncCmd(#ProgSync,AmZiel_1,B0011) SyncCmd(#ProgSync,AmZiel_1,B0011)
PTP P1 PTP P1
PTP Home PTP Home

10.4.3 Master/slave procedure
2
1
(1) Master
(2) Slave
(3) External axis (geometrically coupled with the master)
Fig. 105 Master/slave procedure

Init Init
PTP Home PTP Home

PTP P1 PTP P1
;-- at workpiece -- ;-- at workpiece .. establish link --

SyncCmd(#MotionSync,M1,#B0011) SyncCmd(#MotionSync,M1,B0011)
$Base=EK(Root,Offset,#EASYS) $Base=LK(Root,IP_Master,Offset,#EASYS)
LIN P2 LIN P2
SyncCmd(#MotionSync,M2,B0011) SyncCmd(#MotionSync,M2,B0011)
LIN P3 LIN P3
: :
: :
SyncCmd(#MotionSync,M9,B0011) SyncCmd(#MotionSync,M9,B0011)
LIN P9 LIN P9
$Base=$Nullframe $Base=$Nullframe
LIN P10 LIN P10
PTP P1 PTP P1
PTP Home PTP Home

10.4.4 Base reference of point positions in the WCD

The base reference of taught points is displayed in the WCD directory window. The position
in which a position point is displayed in the directory depends on the base under which the
point was taught.
Fig. 106 Base reference of taught points in the Work Cell Diagram

10.5 Program examples

10.5.1 Load sharing process with two robots
In the following example, load pick--up points on opposite sides of the workpiece are each
approached by a single gripper. Setting several PROGSYNC commands with corresponding
base references results in cooperation between the master and slave robot in the form of
both synchronization and geometric coupling. The slave follows the motions of the master
without a motion block of its own.
10.5.1.1 Master program
1 INI
2
4 PTP P1 Vel=100 % PDAT1 Tool[1]:Gripper Base[2]:WorldCS
5
6 PROGSYNC Start 1 --> R1_R2 WAIT
7 PROGSYNC Start 2 --> R1_R2 WAIT
8
9 LIN P2 Vel=2 m/s CPDAT1 Tool[2]:Gripper with parl Base[2]:WorldCS
12
13 PROGSYNC End 1 --> R1_R2 WAIT
14 PROGSYNC End 2 --> R1_R2 WAIT
15
Fig. 107 Master program
Program line:
4 The position of the gripper is described in the world coordinate system (WorldCS).
6 Wait until each gripper has reached its pick--up position.
7 Wait until the geometric coupling of the slave has been accomplished.
9--11 The master executes the motion commands. The slave follows the motions of the
master synchronously.
13 Signal to the slave that the motions have been completed.
14 Wait until the geometric coupling of the master and slave has been canceled. The
slave can now execute an independent program again.

10.5.1.2 Slave program
1 INI
2
4 PTP P1 Vel=100 % PDAT1 Tool[1]:Gripper Base[2]:WorldCS
5
6 PROGSYNC Start 1 - > R1_R2 WAIT
7 LIN P2 Vel=2 m/s CPDAT1 Tool[2]:Gripper with part
Base[1]:Master flange
9
10 ;Slave follows master
11
12 PROGSYNC End 1 - > R1_R2 WAIT
13 LIN P3 Vel=2 m/s CPDAT2 Tool[2]:Gripper with part Base[2]:WorldCS
14 PROGSYNC End 2 - > R1_R2 WAIT
15
Fig. 108 Slave program
Program line:
4 The position of the gripper is described in the world coordinate system.
6 Wait until each gripper has reached its pick--up position.
7 Teaching of the coupling. The base coordinate system WorldCS of the slave is
switched to Master flange. The slave is thus geometrically coupled to the master.
8 Signal to the master that the coupling has been implemented.
Motion blocks do not have to be entered.
10 The slave follows the motions of the master without a motion block (zero block) of
its own.
12 The slave is waiting for the signal to cancel the coupling. As long as this signal has
not been received, the last motion block (7) is continued and the coupling is
maintained.
13 Teaching of the decoupling. The coupling is canceled by a zero block referring to the
world coordinate system.
14 Signal to the master that the decoupling is being implemented. The slave can now
execute an independent program again.

10.5.2 Load sharing process with two robots and an external axis
10.5.2.1 Master/slave procedure

In the following example, robots R3 and R2 are synchronized and geometrically coupled on
an external axis connected to R3. The two robots are made to cooperate by setting the SYNC
command and the corresponding base reference.
Master robot R3
1 INI
2
3 PTP HOME_NEW_1 Vel=100 % PDAT2 Tool[1]:Torch22_R3 Base[0]
4
5 PTP P1 CONT Vel=100 % PDAT1 Tool[1]:Torch22_R3 Base[0]
7 ;Start position
8
10 LIN P3 Vel=2 m/s CPDAT1 Sync= ms1 - > R1 Tool[1]:Torch22_R3
Base[2]:B ExAx Rob 3
11 LIN P4 CONT Vel=2 m/s CPDAT2 Sync= ms2 - > R1 Tool[1]:Torch22_R3
15 CIRC P8 CONT Vel=2 m/s CPDAT6 Sync= ms6 - > R1 Tool[1]:
Torch22_R3 Base[2]:B ExAx Rob 3
16 LIN P10 CONT Vel=2 m/s CPDAT7 Sync= ms7 - > R1 Tool[1]:
18 LIN P12 Vel=2 m/s CPDAT8 Sync= ms9 - > R1 Tool[1]:
19
20 PTP HOME_NEW_1 Vel=100 % DEFAULT Tool[1]:Torch22_R3 Base[0]
Fig. 109 Master program R3

Program line:
9 Setting of the PROGSYNC command for synchronization.
10 Start of the geometric coupling of the master by means of an EK statement, in which
the external axis logically connected to the master is selected as the base
(B_ExAx_Rob3). The block--by--block synchronization of the master and its external
axis is carried out by means of the additional SYNC command integrated into the LIN
block.
18 Last coupled motion block.
20 Coupling is canceled by the base reference $Base[0].

Slave robot R2
1 INI
2
3 PTP HOME_NEW_1 Vel=100% DEFAULT
4
7 ;Start position
8
10 LIN P3 Vel=2 m/s CPDAT1 Sync= ms1 - > R1 Tool[1]:Torch22_R2
15 CIRC P8 CONT Vel=2 m/s CPDAT6 Sync= ms6 - > R1 Tool[1]:
18 LIN P12 Vel=2 m/s CPDAT8 Sync= ms9 - > R1 Tool[1]:
19
20 PTP HOME_NEW_1 Vel=100 % DEFAULT Tool[1]:Torch22_R2 Base[0]
Fig. 110 Slave program R2
Program line:
9 Setting of the PROGSYNC command for synchronization.
10 Start of the geometric coupling of the slave by means of an LK statement, in which
the external axis logically connected to the master is selected as the base
(B_ExAx_Rob3). The block--by--block synchronization with the master is carried out
by means of the additional SYNC command integrated into the LIN block.
18 Last coupled motion block.
20 Coupling is canceled by the base reference $Base[0].

10.5.3 Process--dependent procedure

In the following example, two slaves are cooperating with a master that is holding a workpiece
to be machined. The motions of the tools of both slaves are coordinated with the motions of
the master workpiece. The two robots are made to cooperate by setting the PROGSYNC
and SYNC commands and the corresponding base reference.
There is no geometric coupling between the slaves!
Master
1 INI
2 Start ROB_2
3 Start ROB_3
4
5 PTP HOME Vel=100% DEFAULT
6
7 PTP P1 CONT Vel=100 % PDAT1 Tool[1]:Gripper Base[0]
8 PTP P1_1 CONT Vel=100 % PDAT5 Tool[1]:Gripper Base[0]
9 ;Start position MASTER
10
11 PTP P2 Vel=100 % PDAT2 Tool[1]:Gripper Base[0]
12 ;Wait for synchronization of R2 and R3
13 PROGSYNC A1 - > R1_R2_R3 WAIT
15 LIN P3 CONT Vel=2 m/s CPDAT1 Sync= ms1 - > R1_R2_R3 Tool[1]:
Gripper Base[0]
16 LIN P4 CONT Vel=2 m/s CPDAT2 Sync= ms2 - > R1_R2_R3 Tool[1]:
Gripper Base[0]
17 LIN P5 CONT Vel=2 m/s CPDAT3 Tool[1]:Gripper Base[0]
20
23
24 PTP HOME Vel=100% DEFAULT
Fig. 111 Master program
Program line:
14 Wait until the geometric coupling of the slaves to the master has been accomplished.
15--16 Setting of two SYNC commands. This results in block--by--block synchronization with
both slaves.
17 End of the synchronization while the geometric coupling continues.
18 End of the geometric coupling.

Slave 1
1 INI
2
3 PTP HOME_NEW Vel=100% PDAT1 Tool[1]:Torch22_R2 Base[0]
4
5 PTP STARTPOS Vel=100 % PDAT2 Tool[1]:Torch22_R2 Base[0]
7 LIN LINK1 Vel=2 m/s CPDAT1 Tool[1]:Torch22_R2 Base[1]:B_Rob 1
9 LIN LINK2 CONT P3 Vel=2 m/s CPDAT2 Sync= ms1 - > R1_R2_R3
Tool[1]:Torch22_R2 Base[1]:B_Rob 1
12 LIN LINK4 Vel=2 m/s CPDAT4 Tool[1]:Torch22_R2 Base[0]
14 PTP HOME_NEW Vel=100 % PDAT3 Tool[1]:Torch22_R2 Base[0]
Fig. 112 Program: slave 1
Slave 2
1 INI
2
3 PTP HOMEPOS Vel=100% PDAT2 Tool[1]:Torch22_R3 Base[0]
4
5 PTP STARTPOS Vel=100 % PDAT2 Tool[1]:Torch22_R3 Base[0]
6 PROGSYNC A1 --> R1_R2_R3 WAIT
7 LIN LINK1 Vel=2 m/s CPDAT1 Tool[1]:Torch22_R2 Base[1]:B_Rob 1
10 LIN LINK3 CONT P3 Vel=2 m/s CPDAT3 Sync= ms2 --> R1_R2_R3
12 LIN LINK4 Vel=2 m/s CPDAT4 Tool[1]:Torch22_R3 Base[0]
14 PTP HOMEPOS Vel=100 % PDAT3 Tool[1]:Torch22_R3 Base[0]
Fig. 113 Program: slave 2
Program line:
7 Slave 1/slave 2 is coupled with the master; the torch tools now refer to the flange
coordinate system of the master.
8 The coupling is communicated to the master.
9 Block--by--block synchronization using the SYNC command.
12 The slave cancels the coupling by means of a zero block.


11 Error treatment
11 Error treatment
11.1 Deadlock of cooperating robots
If shared workspaces are used, undesired deadlocks of cooperating robots can arise. This
can happen if:
G not all previously used workspaces have been enabled at the start of the program by
means of the EXITSPACE Release All command,
G the EXITSPACE command has been ignored,
G the access sequence of the workspaces has been defined inaccurately.
This example with robots R1 and R2 illustrates how a deadlock can arise:
R1
WS2 WS1
R2
1 Disabled workspace
Fig. 114 Deadlock
Two workspaces are reserved for robot R1 with the sequence WS1 --> WS2. The work-
spaces are reserved for R2 in the reverse sequence WS2 --> WS1.
After its stay in WS1, robot R1 cannot move to workspace WS2, as this is still occupied by
R2. The two robots are blocking one another.
Reason: No enabling command for WS1 was issued during programming of the CP motion
of robot R1! Robot R2 cannot enter WS1 and remains in WS2.
This deadlock can only be resolved by means of an operator intervention.
See also Section 9.2 of this documentation.

11.1.1 Checking for deadlocks

Program Cooperation provides a search function to check for deadlocks.
(1) Open the menu [ Monitor Workspace ] and press the softkey [ Find ].
The search for deadlocks is started.
If deadlocks are detected, the program generates a message with a reference to the over-
view window.
The search can also be automated. This form of monitoring is particularly advantageous with
large programs.
(1) Open the menu [ Monitor Workspace ] and press the softkey [ Debug On ].
The entry Deadlock sequence checking active appears in the overview window.
Test_1 RT1
Test_2 RT2
Fig. 115 Deadlock

The assignment of the softkey changes simultaneously to the switch--off function
[ Debug Off ].

11 Error treatment (continued)
11.1.2 Enabling a workspace

In order to release a deadlocked system, at least one of the robots involved must be brought
out of its waiting state.
Software enabling
Program Cooperation provides a menu function for canceling the deadlock of the robots by
enabling the workspace in question.
(1) Switch to the user group Expert and select T1/T2 mode.
(2) Open the Workspace State window and press the softkey [ Force ].
The next robot in the queue moves into the enabled workspace.
Manual enabling
Manual intervention in automatic program execution must be undertaken

with extreme care! Risk of collision!
If there is another robot in the workspace it must first be moved manually out of the work-
space.
11.2 Missing network connection

If the network connection is broken, required data can no longer be exchanged.
The status of the VxWorks and Windows networks is displayed in the cell configuration. If
a network connection is broken, all network connections and configuration settings should
be checked.
1 3
2 4
(1) VxWorks network connection active (yellow dot).

(2) VxWorks network connection broken (red dot).
(3) Windows network connection active (yellow dot).
(4) Windows network connection broken (red dot).
Fig. 116 Network status

11.3 Safety circuit (ESC) broken

G Shared pendant not connected to the first control cabinet.
See Section CR cabling.
G Shared pendant connected after system booted.
Check components for material damage and repeat installation.
G Standard KCP connected to a client controller.
Remove standard KCP.
G Control cabinets not suitable for cooperating robot operation.
Exchange cabinet.
G CR cabling carried out in wrong direction.
G CR--IN terminating resistor missing at host controller.
G CR--OUT terminating resistor missing at last client controller.
G Signal lamp defective.
Carry out a lamp test in T1/T2 mode and exchange any defective lamps.
G Standard KCP connected to KCP master.
Use shared pendant.
11.4 Robot cannot be jogged

G Network configuration incorrect.
See Section 11.2.
G Cell configuration incorrect.
See Section 8.3.
11.5 No connection established to client controllers

G Technology software on client controllers faulty or not installed.
Disconnect the CR cabling, check the individual installations using the shared
pendant and complete as necessary.
G Invalid IP addresses.
Check the IP addresses in the cell configuration.
G The controllers have not been specified as client controllers in the name list of the host
controller.
Check the name lists and selections in the cell configuration of the host control-
ler.

G The client controllers cannot detect the host controller.

No host controller has been selected in the cell configuration of the client con-
trollers.
G The wrong type of KCP has been entered for the client controllers.
Check the entry KCP type in the cell configuration of the client controllers.
11.6 Safety Selection Board (SSB)

SSB--GUI is not displayed
G No suitable KCP is connected.
Connect a shared pendant.
G Control cabinets are not fitted with Safety Selection Board.
Exchange control cabinets.
G SSB--GUI does not appear when the pushbutton is pressed.
Mode T1/T2 not selected.
SSB--GUI fault profiles
G Gray indicator bar without controller name.
Carry out cell configuration.
G No colored indicator bar.
Carry out cell configuration including color selection for the controllers.
G A lamp icon on a square, gray background is displayed following the lamp test.
Exchange signal lamp.
G Drive settings are deleted after switching back from Automatic / Automatic External
mode.
Safety switch set by the manufacturer to prevent previous operator settings
from being applied without having been checked.

11.7 Coupling does not work

G Incorrect entries in WCD
Check the definition of the mechanism type (e.g. robot instead of external kine-
matic system) and modify if necessary.
Check the entry of the calibration values and modify if necessary.
Check the base specifications (e.g. could the base name in the program differ
from that in the form) and modify if necessary.
Check the assignment, values and name of the tool and modify if necessary.
The mirroring of the position points may have been carried out in the wrong mir-
ror frame.
The coupling to the base of the master is missing in the slave directory of the
WCD or has been entered incorrectly.
G SYNC command programmed incorrectly

Check the specifications in the SYNC command (e.g. synchronization name
ambiguous, incorrect controller selected for synchronization, etc.) and modify
if necessary.
G The coupling does not function due to an incorrect PROGSYNC command.

Check the specifications in the SYNC command (e.g. use of identical wait com-
mands with different names, incomplete listing of waiting robots, robots not en-
tered in the controller list $COOP_KRC[Index], etc.) and modify if necessary.
G The coupling does not function due to incorrect entries in CellMap Simulation.
Check the entry for the relevant robot in the cell configuration and modify if nec-
essary.
G In the case of synchronized motion, the local master controller waits in vain for the mo-
tion of the slave. Instead, the slave stops or is occupied with interrupt motions.
Check the slave controller and adapt the slave programs if required. Motion ex-
ecution cannot start until all slaves have reached the block in the main run.
Start the slave program and check whether any wait messages from an inter-
rupt are present.
G Motion of the master interrupted by an interrupt in the slave program. Master waits until
the slave resumes its motion.
The master program must be adapted. If the program is correct, wait until the
slave reaches a new motion block.
G The local controller receives a start command from an external controller although no
coupling is currently active.
System error! Please contact the KUKA Roboter GmbH Service department.

G Local program execution is interrupted during the coupling because of a program stop
on an external controller.
The external controller is specified in the message text. Check the program of
the external controller.
G Local program execution is interrupted during the coupling because of a path--maintain-

ing E--STOP on an external controller.
The external controller is specified in the message text. Check the program of
the external controller.
G No geometric coupling takes place.

It is possible that not all the cooperating controllers are running the same ver-
sion of the communications protocols. Check the protocols that have been set
and carry out an update on all cooperating controllers if required.
G Synchronization is lost during program execution. Program execution is ultimately

canceled.
There are communications problems between the controllers. These could be
caused by the hardware or program--related. Reset the program or carry out
block selection to the synchronized block on all affected controllers.
Please contact the KUKA Roboter GmbH Service department if the error re-
curs.
G In the case of synchronized motion, the local slave controller waits in vain for the motion
of the master. Instead, the master stops or is occupied with interrupt motions.
At least two controllers have been switched to different program run modes. Set
the same program run mode on all controllers.
G Problems jogging the master.

Jog and enabling keys released in the wrong order. The jog key must always
be released first!
G Robot cannot be jogged in T1/T2 mode when geometrically coupled.

Signal lamp defective or power supply to signal lamp interrupted.


12 Abbreviations / technical terms
12 Abbreviations / technical terms

12.1 Abbreviations
G CR Cooperating Robots
G CR group Coupling of several cooperating robots to form a group
G CR cabling Connecting cables for the control cabinets of cooperating robots
G CM Cell Map ----> Cell configuration
G CMS Cell Map Simulation ----> Cell simulation
G I/O Input/Output
G EK External Kinematic
G ESC Electronic Safety Circuit
G EMT Electronic Measuring Tool
G GUI Graphical User Interface
G KCP KUKA Control Panel ----> KUKA teach pendant
G KCP2--SP Teach pendant for cooperating robots (shared pendant)
G KIR German abbreviation for Cooperating Industrial Robots (see CR)
G KR C KUKA Robot Controller
G KRL KUKA Robot Language
G KSS KUKA System Software ----> KUKA controller software
G KST KUKA System Technology
G LAN Local Area Network
G LK Linked Kinematic
G MC Motion Cooperation
G MS Motion Sync ----> Motion synchronization
G PC Program Cooperation ----> Program synchronization
G PS PROGSYNC command
G RC Remote Command
G SP Shared Pendant ----> Shared pendant technology software
G PLC Programmable Logic Controller
G SSB Safety Selection Board ----> Module in the CR control cabinet
G SSB--GUI Safety Selection Board Graphical User Interface
G WINS Windows Internet Name Server ----> Server for processing
name registrations
G WS Workspace Sharing

12.2 Technical terms

G Administrator
Person who manages a robot system and configures it for specific tasks.
G Client controller
A controller connected indirectly to the shared pendant is called a client control-
ler. It is only connected to the shared pendant of the host controller via the CR
cabling.
G Connection type
Designation of the connection between the controller and the KCP in the Cell
Map menu.
Shared KCP
The controller is a host controller and is connected directly to the KCP.
KCP
The controller is not a cooperating robot controller and is connected to a stan-
dard KCP.
No KCP
The controller is a client controller and is thus only indirectly connected to a KCP
via the CR cabling.
G Crossed cable
Local network connection cable with the data wires interchanged at the ends
of the cable.
G ESC
A microcontroller--based safety bus in the KR C2 that ensures constant moni-
toring of all safety--related signals and devices (operating mode, enabling
switches, etc.).
G Expert
Robot system operator and programmer with the skills and experience (basic
and advanced programming courses) to carry out modifications to the program
code.
G External axis
External axes include, for example, turntables, two--axis positioners, linear
units, etc.
G Fixed tool
e.g. a stationary adhesive bonding unit or welding torch. It receives its own icon
in the WCD.
G Fully configurable switch
This is interposed in the VxWorks network, in the case of more than two cooper-
ating robot controllers, to establish full duplex mode between the MFC network
cards.
G Function block
Program that carries out special tasks within the software of a technology pack-
age (e.g. in the case of Motion Cooperation: WCD, LK function, etc.).
G KCP Master
A controller connected directly to the shared pendant is called a KCP master
(host controller).

12 Abbreviations / technical terms (continued)
G Kinematic systems
Robots, external axes, e.g. turntables, two--axis positioners, linear units, etc.
G LK offset
Offset value of the workpiece base of a cooperating robot. Corresponds to the
EK offset in the case of an external kinematic system (turntable).
G Load data
Information about the mass, location of the center of gravity and moment of in-
ertia of a payload (gripper, weld gun, workpiece, etc.).
G Local robot
Robot that is currently being operated using the shared pendant. It is indicated
in line 1 of the Cell Map user interface as Local KRC name.
G Payload
Information about the mass of the tool, workpiece and energy supply system
components (hoses, etc.).
G Positionally accurate robot
Robot calibrated directly at KUKA with defined positioning accuracy.
G Positioning robot
Robot whose sole function is to move workpieces to their machining positions
at the process robot.
G Process robot
Robot whose sole function is to carry out machining processes on workpieces.
G Program run mode
A KRL program can be executed continuously from start to finish (Go) or step--
by--step (Single Step / Incremental Step). It is also possible to run the program
backwards.
G Program synchronization
Simultaneous execution of a program step in several programs by setting the
program command PROGSYNC.
G Remote controller
Controller that is not operated locally using the shared pendant. It is indicated
in the user interface of the cell configuration as External Participant.
G Safety data
Safety signals routed via the ESC safety circuit (E--STOP, enabling switches,
etc.) and additionally, in the case of cooperating robots, via the SSB.
G Standard switch
This is interposed in the Windows network, in the case of more than two cooper-
ating robot controllers, to establish data exchange between the network cards.
G Supplementary load
Information about the additional mass mounted on the robot arm, link arm or
rotating column.
G Technology package
Technology--specific hardware and software in addition to the system software.

G Terminal Client Server

Internal control program in Windows which allows the KCP shared pendant to
switch to other controllers (keys: SYM + Window selection key).
G Time pulse
This is generally supplied to the client controllers by the host controllers (selec-
tion in the Cell Map).
G User
Operator of a robot system who carries out simple commissioning tasks (mas-
tering, calibration) and creates basic application programs (with the aid of inline
forms).
G VxWorks operating system
The part of the KR C robot controller used for all tasks requiring real--time
processing, such as path planning or internal and external command
processing.
G Windows operating system
The part of the KR C robot controller used for operator control, display functions
and data management.
G Workspace
Program--dependent, overall motion range of all a robots axes.
1

Index
Numbers F
3--point method, 111 Find, 83, 134, 135
First mastering, 33
Fixed tool, 108
A Force, 83
Add, 103 Forms of cooperation, 9, 13
Adhesive bonding, 99 Frame, 107
Arc welding, 99 Function block, 19, 75
G
B
GEOLINK, 117
Basic motion, 12 Geometric coupling, 11
By existing Frame, 110
H
C Host controller, 22
Calibration, 35
Cell configuration, 19, 22, 50, 52 I
Cell Map, 19, 75 I/O functions, 86
Clock Sync Master, 54 Indirect geometric coupling, 101
Color, 22, 56 Installation type, 31
Combined procedure, 15 Interpreter, 12
Computer name, 49 IP addresses, 19, 47
Control cabinet, 22
Cooperation, 9 K
Copy, 103 KCP Clients, 55
Coupling, 73 KCP Master, 62
CR cabling, 21, 22, 44 KCP type, 57
Cut, 103 KRC Definition, 56
KUKA.CR Motion Cooperation, 19
D
L
Deadlock, 133
Lamp test, 61
Debug Off, 83, 134
LAN, 46
Debug On, 83
Laser welding, 99
Decoupling, 69 Linear unit, 15
Direct geometric coupling, 101 Linked Kinematic, 20
LK, 20
LK function, 99, 121
E
LK_Offset, 11
Enter, 83 LK_ROOT, 11
ENTERSPACE, 80, 85 Load data, 108
EXITSPACE, 80, 85 Load mastering, 33
External axis, 15 Load sharing, 12, 13, 15
External robot, 99 Local KRC name, 53
Index -- i
Index
Local robot, 99 REMOTE WAIT, 88

Robot name, 53
M Root, 36
Root -- Numeric Entry, 40
Master--slave principle, 15
Mastering, 33
Measuring tips, 36 S
Mechanism, 106 Safety circuit, 136
Mirroring, 104, 110 Safety data, 16, 21
Mirroring position points: Axis, 110 Safety Selection Board, 19, 21, 22, 44, 59
Motion block, 20 Shared KCP, 57
Motion Cooperation, 19 Shared memory network, 46
Motion start, 9 Shared Pendant, 19
Motion synchronization, 100 Shared pendant, 21
MotionSync, 20, 120 Signal lamp, 22
Signal lamps, 42, 61
N Simulation, 106
SM, 46
Network class, 46
Spot welding, 99
No KCP, 57
Subnet mask, 46
NO WAIT option, 78
Superposed motion, 12
Supplementary load data, 34
P SYNC, 120
Paste, 104 SYNC command, 10, 20
PLC, 16 Synchronization, 9, 100, 101, 120
Point name, 120 Synchronization name, 120
Position points, 109, 113 Synchronization period, 10
Positional accuracy, 31 Synchronization point, 9, 19, 76
Positioning robot, 14 System variable, 95
Process robot, 14
Process--dependent procedure, 14
T
Program command, 10
Program Cooperation, 19 Teach offset, 33
Program interpreter, 78 Teach pendant, 16
Program synchronization, 9, 100 Teaching, 125
PROGSYNC, 9, 19, 121 Technology package, 19
Terminal Client Server, 21
Terminating resistors, 29
R
Time pulse, 22
Real time, 21 Tool, 107
Refresh, 103 Transfer robot, 14
Relative, 104 Turntable, 15
REMOTE, 87, 98
REMOTE command, 16
Remote Command, 20, 87 V
Remote KRC name, 53 VxWorks, 22
REMOTE START, 88 VxWorks network, 46
Index -- ii
Index
W
WAIT option, 78
WCD, 34, 102
Windows, 22
Windows network, 46
Work Cell Diagram, 20
Workspace, 16, 20
Workspaces, 97
Index -- iii

KST CR Motion Cooperation 22 en

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

KST CR Motion Cooperation 22 en

Transféré par

Droits d'auteur :

Formats disponibles

SOFTWARE

KUKA.CR Motion Cooperation 2.2

For KUKA System Software (KSS) 5.3/5.4/5.5/5.6

Issued: 10 Jun 2009 Version: 02

KUKA.CR Motion Cooperation 2.2 06.09.02 en 1 of 144

KUKA Roboter GmbH

2 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

2 The cooperating robots concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 The KUKA.CR concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

KUKA.CR Motion Cooperation 2.2 06.09.02 en 3 of 144

8 Shared pendant (KCP2-- SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

KUKA.CR Motion Cooperation 2.2 06.09.02 en 5 of 144

10.3 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

11 Error treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

12 Abbreviations / technical terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

6 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

1.1 Target group

KUKA.CR Motion Cooperation 2.2 06.09.02 en 7 of 144

8 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

2 The cooperating robots concept

2.1.1 Synchronization of the motion start (Program Cooperation)

(1) Synchronization point

KUKA.CR Motion Cooperation 2.2 06.09.02 en 9 of 144

2.1.2 Synchronization of the motion time (Motion Cooperation)

(1) Synchronization point

The synchronization period t1 is programmed in the individual programs by means of the

10 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

2.2 Geometric coupling (master/slave)

KUKA.CR Motion Cooperation 2.2 06.09.02 en 11 of 144

2.2.1 Direct geometric coupling

Fig. 5 Load sharing

2.2.2 Indirect geometric coupling

Master Slave Slave

12 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

2.3 Forms of cooperation

2.3.1 Load sharing

KUKA.CR Motion Cooperation 2.2 06.09.02 en 13 of 144

2.3.2 Process--dependent procedure

Fig. 9 illustrates a form of cooperation between geometrically coupled robots. It is called a

14 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

2.3.3 Combined procedure

2.3.4 Extended master--slave principle

Fig. 12 Extended master--slave principle

KUKA.CR Motion Cooperation 2.2 06.09.02 en 15 of 144

2.4 Control system

Fig. 13 Shared workspace

G Control of one robot by another by means of REMOTE commands.

16 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

Please refer to the chapter [Safety] in the Operating Handbook.

KUKA.CR Motion Cooperation 2.2 06.09.02 en 17 of 144

18 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

4 The KUKA.CR concept

KUKA.CR Motion Cooperation

KUKA System Software (KSS)

Fig. 14 KUKA.CR Motion Cooperation function blocks

4.1 Function blocks

KUKA.CR Motion Cooperation 2.2 06.09.02 en 19 of 144

20 of 144 KUKA.CR Motion Cooperation 2.2 06.09.02 en

4.2 CR controller concept

(1) Shared pendant (KCP2--SP)

4.2.1 Shared pendant (KCP2--SP)

KUKA.CR Motion Cooperation 2.2 06.09.02 en 21 of 144