User manual | ABB IRC5 Controller software Application manual

Application manual

Controller software IRC5

Trace back information:

Workspace R16-1 version a6

Checked in 2016-03-01

Skribenta version 4.6.209

Application manual

Controller software IRC5

RobotWare 6.03

Document ID: 3HAC050798-001

Revision: C

© Copyright 2016 ABB. All rights reserved.

The information in this manual is subject to change without notice and should not be construed as a commitment by ABB. ABB assumes no responsibility for any errors that may appear in this manual.

Except as may be expressly stated anywhere in this manual, nothing herein shall be construed as any kind of guarantee or warranty by ABB for losses, damages to persons or property, fitness for a specific purpose or the like.

In no event shall ABB be liable for incidental or consequential damages arising from use of this manual and products described herein.

This manual and parts thereof must not be reproduced or copied without ABB's written permission.

Additional copies of this manual may be obtained from ABB.

The original language for this publication is English. Any other languages that are supplied have been translated from English.


ABB AB

Robotics Products

Se-721 68 Västerås

Sweden

Table of contents


Overview of this manual ...................................................................................................................

13

1 Introduction to RobotWare 15

2 RobotWare-OS

2.1

Advanced RAPID ..............................................................................................

2.1.1

Introduction to Advanced RAPID ................................................................

2.1.2

Bit functionality .......................................................................................

2.1.2.1 Overview ...................................................................................

2.1.2.2 RAPID components ......................................................................

2.1.2.3 Bit functionality example ...............................................................

2.1.3

Data search functionality ..........................................................................

2.1.3.1 Overview ...................................................................................


2.1.3.3 Data search functionality examples .................................................

2.1.4

Alias I/O signals ......................................................................................

2.1.4.1 Overview ...................................................................................


2.1.4.3 Alias I/O functionality example .......................................................

2.1.5

Configuration functionality ........................................................................

2.1.5.1 Overview ...................................................................................


2.1.5.3 Configuration functionality example ................................................

2.1.6

Power failure functionality .........................................................................

2.1.6.1 Overview ...................................................................................

2.1.6.2 RAPID components and system parameters .....................................

2.1.6.3 Power failure functionality example .................................................

2.1.7

Process support functionality ....................................................................

2.1.7.1 Overview ...................................................................................


2.1.7.3 Process support functionality examples ...........................................

2.1.8

Interrupt functionality ...............................................................................

2.1.8.1 Overview ...................................................................................


2.1.8.3 Interrupt functionality examples .....................................................

2.1.9

User message functionality .......................................................................

2.1.9.1 Overview ...................................................................................


2.1.9.3 User message functionality examples ..............................................

2.1.9.4 Text table files ............................................................................

2.1.10 RAPID support functionality ......................................................................

2.1.10.1 Overview ...................................................................................


2.1.10.3 RAPID support functionality examples .............................................

2.2

Analog Signal Interrupt .......................................................................................

2.2.1

Introduction to Analog Signal Interrupt ........................................................

2.2.2

RAPID components .................................................................................

2.2.3

Code example ........................................................................................

2.3

Auto Acknowledge Input .....................................................................................

2.4

Cyclic bool .......................................................................................................

2.4.1

Cyclically evaluated logical conditions ........................................................

2.4.2


2.4.3

Cyclic bool examples ...............................................................................

2.5

Electronically Linked Motors ................................................................................

2.5.1

Overview ...............................................................................................

2.5.2

Configuration .........................................................................................

2.5.2.1 System parameters ......................................................................

17

37

38

39

40

33

34

35

37

30

31

32

33

27

28

29

30

24

25

26

27

21

22

23

24

17

17

18

18

19

20

21

50

51

51

53

47

47

48

49

54

57

57

59

59

44

44

45

46

40

41

42

43

Application manual - Controller software IRC5

3HAC050798-001 Revision: C


5


2.5.2.2 Configuration example ..................................................................

2.5.3

Managing a follower axis ..........................................................................

2.5.3.1 Using the service program ............................................................

2.5.3.2 Calibrate follower axis position .......................................................

2.5.3.3 Reset follower axis ......................................................................

2.5.4

Tuning a torque follower ...........................................................................

2.5.4.1 Torque follower descriptions ..........................................................

2.5.4.2 Using the service program ............................................................

2.5.5

Data setup .............................................................................................

2.5.5.1 Set up data for service program .....................................................

2.5.5.2 Example of data setup ..................................................................

2.6

Fixed Position Events ........................................................................................

2.6.1

Overview ...............................................................................................

2.6.2

RAPID components and system parameters .................................................

2.6.3

Code examples .......................................................................................

2.7

File and Serial Channel Handling .........................................................................

2.7.1

Introduction to File and Serial Channel Handling ...........................................

2.7.2

Binary and character based communication .................................................

2.7.2.1 Overview ...................................................................................


2.7.2.3 Code examples ...........................................................................

2.7.3

Raw data communication ..........................................................................

2.7.3.1 Overview ...................................................................................


2.7.3.3 Code examples ...........................................................................

2.7.4

File and directory management ..................................................................

2.7.4.1 Overview ...................................................................................


2.7.4.3 Code examples ...........................................................................

2.8

Device Command Interface .................................................................................

2.8.1

Introduction to Device Command Interface ...................................................

2.8.2

RAPID components and system parameters .................................................

2.8.3

Code example ........................................................................................

2.9

Logical Cross Connections .................................................................................

2.9.1

Introduction to Logical Cross Connections ...................................................

2.9.2

Configuring Logical Cross Connections .......................................................

2.9.3

Examples ..............................................................................................

2.9.4

Limitations .............................................................................................

2.10 Remote Service Embedded .................................................................................

2.10.1 Overview ...............................................................................................

2.10.2 RSE connectivity .....................................................................................

2.10.3 Configuration - system parameters .............................................................

2.10.4 RSE registration ......................................................................................

2.10.5 Remote Service information ......................................................................

89

90

92

92

85

86

88

88

81

82

84

84

79

79

80

80

73

73

74

77

67

69

69

71

61

62

62

63

65

66

66

97

98

100

101

93

94

96

96

101

103

105

106

108

3 Motion performance 113

3.1

Absolute Accuracy [603-1, 603-2] .........................................................................

3.1.1

About Absolute Accuracy .........................................................................

3.1.2

When is Absolute Accuracy being used .......................................................

3.1.3

Useful tools ............................................................................................

3.1.4

Configuration .........................................................................................

3.1.5

Maintenance ..........................................................................................

3.1.5.1 Maintenance that affect the accuracy ..............................................

3.1.5.2 Loss of accuracy .........................................................................

3.1.6

Compensation theory ...............................................................................

3.1.6.1 Error sources ..............................................................................

3.1.6.2 Absolute Accuracy compensation ...................................................

3.1.7

Preparation of Absolute Accuracy robot ......................................................

3.1.7.1 ABB calibration process ................................................................

113

113

115

116

117

119

119

121

122

122

123

125

125

6 Application manual - Controller software IRC5




3.1.7.2 Birth certificate ............................................................................

3.1.7.3 Compensation parameters ............................................................

3.1.8

Cell alignment ........................................................................................

3.1.8.1 Overview ...................................................................................

3.1.8.2 Measure fixture alignment .............................................................

3.1.8.3 Measure robot alignment ..............................................................

3.1.8.4 Frame relationships .....................................................................

3.1.8.5 Tool calibration ...........................................................................

3.2

Advanced robot motion [687-1] ............................................................................

3.3

Advanced Shape Tuning [included in 687-1] ...........................................................

3.3.1

About Advanced Shape Tuning ..................................................................

3.3.2

Automatic friction tuning ...........................................................................

3.3.3

Manual friction tuning ..............................................................................

3.3.4

System parameters .................................................................................


3.3.4.2 Setting tuning system parameters ...................................................

3.3.5


3.4

Motion Process Mode [included in 687-1] ...............................................................

3.4.1

About Motion Process Mode .....................................................................

3.4.2

User-defined modes ................................................................................

3.4.3

General information about robot tuning .......................................................

3.4.4

Additional information ..............................................................................

3.5

Wrist Move [included in 687-1] .............................................................................

3.5.1

Introduction to Wrist Move ........................................................................

3.5.2

Cut plane frame ......................................................................................

3.5.3


3.5.4

RAPID code, examples .............................................................................

3.5.5

Trouble shooting .....................................................................................

143

144

145

145

147

149

152

153

153

155

157

158

160

135

136

137

137

138

140

142

142

127

128

131

131

132

133

134

4 Motion coordination 161

4.1

Machine Synchronization [607-1], [607-2] ...............................................................

4.1.1

Overview ...............................................................................................

4.1.2

What is needed .......................................................................................

4.1.3

Synchronization features ..........................................................................

4.1.4

General description of the synchronization process .......................................

4.1.5

Limitations .............................................................................................

4.1.6

Hardware installation for Sensor Synchronization ..........................................

4.1.6.1 Encoder specification ...................................................................

4.1.6.2 Encoder description .....................................................................

4.1.6.3 Installation recommendations ........................................................

4.1.6.4 Connecting encoder and encoder interface unit .................................

4.1.7

Hardware installation for Analog Synchronization ..........................................

4.1.7.1 Required hardware ......................................................................

4.1.8

Software installation ................................................................................

4.1.8.1 Sensor installation .......................................................................

4.1.8.2 Reloading saved Motion parameters ...............................................

4.1.8.3 Installation of several sensors ........................................................

4.1.9

Programming the synchronization ..............................................................

4.1.9.1 General issues when programming with the synchronization option ......

4.1.9.2 Programming examples ................................................................

4.1.9.3 Entering and exiting coordinated motion in corner zones ....................

4.1.9.4 Use several sensors .....................................................................

4.1.9.5 Finepoint programming .................................................................

4.1.9.6 Drop sensor object ......................................................................

4.1.9.7 Information on the FlexPendant ......................................................

4.1.9.8 Programming considerations .........................................................

4.1.9.9 Modes of operation ......................................................................

4.1.10 Robot to robot synchronization ..................................................................

4.1.10.1 Introduction ................................................................................

177

178

178

180

182

183

184

185

186

187

189

191

191

169

170

171

173

173

174

174

176

161

161

163

165

166

167

168

168




7


4.1.10.2 The concept of robot to robot synchronization ..................................

4.1.10.3 Master robot configuration parameters ............................................

4.1.10.4 Slave robot configuration parameters ..............................................

4.1.10.5 Programming example for master robot ...........................................

4.1.10.6 Programming example for slave robot .............................................

4.1.11 Synchronize with hydraulic press using recorded profile .................................

4.1.11.1 Introduction ................................................................................

4.1.11.2 Configuration of system parameters ................................................

4.1.11.3 Program example ........................................................................

4.1.12 Synchronize with molding machine using recorded profile ..............................

4.1.12.1 Introduction ................................................................................

4.1.12.2 Configuration of system parameters ................................................

4.1.12.3 Program example ........................................................................

4.1.13 Supervision ............................................................................................

4.1.14 System parameters .................................................................................

4.1.15 I/O signals .............................................................................................

4.1.16 RAPID components .................................................................................

203

205

206

206

207

209

210

211

214

215

192

193

196

199

201

202

202

5 Motion Events 217

5.1

World Zones [608-1] ..........................................................................................

5.1.1

Overview ...............................................................................................

5.1.2


5.1.3

Code examples .......................................................................................

217

217

219

221

6 Motion functions 223

6.1

Independent Axes [610-1] ...................................................................................

6.1.1

Overview ...............................................................................................

6.1.2


6.1.3


6.1.4

Code examples .......................................................................................

6.2

Path Recovery [611-1] ........................................................................................

6.2.1

Overview ...............................................................................................

6.2.2


6.2.3

Store current path ...................................................................................

6.2.4

Path recorder .........................................................................................

6.3

Path Offset [612-1] .............................................................................................

6.3.1

Overview ...............................................................................................

6.3.2


6.3.3

Related RAPID functionality ......................................................................

6.3.4

Code example ........................................................................................

230

231

237

244

244

245

246

247

223

223

225

226

227

229

229

7 Motion Supervision 249

7.1

Collision Detection [613-1] ..................................................................................

7.1.1

Overview ...............................................................................................

7.1.2

Limitations .............................................................................................

7.1.3

What happens at a collision .......................................................................

7.1.4

Additional information ..............................................................................

7.1.5

Configuration and programming facilities .....................................................



7.1.5.3 Signals ......................................................................................

7.1.6

How to use Collision Detection ..................................................................

7.1.6.1 Set up system parameters .............................................................

7.1.6.2 Adjust supervision from FlexPendant ..............................................

7.1.6.3 Adjust supervision from RAPID program ..........................................

7.1.6.4 How to avoid false triggering .........................................................

256

257

258

258

259

260

261

249

249

250

251

253

254

254





8 Communication 263

8.1

FTP Client [614-1] .............................................................................................

8.1.1

Introduction to FTP Client .........................................................................

8.1.2


8.1.3

Examples ..............................................................................................

8.2

NFS Client [614-1] .............................................................................................

8.2.1

Introduction to NFS Client .........................................................................

8.2.2


8.2.3

Examples ..............................................................................................

8.3

PC Interface [616-1] ...........................................................................................

8.3.1

Introduction to PC Interface .......................................................................

8.3.2

Send variable from RAPID ........................................................................

8.3.3

ABB software using PC Interface ...............................................................

8.4

Socket Messaging [616-1] ...................................................................................

8.4.1

Introduction to Socket Messaging ..............................................................

8.4.2

Schematic picture of socket communication .................................................

8.4.3

Technical facts about Socket Messaging .....................................................

8.4.4


8.4.5

Code examples .......................................................................................

8.5

RAPID Message Queue [included in 616-1, 623-1] ...................................................

8.5.1

Introduction to RAPID Message Queue .......................................................

8.5.2

RAPID Message Queue behavior ...............................................................

8.5.3


8.5.4


8.5.5

Code examples .......................................................................................

270

271

271

272

274

275

275

276

263

263

265

266

267

267

269

277

278

280

282

282

283

287

288

289

9 Engineering tools 293

9.1

Multitasking [623-1] ...........................................................................................

9.1.1

Introduction to Multitasking .......................................................................

9.1.2


9.1.3


9.1.4

Task configuration ...................................................................................

9.1.4.1 Debug strategies for setting up tasks ..............................................

9.1.4.2 Priorities ....................................................................................

9.1.4.3 Task Panel Settings .....................................................................

9.1.4.4 Select which tasks to start with START button ..................................

9.1.5

Communication between tasks ..................................................................

9.1.5.1 Persistent variables .....................................................................

9.1.5.2 Waiting for other tasks ..................................................................

9.1.5.3 Synchronizing between tasks .........................................................

9.1.5.4 Using a dispatcher .......................................................................

9.1.6

Other programming issues ........................................................................

9.1.6.1 Share resource between tasks .......................................................

9.1.6.2 Test if task controls mechanical unit ................................................

9.1.6.3 taskid ........................................................................................

9.1.6.4 Avoid heavy loops .......................................................................

9.2

Sensor Interface [628-1] .....................................................................................

9.2.1

Introduction to Sensor Interface .................................................................

9.2.2

Configuring sensors ................................................................................

9.2.2.1 About the sensors .......................................................................

9.2.2.2 Configuring sensors over serial channels .........................................

9.2.2.3 Configuring sensors over Ethernet channel ......................................

9.2.3

RAPID ...................................................................................................


9.2.4

Examples ..............................................................................................

9.2.4.1 Code examples ...........................................................................

314

315

316

317

317

318

318

319

320

321

321

324

324

303

305

305

307

309

311

313

313

293

293

295

297

298

298

300

302




9


9.3

Externally Guided Motion [689-1] ..........................................................................

9.3.1

Introduction to EGM .................................................................................

9.3.1.1 Overview ...................................................................................

9.3.1.2 Introduction to EGM Position Guidance ...........................................

9.3.1.3 Introduction to EGM Path Correction ...............................................

9.3.2

Using EGM ............................................................................................

9.3.2.1 Basic approach ...........................................................................

9.3.2.2 Execution states ..........................................................................

9.3.2.3 Input data ...................................................................................

9.3.2.4 Output data ................................................................................

9.3.2.5 Configuration ..............................................................................

9.3.2.6 Frames ......................................................................................

9.3.3

The EGM sensor protocol .........................................................................

9.3.4


9.3.5


9.3.6

RAPID code examples .............................................................................

9.3.6.1 Using EGM Position Guidance with an UdpUc device .........................

9.3.6.2 Using EGM Position Guidance with signals as input ...........................

9.3.6.3 Using EGM Path Correction with different protocol types ....................

9.3.7

UdpUc code examples .............................................................................

9.4

Robot Reference Interface [included in 689-1] ........................................................

9.4.1

Introduction to Robot Reference Interface ....................................................

9.4.2

Installation .............................................................................................

9.4.2.1 Connecting the communication cable ..............................................

9.4.2.2 Prerequisites ..............................................................................

9.4.2.3 Data orchestration .......................................................................

9.4.2.4 Supported data types ...................................................................

9.4.3

Configuration .........................................................................................

9.4.3.1 Interface configuration ..................................................................

9.4.3.2 Interface settings .........................................................................

9.4.3.3 Device description .......................................................................

9.4.3.4 Device configuration ....................................................................

9.4.4

Configuration examples ............................................................................

9.4.4.1 RAPID programming ....................................................................

9.4.4.2 Example configuration ..................................................................

9.4.5


357

358

359

360

361

361

362

363

346

346

348

352

355

356

356

357

366

369

369

370

375

331

332

335

336

337

339

343

344

326

326

326

328

329

330

330

10 Tool control options 377

10.1 Servo Tool Change [630-1] ..................................................................................

10.1.1 Overview ...............................................................................................

10.1.2 Requirements and limitations ....................................................................

10.1.3 Configuration .........................................................................................

10.1.4 Connection relay .....................................................................................

10.1.5 Tool change procedure ............................................................................

10.1.6 Jogging servo tools with activation disabled .................................................

10.2 Tool Control [1180-1] .........................................................................................

10.2.1 Overview ...............................................................................................

10.2.2 Servo tool movements .............................................................................

10.2.3 Tip management .....................................................................................

10.2.4 Supervision ............................................................................................

10.2.5 RAPID components .................................................................................


10.2.7 Commissioning and service ......................................................................

10.2.8 Mechanical unit calibrations ......................................................................

10.2.9 RAPID code example ...............................................................................

10.3 I/O Controlled Axes [included in 1180-1] ................................................................

10.3.1 Overview ...............................................................................................

10.3.2 Contouring error .....................................................................................

10.3.3 Correcting the position .............................................................................

385

386

387

389

390

391

396

398

377

377

378

380

381

383

384

385

399

400

400

401

402





Index

10.3.4 Tool changing .........................................................................................

10.3.5 Installation .............................................................................................

10.3.6 Configuration .........................................................................................


10.3.8 RAPID programming ................................................................................

403

404

405

407

409

411




11

This page is intentionally left blank

Overview of this manual


About this manual

This manual explains the basics of when and how to use various RobotWare options and functions.

Usage

Who should read this manual?

This manual is intended for robot programmers.

Prerequisites

This manual can be used either as a reference to find out if an option is the right choice for solving a problem, or as a description of how to use an option. Detailed information regarding syntax for RAPID routines, and similar, is not described here, but can be found in the respective reference manual.

The reader should...

• be familiar with industrial robots and their terminology.

• be familiar with the RAPID programming language.

• be familiar with system parameters and how to configure them.

References

Reference

Product specification - Controller software IRC5

IRC5 with main computer DSQC1000 and RobotWare 6.

Document ID

3HAC050945-001

Product specification - Controller IRC5

IRC5 with main computer DSQC1000.

Operating manual - RobotStudio

Operating manual - IRC5 with FlexPendant

3HAC047400-001

3HAC032104-001

3HAC050941-001

Technical reference manual - RAPID Instructions, Functions and

Data types

3HAC050917-001

Technical reference manual - RAPID overview 3HAC050947-001

Technical reference manual - System parameters 3HAC050948-001

Revisions

-

Revision

A

Description

Released with RobotWare 6.0.

First release.


• Added Auto Acknowledge Input, see

Auto Acknowledge Input on page 50

.

• The functionality of RAPID Message Queue is corrected, see

RAPID

Message Queue [included in 616-1, 623-1] on page 282 .

• Minor corrections.

Continues on next page





Continued

Revision

B

C

Description


• Updated the path to the template files, see

UdpUc code examples on page 355

and

Commissioning and service on page 396

.

• The TCP ports and protocols are updated for the option Sensor Interface

[628-1], see

Configuring sensors over Ethernet channel on page 320 .

• Added the functionality EGM Path Correction with corresponding

RAPID instructions, see

Externally Guided Motion [689-1] on page 326 .

• Bundled options are reordered in the manual according to the parent option.

• Updated the LTAPP variable list available for optical tracking, see

Constants on page 322

.


• Added the functionality

Cyclic bool on page 51

.

• Added the functionality

Remote Service Embedded on page 101

.

• Functionality is added and updated for option

Motion Process Mode

[included in 687-1] on page 145

.

• The option Servo Tool Control [included in 635-6] is replaced by the option

Tool Control [1180-1] on page 385

.

• Added the option

I/O Controlled Axes [included in 1180-1] on page 400 .

• Minor corrections.




1 Introduction to RobotWare


Software products

RobotWare is a family of software products from ABB Robotics. The products are designed to make you more productive and lower your cost of owning and operating a robot. ABB Robotics has invested many years into the development of these products and they represent knowledge and experience based on several thousands of robot installations.

Product classes

Within the RobotWare family, there are different classes of products:

Product classes

RobotWare-OS

RobotWare options

Description

This is the operating system of the robot. RobotWare-OS provides all the necessary features for fundamental robot programming and operation. It is an inherent part of the robot, but can be provided separately for upgrading purposes.

For a description of RobotWare-OS, see Product specification - Controller IRC5.

These products are options that run on top of RobotWare-OS. They are intended for robot users that need additional functionality for motion control, communication, system engineering, or applications.

Note

Not all RobotWare options are described in this manual. Some options are more comprehensive and are therefore described in separate manuals. For more information see Product specification - Controller software IRC5.

Process application options

RobotWare Add-ins

These are extensive packages for specific process application like spot welding, arc welding, and dispensing. They are primarily designed to improve the process result and to simplify installation and programming of the application.

The process application options are all described in separate manuals. For more information see Product specification - Controller software IRC5.

A RobotWare Add-in is a self-contained package that extends the functionality of the robot system.

Some software products from ABB Robotics are delivered as Addins. For example track motion IRBT, positioner IRBP, and stand alone controller. For more information see Product specification - Controller software IRC5.

The purpose of RobotWare Add-ins is also that a robot program developer outside of ABB can create options for the ABB robot systems, and sell the options to their customers. For more information on creating RobotWare Add-ins, contact your local ABB Robotics representative at www.abb.com/contacts .





15


Continued

Option groups

For IRC5, the RobotWare options have been gathered in groups, depending on the customer benefit. The goal is to make it easier to understand the customer value of the options. However, all options are purchased individually. The groups are as follows:

Option groups

Motion performance

Motion coordination

Motion Events

Motion functions

Motion Supervision

Communication

Engineering tools

Servo motor control

Description

Options that optimize the performance of your robot.

Options that make your robot coordinated with external equipment or other robots.

Options that supervises the position of the robot.

Options that controls the path of the robot.

Options that supervises the movement of the robot.

Options that make the robot communicate with other equipment.

(External PCs etc.)

Options for the advanced robot integrator.

Options that make the robot controller operate external motors, independent of the robot.

Note

Not all RobotWare options are described in this manual. Some options are more comprehensive and are therefore described in separate manuals. For more information see Product specification - Controller software IRC5.




2 RobotWare-OS

2.1.1 Introduction to Advanced RAPID

2 RobotWare-OS

2.1 Advanced RAPID

2.1.1 Introduction to Advanced RAPID

Introduction to Advanced RAPID

The RobotWare base functionality Advanced RAPID is intended for robot programmers who develop applications that require advanced functionality.

Advanced RAPID includes many different types of functionality, which can be divided into these groups:

Functionality group

Bit functionality

Data search functionality

Alias I/O functionality

Configuration functionality

Power failure functionality

Process support functionality

Interrupt functionality

User message functionality

RAPID support functionality

Description

Bitwise operations on a byte.

Search and get/set data objects (e.g. variables).

Give an I/O signal an optional alias name.

Get/set system parameters.

Restore signals after power failure.

Useful when creating process applications.

More interrupt functionality than included in Robot-

Ware base functionality.

Error messages and other texts.

Miscellaneous support for the programmer.




17

2 RobotWare-OS

2.1.2.1 Overview

2.1.2 Bit functionality

2.1.2.1 Overview

Purpose

The purpose of the bit functionality is to be able to make operations on a byte, seen as 8 digital bits. It is possible to get or set a single bit, or make logical operations on a byte. These operations are useful, for example, when handling serial communication or group of digital I/O signals.

What is included

Bit functionality includes:

• The data type byte

.

• Instructions used set a bit value:

BitSet and

BitClear

.

• Function used to get a bit value:

BitCheck

.

• Functions used to make logical operations on a byte:

BitAnd

,

BitOr

,

BitXOr

,

BitNeg

,

BitLSh

, and

BitRSh

.




2 RobotWare-OS

2.1.2.2 RAPID components

2.1.2.2 RAPID components

Data types

This is a brief description of each data type used for the bit functionality. For more information, see the respective data type in Technical reference manual - RAPID

Instructions, Functions and Data types.

Data type

byte

Description

The data type byte represent a decimal value between 0 and 255.

Instructions

This is a brief description of each instruction used for the bit functionality. For more information, see the respective instruction in Technical reference manual - RAPID


Instruction

BitSet

BitClear

Description

BitSet is used to set a specified bit to 1 in a defined byte data.

BitClear is used to clear (set to 0) a specified bit in a defined byte data.

Functions

This is a brief description of each function used for the bit functionality. For more information, see the respective function in Technical reference manual - RAPID


Function

BitAnd

BitOr

BitXOr

BitNeg

BitLSh

BitRSh

BitCheck

Description

BitAnd is used to execute a logical bitwise AND operation on data types byte.

BitOr is used to execute a logical bitwise OR operation on data types byte.

BitXOr

(Bit eXclusive Or) is used to execute a logical bitwise XOR operation on data types byte.

BitNeg is used to execute a logical bitwise negation operation (one’s complement) on data types byte.

BitLSh

(Bit Left Shift) is used to execute a logical bitwise left shift operation on data types byte.

BitRSh

(Bit Right Shift) is used to execute a logical bitwise right shift operation on data types byte.

BitCheck is used to check if a specified bit in a defined byte data is set to

1.

Tip

Even though not part of the option, the functions for conversion between a byte and a string,

StrToByte and

ByteToStr

, are often used together with the bit functionality.




19

2 RobotWare-OS

2.1.2.3 Bit functionality example

2.1.2.3 Bit functionality example

Program code

CONST num parity_bit := 8;

!Set data1 to 00100110

VAR byte data1 := 38;


VAR byte data2 := 34;

VAR byte data3;

!Set data3 to 00100010 data3 := BitAnd(data1, data2);

!Set data3 to 00100110 data3 := BitOr(data1, data2);

!Set data3 to 00000100 data3 := BitXOr(data1, data2);

!Set data3 to 11011001 data3 := BitNeg(data1);

!Set data3 to 10011000 data3 := BitLSh(data1, 2);

!Set data3 to 00010011 data3 := BitRSh(data1, 1);


BitSet data1, parity_bit;


BitClear data1, parity_bit;

!If parity_bit is 0, set it to 1

IF BitCheck(data1, parity_bit) = FALSE THEN

BitSet data1, parity_bit;

ENDIF




2 RobotWare-OS

2.1.3.1 Overview

2.1.3 Data search functionality


Purpose

The purpose of the data search functionality is to search and get/set values for data objects of a certain type.

Here are some examples of applications for the data search functionality:

• Setting a value to a variable, when the variable name is only available in a string.

• List all variables of a certain type.

• Set a new value for a set of similar variables with similar names.


Data search functionality includes:

• The data type datapos

.

• Instructions used to find a set of data objects and get or set their values:

SetDataSearch

,

GetDataVal

,

SetDataVal

, and

SetAllDataVal

.

• A function for traversing the search result:

GetNextSym

.




21

2 RobotWare-OS



Data types

This is a brief description of each data type used for the data search functionality.

For more information, see the respective data type in Technical reference manual - RAPID Instructions, Functions and Data types.

Data type

datapos

Description

datapos is the enclosing block to a data object (internal system data) retrieved with the function

GetNextSym

.

Instructions

This is a brief description of each instruction used for the data search functionality.

For more information, see the respective instruction in Technical reference manual - RAPID Instructions, Functions and Data types.

Instruction Description

SetDataSearch SetDataSearch is used together with

GetNextSym to retrieve data objects from the system.

GetDataVal GetDataVal makes it possible to get a value from a data object that is specified with a string variable, or from a data object retrieved with

GetNextSym

.

SetDataVal SetDataVal makes it possible to set a value for a data object that is specified with a string variable, or from a data object retrieved with

GetNextSym

.

SetAllDataVal SetAllDataVal make it possible to set a new value to all data objects of a certain type that match the given grammar.

Functions

This is a brief description of each function used for the data search functionality.

For more information, see the respective function in Technical reference manual - RAPID Instructions, Functions and Data types.

Function

GetNextSym

Description

GetNextSym

(Get Next Symbol) is used together with

SetDataSearch to retrieve data objects from the system.




2 RobotWare-OS

2.1.3.3 Data search functionality examples

2.1.3.3 Data search functionality examples

Set unknown variable

This is an example of how to set the value of a variable when the name of the variable is unknown when programming, and only provided in a string.

VAR string my_string;

VAR num my_number;

VAR num new_value:=10; my_string := "my_number";

!Set value to 10 for variable specified by my_string

SetDataVal my_string,new_value;

Reset a range of variables

This is an example where all numeric variables starting with "my" is reset to 0.

VAR string my_string:="my.*";

VAR num zerovar:=0;

SetAllDataVal "num"\Object:=my_string,zerovar;

List/set certain variables

In this example, all numeric variables in the module "mymod" starting with "my" are listed on the FlexPendant and then reset to 0.

VAR datapos block;

VAR string name;

VAR num valuevar;

VAR num zerovar:=0;

!Search for all num variables starting with "my" in the module

"mymod"

SetDataSearch "num"\Object:="my.*"\InMod:="mymod";

!Loop through the search result

WHILE GetNextSym(name,block) DO

!Read the value from each found variable

GetDataVal name\Block:=block,valuevar;

!Write name and value for each found variable

TPWrite name+" = "\Num:=valuevar;

!Set the value to 0 for each found variables

SetDataVal name\Block:=block,zerovar;

ENDWHILE




23

2 RobotWare-OS

2.1.4.1 Overview

2.1.4 Alias I/O signals


Purpose

The Alias I/O functionality gives the programmer the ability to use any name on a signal and connect that name to a configured I/O signal.

This is useful when a RAPID program is reused between different systems. Instead of rewriting the code, using a signal name that exist on the new system, the signal name used in the program can be defined as an alias name.


Alias I/O functionality consists of the instruction

AliasIO

.




2 RobotWare-OS



Data types

There are no RAPID data types for the Alias I/O functionality.

Instructions

This is a brief description of each instruction used for the Alias I/O functionality.


Instruction

AliasIO

Description

AliasIO is used to define a signal of any type with an alias name, or to use signals in built-in task modules. The alias name is connected to a configured I/O signal.

The instruction

AliasIO must be run before any use of the actual signal.

Functions

There are no RAPID functions for the Alias I/O functionality.




25

2 RobotWare-OS

2.1.4.3 Alias I/O functionality example

2.1.4.3 Alias I/O functionality example

Assign alias name to signal

This example shows how to define the digital output signal alias_do to be connected to the configured digital output I/O signal config_do

.

The routine prog_start is connected to the START event.

This will ensure that "alias_do" can be used in the RAPID code even though there is no configured signal with that name.

VAR signaldo alias_do;

PROC prog_start()

AliasIO config_do, alias_do;

ENDPROC




2 RobotWare-OS

2.1.5.1 Overview

2.1.5 Configuration functionality


Purpose

The configuration functionality gives the programmer access to the system parameters at run time. The parameter values can be read and edited. The controller can be restarted in order for the new parameter values to take effect.


Configuration functionality includes the instructions:

ReadCfgData

,

WriteCfgData

, and

WarmStart

.




27

2 RobotWare-OS



Data types

There are no RAPID data types for the configuration functionality.

Instructions

This is a brief description of each instruction used for the configuration functionality.


Instruction

ReadCfgData

WarmStart

Description

ReadCfgData is used to read one attribute of a named system parameter

(configuration data).

WriteCfgData WriteCfgData is used to write one attribute of a named system parameter (configuration data).

WarmStart is used to restart the controller at run time.

This is useful after changing system parameters with the instruction

WriteCfgData

.

Functions

There are no RAPID functions for the configuration functionality.




2 RobotWare-OS

2.1.5.3 Configuration functionality example

2.1.5.3 Configuration functionality example

Configure system parameters

This is an example where the system parameter cal_offset for rob1_1 is read, increased by 0.2 mm and then written back. To make this change take effect, the controller is restarted.

VAR num old_offset;

VAR num new_offset;

ReadCfgData "/MOC/MOTOR_CALIB/rob1_1", "cal_offset",old_offset; new_offset := old_offset + (0.2/1000);

WriteCfgData "/MOC/MOTOR_CALIB/rob1_1", "cal_offset",new_offset;

WarmStart;




29

2 RobotWare-OS

2.1.6.1 Overview

2.1.6 Power failure functionality


Purpose

If the robot was in the middle of a path movement when the power fail occurred, some extra actions may need to be taken when the robot motion is resumed. The power failure functionality helps you detect if the power fail occurred during a path movement.

Note

For more information see the type Signal Safe Level, which belongs to the topic

I/O System, in Technical reference manual - System parameters.


The power failure functionality includes a function that checks for interrupted path:

PFRestart




2 RobotWare-OS

2.1.6.2 RAPID components and system parameters

2.1.6.2 RAPID components and system parameters

Data types

There are no RAPID data types in the power failure functionality.

Instructions

There are no RAPID instructions in the power failure functionality.

Functions

This is a brief description of each function in the power failure functionality. For more information, see the respective function in Technical reference manual - RAPID


Function

PFRestart

Description

PFRestart

(Power Failure Restart) is used to check if the path was interrupted at power failure. If so it might be necessary to make some specific actions. The function checks the path on current level, base level or on interrupt level.

System parameters

There are no system parameters in the power failure functionality. However, regardless of whether you have any options installed, you can use the parameter

Store signal at power fail.

For more information, see Technical reference manual - System parameters.




31

2 RobotWare-OS

2.1.6.3 Power failure functionality example

2.1.6.3 Power failure functionality example

Test for interrupted path

When resuming work after a power failure, this example tests if the power failure occurred during a path (i.e. when the robot was moving).

!Test if path was interrupted

IF PFRestart() = TRUE THEN

SetDO do5,1;

ELSE

SetDO do5,0;

ENDIF




2 RobotWare-OS

2.1.7.1 Overview

2.1.7 Process support functionality


Purpose

Process support functionality provides some RAPID instructions that can be useful when creating process applications. Examples of its use are:

• Analog output signals, used in continuous process application, can be set to be proportional to the robot TCP speed.

• A continuous process application that is stopped with program stop or emergency stop can be continued from where it stopped.


The process support functionality includes:

• The data type restartdata

.

• Instruction for setting analog output signal:

TriggSpeed

.

• Instructions used in connection with restart:

TriggStopProc and

StepBwdPath

.

Limitations

The instruction

TriggSpeed can only be used if you have the base functionality

Fixed Position Events.




33

2 RobotWare-OS



Data types

This is a brief description of each data type used for the process support functionality. For more information, see the respective data type in Technical reference manual - RAPID Instructions, Functions and Data types.

Data type

restartdata

Description

restartdata can contain the pre- and post-values of specified I/O signals (process signals) at the stop sequence of the robot movements.

restartdata

, together with the instruction

TriggStopProc is used to preserve data for the restart after program stop or emergency stop of self-developed process instructions.

Instructions

This is a brief description of each instruction used for the process support functionality. For more information, see the respective instruction in Technical reference manual - RAPID Instructions, Functions and Data types.

Instruction

TriggSpeed

Description

TriggSpeed is used to define the setting of an analog output to a value proportional to the TCP speed.

TriggSpeed can only be used together with the option Fixed Position

Events.

TriggStopProc TriggStopProc is used to store the pre- and post-values of all used process signals.

TriggStopProc and the data type restartdata are used to preserve data for the restart after program stop or emergency stop of self-developed process instructions.

StepBwdPath StepBwdPath is used to move the TCP backwards on the robot path from a RESTART event routine.

Functions

There are no RAPID functions for the process support functionality.




2 RobotWare-OS

2.1.7.3 Process support functionality examples

2.1.7.3 Process support functionality examples

Signal proportional to speed

In this example, the analog output signal that controls the amount of glue is set to be proportional to the speed.

Any speed dip by the robot is time compensated in such a way that the analog output signal glue_ao is affected 0.04 s before the TCP speed dip occurs. If overflow of the calculated logical analog output value in glue_ao

, the digital output signal glue_err is set.

VAR triggdata glueflow;

!The glue flow is set to scale value 0.8 0.05 s before point p1

TriggSpeed glueflow, 0, 0.05, glue_ao, 0.8 \DipLag=:0.04,

\ErrDO:=glue_err;

TriggL p1, v500, glueflow, z50, gun1;

!The glue flow is set to scale value 1 10 mm plus 0.05 s before point p2

TriggSpeed glueflow, 10, 0.05, glue_ao, 1;


!The glue flow ends (scale value 0) 0.05 s before point p3

TriggSpeed glueflow, 0, 0.05, glue_ao, 0;


Tip

Note that it is also possible to create self-developed process instructions with

TriggSpeed using the

NOSTEPIN routine concept.

Resume signals after stop

In this example, an output signal resumes its value after a program stop or emergency stop.

The procedure supervise is defined as a POWER ON event routine and resume_signals as a RESTART event routine.

PERS restartdata myproc_data :=

[FALSE,FALSE,0,0,0,0,0,0,0,0,0,0,0,0,0];

...

PROC myproc()

MoveJ p1, vmax, fine, my_gun;

SetDO do_close_gun, 1;

MoveL p2,v1000,z50,my_gun;

MoveL p3,v1000,fine,my_gun;

SetDO do_close_gun, 0;

ENDPROC

...

PROC supervise()

TriggStopProc myproc_data \DO1:=do_close_gun, do_close_gun;





2 RobotWare-OS

2.1.7.3 Process support functionality examples

Continued

ENDPROC

PROC resume_signals()

IF myproc_data.preshadowval = 1 THEN

SetDO do_close_gun,1;

ELSE

SetDO do_close_gun,0;

ENDIF

ENDPROC

Move TCP backwards

In this example, the TCP is moved backwards 30 mm in 1 second, along the same path as before the restart.

The procedure move_backward is defined as a RESTART event routine.

PROC move_backward()

StepBwdPath 30, 1;

ENDPROC




2 RobotWare-OS

2.1.8.1 Overview

2.1.8 Interrupt functionality


Purpose

The interrupt functionality in Advanced RAPID has some extra features, in addition to the interrupt features always included in RAPID. For more information on the basic interrupt functionality, see Technical reference manual - RAPID overview.

Here are some examples of interrupt applications that Advanced RAPID facilitates:

• Generate an interrupt when a persistent variable change value.

• Generate an interrupt when an error occurs, and find out more about the error.


The interrupt functionality in Advanced RAPID includes:

• Data types for error interrupts: trapdata

, errdomain

, and errtype

.

• Instructions for generating interrupts:

IPers and

IError

.

• Instructions for finding out more about an error interrupt:

GetTrapData and

ReadErrData

.




37

2 RobotWare-OS



Data types

This is a brief description of each data type in the interrupt functionality. For more information, see the respective data type in Technical reference manual - RAPID


Data type

trapdata errdomain errtype

Description

trapdata represents internal information related to the interrupt that caused the current trap routine to be executed.

errdomain is used to specify an error domain. Depending on the nature of the error, it is logged in different domains.

errtype is used to specify an error type (error, warning, state change).

Instructions

This is a brief description of each instruction in the interrupt functionality. For more information, see the respective instruction in Technical reference manual - RAPID


Instruction

IPers

Description

IPers

(Interrupt Persistent) is used to order an interrupt to be generated each time the value of a persistent variable is changed.

IError IError

(Interrupt Errors) is used to order an interrupt to be generated each time an error occurs.

GetTrapData GetTrapData is used in trap routines generated by the instruction

IError

.

GetTrapData obtains all information about the interrupt that caused the trap routine to be executed.

ReadErrData ReadErrData is used in trap routines generated by the instruction

IError

.

ReadErrData read the information obtained by

GetTrapData

.

ErrRaise ErrRaise is used to create an error in the program and the call the error handler of the routine.

ErrRaise can also be used in the error handler to propagate the current error to the error handler of the calling routine.

Functions

There are no RAPID functions for the interrupt functionality.




2 RobotWare-OS

2.1.8.3 Interrupt functionality examples

2.1.8.3 Interrupt functionality examples

Interrupt when persistent variable changes

In this example, a trap routine is called when the value of the persistent variable counter changes.

VAR intnum int1;

PERS num counter := 0;

PROC main()

CONNECT int1 WITH iroutine1;

IPers counter, int1;

...

counter := counter + 1;

...

Idelete int1;

ENDPROC

TRAP iroutine1

TPWrite "Current value of counter = " \Num:=counter;

ENDTRAP

Error interrupt

In this example, a trap routine is called when an error occurs. The trap routine determines the error domain and the error number and communicates them via output signals.

VAR intnum err_interrupt;

VAR trapdata err_data;

VAR errdomain err_domain;

VAR num err_number;

VAR errtype err_type;

PROC main()

CONNECT err_interrupt WITH trap_err;

IError COMMON_ERR, TYPE_ERR, err_interrupt;

...

a:=3; b:=0; c:=a/b;

...

IDelete err_interrupt;

ENDPROC

TRAP trap_err

GetTrapData err_data;

ReadErrData err_data, err_domain, err_number, err_type;

SetGO go_err1, err_domain;

SetGO go_err2, err_number;

ENDTRAP




39

2 RobotWare-OS

2.1.9.1 Overview

2.1.9 User message functionality


Purpose

The user message functionality is used to set up event numbers and facilitate the handling of event messages and other texts to be presented in the user interface.

Here are some examples of applications:

• Get user messages from a text table file, which simplifies updates and translations.

• Add system error number to be used as error recovery constants in RAISE instructions and for test in ERROR handlers.


The user message functionality includes:

• Text table operating instruction

TextTabInstall

.

• Text table operating functions:

TextTabFreeToUse

,

TextTabGet

, and

TextGet

.

• Instruction for error number handling:

BookErrNo

.




2 RobotWare-OS



Data types

There are no RAPID data types for the user message functionality.

Instructions

This is a brief description of each instruction used for the user message functionality. For more information, see the respective instruction in Technical reference manual - RAPID Instructions, Functions and Data types.

Instruction

BookErrNo

Description

BookErrNo is used to define a new RAPID system error number.

TextTabInstall TextTabInstall is used to install a text table in the system.

Functions

This is a brief description of each function used for the user message functionality.


Function Description

TextTabFreeToUse TextTabFreeToUse is used to test whether the text table name is free to use (not already installed in the system).

TextTabGet

TextGet

TextTabGet is used to get the text table number of a user defined text table.

TextGet is used to get a text string from the system text tables.




41

2 RobotWare-OS

2.1.9.3 User message functionality examples

2.1.9.3 User message functionality examples

Book error number

This example shows how to add a new error number.

VAR intnum sig1int;

!Introduce a new error number in a glue system.

!Note: The new error variable must be declared with the initial value -1

VAR errnum ERR_GLUEFLOW := -1;

PROC main()

!Book the new RAPID system error number

BookErrNo ERR_GLUEFLOW;

!Raise glue flow error if di1=1

IF di1=1 THEN

RAISE ERR_GLUEFLOW;

ENDIF

ENDPROC

!Error handling

ERROR

IF ERRNO = ERR_GLUEFLOW THEN

ErrWrite "Glue error", "There is a problem with the glue flow";

ENDIF

Error message from text table file

This example shows how to get user messages from a text table file.

There is a text table named text_table_name in a file named

HOME:/language/en/text_file.xml. This table contains error messages in english.

The procedure install_text is executed at event POWER ON. The first time it is executed, the text table file text_file.xml is installed. The next time it is executed, the function

TextTabFreeToUse returns FALSE and the installation is not repeated.

The table is then used for getting user interface messages.

VAR num text_res_no;

PROC install_text()

!Test if text_table_name is already installed

IF TextTabFreeToUse("text_table_name") THEN

!Install the table from the file HOME:/language/en/text_file.xml

TextTabInstall "HOME:/language/en/text_file.xml";

ENDIF

!Assign the text table number for text_table_name to text_res_no text_res_no := TextTabGet("text_table_name");

ENDPROC

...

!Write error message with two strings from the table text_res_no

ErrWrite TextGet(text_res_no, 1), TextGet(text_res_no, 2);




2 RobotWare-OS

2.1.9.4 Text table files

2.1.9.4 Text table files

Overview

A text table is stored in an XML file (each file can contain one table in one language).

This table can contain any number of text strings.

Explanation of the text table file

This is a description of the XML tags and arguments used in the text table file.

Tag

Resource

Argument

Text

Value

Comment

Name

Language

Name

Description

Represents a text table. A file can only contain one instance of

Resource.

The name of the text table. Used by the RAPID instruction

TextTabGet

.

Language code for the language of the text strings.

Currently this argument is not being used. The RAPID instruction

TextTabInstall can only handle English texts.

Represents a text string.

The text string’s number in the table.

The text string to be used.

Comments about the text string and its usage.

Example of text table file

<?xml version="1.0" encoding="iso-8859-1" ?>

<Resource Name="text_table_name" Language="en">

<Text Name="1">

<Value>This is a text that is </Value>

<Comment>The first part of my text</Comment>

</Text>

<Text Name="2">

<Value>displayed in the user interface.</Value>

<Comment>The second part of my text</Comment>

</Text>

</Resource>




43

2 RobotWare-OS

2.1.10.1 Overview

2.1.10 RAPID support functionality

2.1.10.1 Overview

Purpose

The RAPID support functionality consists of miscellaneous routines that might be helpful for an advanced robot programmer.


• Activate a new tool, work object or payload.

• Find out what an argument is called outside the current routine.

• Test if the program pointer has been moved during the last program stop.


RAPID support functionality includes:

• Instruction for activating specified system data:

SetSysData

.

• Function that gets original data object name:

ArgName

.

• Function for information about program pointer movement:

IsStopStateEvent

.




2 RobotWare-OS



Data types

There are no data types for RAPID support functionality.

Instructions

This is a brief description of each instruction used for RAPID support functionality.


Instruction

SetSysData

Description

SetSysData activates (or changes the current active) tool, work object, or payload for the robot.

Functions

This is a brief description of each function used for RAPID support functionality.


Function Description

ArgName ArgName is used to get the name of the original data object for the current argument or the current data.

IsStopStateEvent IsStopStateEvent returns information about the movement of the program pointer.




45

2 RobotWare-OS

2.1.10.3 RAPID support functionality examples

2.1.10.3 RAPID support functionality examples

Activate tool

This is an example of how to activate a known tool:

!Activate tool1

SetSysData tool1;

This is an example of how to activate a tool when the name of the tool is only available in a string:

VAR string tool_string := "tool2";

!Activate the tool specified in tool_string

SetSysData tool0 \ObjectName := tool_string;

Get argument name

In this example, the original name of par1 is fetched. The output will be "Argument name my_nbr with value 5".

VAR num my_nbr :=5; proc1 my_nbr;

PROC proc1 (num par1)

VAR string name; name:=ArgName(par1);

TPWrite "Argument name "+name+" with value " \Num:=par1;

ENDPROC

Test if program pointer has been moved

This example tests if the program pointer was moved during the last program stop.

IF IsStopStateEvent (\PPMoved) = TRUE THEN

TPWrite "The program pointer has been moved.";

ENDIF




2 RobotWare-OS

2.2.1 Introduction to Analog Signal Interrupt

2.2 Analog Signal Interrupt

2.2.1 Introduction to Analog Signal Interrupt

Purpose

The purpose of Analog Signal Interrupt is to supervise an analog signal and generate an interrupt when a specified value is reached.

Analog Signal Interrupt is faster, easier to implement, and require less computer capacity than polling methods.


• Save cycle time with better timing (start robot movement exactly when a signal reach the specified value, instead of waiting for polling).

• Show warning or error messages if a signal value is outside its allowed range.

• Stop the robot if a signal value reaches a dangerous level.


The RobotWare base functionality Analog Signal Interrupt gives you access to the instructions:

•

ISignalAI

•

ISignalAO

Basic approach

This is the general approach for using Analog Signal Interrupt. For a more detailed example of how this is done, see

Code example on page 49 .

1 Create a trap routine.

2 Connect the trap routine using the instruction

CONNECT

.

3 Define the interrupt conditions with the instruction

ISignalAI or

ISignalAO

.

Limitations

Analog signals can only be used if you have an industrial network option (for example DeviceNet or PROFIBUS).




47

2 RobotWare-OS

2.2.2 RAPID components

2.2.2 RAPID components

Data types

Analog Signal Interrupt includes no data types.

Instructions

This is a brief description of each instruction in Analog Signal Interrupt. For more information, see the respective instruction in Technical reference manual - RAPID


Instruction

ISignalAI

ISignalAO

Description

Defines the values of an analog input signal, for which an interrupt routine shall be called.

An interrupt can be set to occur when the signal value is above or below a specified value, or inside or outside a specified range. It can also be specified if the interrupt shall occur once or repeatedly.

Defines the values of an analog output signal, for which an interrupt routine shall be called.

An interrupt can be set to occur when the signal value is above or below a specified value, or inside or outside a specified range. It can also be specified if the interrupt shall occur once or repeatedly.

Functions

Analog Signal Interrupt includes no RAPID functions.




2 RobotWare-OS

2.2.3 Code example

2.2.3 Code example

Temperature surveillance

In this example a temperature sensor is connected to the signal ai1

.

An interrupt routine with a warning is set to execute every time the temperature rises 0.5 degrees in the range 120-130 degrees. Another trap routine, stopping the robot, is set to execute as soon as the temperature rise above 130 degrees.

VAR intnum ai1_warning;

VAR intnum ai1_exeeded;

PROC main()

CONNECT ai1_warning WITH temp_warning;

CONNECT ai1_exeeded WITH temp_exeeded;

ISignalAI ai1, AIO_BETWEEN, 130, 120, 0.5, \DPos, ai1_warning;

ISignalAI \Single, ai1, AIO_ABOVE_HIGH, 130, 120, 0, ai1_exeeded;

...

IDelete ai1_warning;

IDelete ai1_exeeded;

ENDPROC

TRAP temp_warning

TPWrite "Warning: Temperature is "\Num:=ai1;

ENDTRAP

TRAP temp_exeeded

TPWrite "Temperature is too high";

Stop;

ENDTRAP




49

2 RobotWare-OS

2.3 Auto Acknowledge Input

2.3 Auto Acknowledge Input

Description

Auto Acknowledge Input is a system input which will acknowledge the dialog presented on the FlexPendant when switching from operator mode manual to auto with the key switch on the robot controller.

WARNING

Note that using such an input will be contrary to the regulations in the safety standard ISO 10218-1 chapter 5.3.5 Single point of control with following text:

"The robot control system shall be designed and constructed so that when the robot is placed under local pendant control or other teaching device control, initiation of robot motion or change of local control selection from any other source shall be prevented."

Thus it is absolutely necessary to use other means of safety to maintain the requirements of the standard and the machinery directive and also to make a risk assessment of the completed cell. Such additional arrangements and risk assessment is the responsibility of the system integrator and the system must not be put into service until these actions have been completed

Limitations

The system parameter cannot be defined using the FlexPendant or RobotStudio, only with a text string in the I/O configuration file.

Activate Auto Acknowledge Input

Use the following procedure to activate the system input for Auto Acknowledge

Input.

3

4

1

2

Action

Save a copy of the I/O configuration file, eio.cfg, using the FlexPendant or RobotStudio.

Edit the I/O configuration file, eio.cfg, using a text editor. Add the following line in the group

SYSSIG_IN

:

-Signal "my_signal_name" -Action "AckAutoMode" my_signal_name is the name of the configured digital input signal that should be used as the system input.

Save the file and reload it to the controller.

Restart the system to activate the signal.




2 RobotWare-OS

2.4.1 Cyclically evaluated logical conditions

2.4 Cyclic bool

2.4.1 Cyclically evaluated logical conditions

Purpose

The purpose of cyclically evaluated logical conditions, Cyclic bool, is to allow a

RAPID programmer to connect a logical condition to a persistent boolean variable.

The logical condition will be evaluated every 12 ms and the result will be written to the connected variable.


The RobotWare base functionality Cyclic bool includes:

• instructions for setting up Cyclic bool:

SetupCyclicBool

,

RemoveCyclicBool

,

RemoveAllCyclicBool

• functions for retrieving the status of Cyclic bool:

GetMaxNumberOfCyclicBool

,

GetNextCyclicBool

,

GetNumberOfCyclicBool

.

Basic approach

This is the general approach for using Cyclic bool. For more detailed examples of how this is done, see

Cyclic bool examples on page 54

.

1 Declare a persistent boolean variable, for example:

PERS bool cyclicbool1;

2 Connect a logical condition to the variable, for example:

SetupCyclicBool cyclicbool1, doSafetyIsOk = 1;

3 Use the variable when programming, for example:

WHILE cyclicbool1 = 1 DO

! Do what’s only allowed when all safety is ok

...

ENDWHILE

4 Remove connection when no longer useful, for example:

RemoveCyclicBool cyclicbool1;

Syntax

SetupCyclicBool Flag Cond

Flag shall be of:

• Data type: bool

Object type:

PERS or

TASK PERS

Cond shall be a bool expression that may consist of:

• Data types: num

, dnum and bool

Object type:

PERS

,

TASK PERS

, or

CONST

• Data types: signaldi

, signaldo or physical di and do

Object type:

VAR





2 RobotWare-OS

2.4.1 Cyclically evaluated logical conditions

Continued

• Operands: '

NOT

', '

AND

', '

OR

', '

XOR

', '

=

', '

(

', '

)

'

RemoveCyclicBool Flag

Flag shall be of:

• Data type: bool

Object type:

PERS or

TASK PERS

Limitations

• Records and arrays are not allowed in the logical condition.

• A maximum of 60 conditions can be connected at the same time.




2 RobotWare-OS



About the RAPID components

This is an overview of all RAPID instructions, functions, and data types in Cyclic bool.

For more information, see Technical reference manual - RAPID Instructions,

Functions and Data types.

Instructions

Instruction

SetupCyclicBool

Description

SetupCyclicBool connects a logical condition to a boolean variable.

RemoveCyclicBool RemoveCyclicBool removes a specific connected logical condition.

RemoveAllCyclicBool RemoveAllCyclicBool removes all connected logical conditions.

Functions

Function

GetMaxNumberOfCyclicBool

GetNextCyclicBool

GetNumberOfCyclicBool

Description

GetMaxNumberOfCyclicBool retrieves the maximum number of cyclically evaluated logical condition that can be connected at the same time.

GetNextCyclicBool retrieves the name of a connected cyclically evaluated logical condition.

GetNumberOfCyclicBool retrieves the number of a connected cyclically evaluated logical condition.

Data types

Cyclic bool includes no data types.




53

2 RobotWare-OS

2.4.3 Cyclic bool examples

2.4.3 Cyclic bool examples

Using digital input and output signals

! Wait until all signals are set

PERS bool cyclicbool1 := FALSE;

PROC main()

SetupCyclicBool cyclicbool1, di1=1 AND do2=1;

WaitUntil cyclicbool1=TRUE;

! All is ok

...

! Remove connection when no longer in use


ENDPROC

Using bool variables

! Wait until all flags are TRUE


TASK PERS bool flag1 := FALSE;

PERS bool flag2 := FALSE;

PROC main()

SetupCyclicBool cyclicbool1, flag1=TRUE AND flag2=TRUE;


! All is ok

...



ENDPROC

Using num and dnum variables

! Wait until all conditions are met



PERS num num1 := 0;

PERS dnum1 := 0;

PROC main()

SetupCyclicBool cyclicbool1, num1=7 OR dnum1=10000000;

SetupCyclicBool cyclicbool2, num1=8 OR dnum1=11000000;


...


...

! Remove all connections when no longer in use

RemoveAllCyclicBool;

ENDPROC





2 RobotWare-OS


Continued

Using alias variables


ALIAS bool aliasBool;

ALIAS num aliasNum;

ALIAS dnum aliasDnum;


PERS aliasBool flag1 := FALSE;

PERS aliasNum num1 := 0;

PERS aliasDnum dnum1 := 0;

PROC main()

SetupCyclicBool cyclicbool1, flag1=TRUE AND (num1=7 OR dnum1=10000000);


! All is ok

...



ENDPROC

Using user defined constants for comparison


PERS bool cyclicbool1;

PERS bool flag1 := FALSE;

PERS num num1 := 0;

PERS dnum dnum1 := 0;

CONST bool MYTRUE := TRUE;

CONST num NUMLIMIT := 10;

CONST dnum DNUMLIMIT := 10000000;

PROC main()

SetupCyclicBool cyclicbool1, flag1=MYTRUE AND num1=NUMLIMIT AND dnum1=DNUMLIMIT;


! All is ok

...



ENDPROC





55

2 RobotWare-OS


Continued

Handing over arguments by reference

If the instruction

SetupCyclicBool is used inside a called procedure, it is possible to hand over conditions as arguments to that procedure.

Using conditions passed by reference works only for

SetupCyclicBool

. Conditions passed by reference has the same restrictions as conditions for

SetupCyclicBool

.

This functionality works regardless if the modules are

Nostepin or has any other module attributes.

MODULE MainModule

CONST robtarget p10 := [[600,500,225.3], [1,0,0,0], [1,1,0,0],

[11,12.3,9E9,9E9,9E9,9E9]];

PERS bool m1;

PERS bool Flag2 := FALSE;

PROC main()

! The Expression (di_1 = 1) OR Flag2 = TRUE shall be used by

SetupCyclicBool my_routine (di_1 = 1) OR Flag2 = TRUE;

ENDPROC

PROC my_routine(bool X)

! It is possible to pass arguments between several procedures

MySetCyclicBool X;

ENDPROC

PROC MySetCyclicBool (bool Y)

RemoveCyclicBool m1;

! Only SetupCyclicBool can pass arguments

SetupCyclicBool m1, Y;

! If conditions passed by reference shall be used by any other instruction, the condition must be setup with

SetupCyclicBool before it can be used.

WaitUntil m1;

MoveL p10, v1000, z30, tool2;

ENDPROC

ENDMODULE




2 RobotWare-OS

2.5.1 Overview

2.5 Electronically Linked Motors

2.5.1 Overview

Description

Electronically Linked Motors makes a master/follower configuration of motors (for example two additional axes). The follower axis will continuously follow the master axis in terms of position, velocity, and acceleration.

For stiff mechanical connection between the master and followers, the torque follower function can be used. Instead of regulating to exactly the same position for the master and follower, the torque is distributed between the axes. A small position error between master and follower will occur depending on backlash and mechanical misalignment.

Purpose

The primary purpose of Electronically Linked Motors is to replace driving shafts of gantry machines, but the base functionality can be used to control any other set of motors as well.


The RobotWare base functionality Electronically Linked Motors gives you access to:

• a service program for defining linked motor groups and trimming the axis positions

• system parameters used to configure a follower axis

Basic approach

This is the general approach for setting up Electronically Linked Motors. For a more detailed description of how this is done, see the respective section.

1 Configure the additional axes that you want to use. See Application manual - Additional axes and stand alone controller.

2 Configure tolerance limits in the system parameters, in the types Linked M

Process, Process, and Joint.

3 Restart the controller for the changes to take effect.

4 Set values to data variables, defining the linked motor group and connecting follower and master axes.

5 Use the service program to trim positions or reset follower after position error.

Limitations

There can be up to 5 follower axes. The follower axes can be configured to follow one master each, or several followers can follow one master, but the total number of follower axes cannot be more than 5.

The follower axis cannot be an ABB robot (IRB robot). The master axis can be either an additional axis or a robot axis.





2 RobotWare-OS

2.5.1 Overview

Continued

The torque follower function can only be used if the follower axis is connected to the same drive module as the master axis.

Using the torque follower functionality might reduce the number of follower axes depending on the number of axes that are available in the drive module where master axis is configured.

The RAPID instruction

IndReset

(Independent Reset) cannot be used in combination with Electronically Linked Motors.




2 RobotWare-OS

2.5.2.1 System parameters

2.5.2 Configuration

2.5.2.1 System parameters

About the system parameters

This is a brief description of each parameter used for Electronically Linked Motors.

For more information, see the respective parameter in Technical reference manual - System parameters.

Joint

These parameters belong to the topic Motion and the type Joint.

Parameter Description

Follower to Joint Specifies which master axis this axis shall follow. Refers to the parameter

Name in the type Joint. Robot axes are referred to as rob1 followed by underscore and the axis number (for example rob1_6).

Use Process Id name of the process that is called. Refers to the parameter Name in the type Process.

Lock Joint in Ipol A flag that locks the axis so it is not used in the path interpolation.

This parameter must be set to TRUE when the axis is electronically linked to another axis.

Process

These parameters belong to the topic Motion and the type Process.


Name Id name of the process.

Use Linked Motor

Process

Id name of electronically linked motor process. Refers to the parameter

Name in the type Linked M Process.

Linked M Process

These parameters belong to the topic Motion and the type Linked M Process.

Parameter

Name

Offset Adjust Delay

Time

Max Follower Offset

Max Offset Speed

Offset Speed Ratio

Description

Id name for the linked motor process.

Time delay from control on until the follower starts to follow the master.

This can be used to give the master time to stabilize before the follower starts following.

The maximum allowed difference in distance (in radians or meters) between master and follower.

If Max Follower Offset is exceeded, emergency stop is activated.

The maximum allowed difference in speed (in rad/s or m/s) between master and follower.

If Max Offset Speed is exceeded, emergency stop is activated.

Defines how large part of the Max Offset Speed that can be used to compensate for position error.





2 RobotWare-OS


Continued

Parameter

Ramp Time

Description

Time for acceleration up to Max Offset Speed.

The proportion constant for position regulation is ramped from zero up to its final value (Master Follower kp) during Ramp Time.

Master Follower kp

Torque follower

Torque distribution

The proportion constant for position regulation. Determines how fast the position error is compensated.

Set to True if the follower and master should share torque instead of regulating on exact position.

This can only be used if the follower axis is connected to the same drive module as the master axis.

The ratio (of the total torque) that should be applied to the follower

(for example 0.3 result in 30% on follower and 70% on master). If drive and motors are equal this is normally set to 0.5.

Follower axis pos. acc.

reduction

This value is set to reduce the accuracy of the follower position loop. This is needed in cases where the mechanical structure gives high torques between the motors due to large position mismatch in a stiff mechanical connection etc.

• 0: accuracy reduction not active

• 10-30 typical values




2 RobotWare-OS

2.5.2.2 Configuration example

2.5.2.2 Configuration example

About this example

This is an example of how to configure the additional axis M8DM1 to be a follower to the axis M7DM1 and axis M9DM1 to be a follower to robot axis 6.

Joint

Name

M7DM1

M8DM1

M9DM1

Follower to Joint

M7DM1 rob1_6

Use Process

ELM_1

ELM_2

Lock Joint in Ipol

True

True

Process

Name

ELM_1

ELM_2

Use Linked Motor Process

Linked_m_1

Linked_m_2

Linked M Process

Name

Linked_m_1

Linked_m_2

Offset Adjust

Delay Time

0.2

0.1

Max Follower Offset

Max Offset

Speed

Offset

Speed Ratio

Ramp

Time

0.05

0.1

0.05

0.1

0.33

0.4

1

1.5

Master Follower kp

0.05

0.08




61

2 RobotWare-OS

2.5.3.1 Using the service program

2.5.3 Managing a follower axis

2.5.3.1 Using the service program

About the service program

The service program is used when you need to:

• calibrate the follower axis

• reset follower after a position error

• tune a torque follower axis, see

Tuning a torque follower on page 66 .

Data variables

At start up the service routine will read values from system parameters and set the values for a set of data variables used by the service routine. These variables only need to be set manually if something goes wrong, see

Data setup on page 69 .

Start service program

Note

4

5

The controller must be in manual or auto mode to run this service program.

2

3

Step

1

Action

In the program view, tap Debug and select Call Routine....

Select Linked_m and tap Go to.

Press the RUN button to start the service program.

The service program is shown on the screen.

Tap Menu 1.

The follower axes that are set up in the system are shown in the task bar.

Tap the follower axis you want to use the service program for.

The main menu of the service program is now shown.

Menu buttons

Button

AUTO

Description

Automatically moves the follower axis to the position corresponding to the master axis, see

Reset follower automatically on page 65 .

STOP

JOG

Stops the movement of the follower axis. Can be used when jogging or using

AUTO and the movement must be stopped immediately.

Manual stepwise movement of the follower axis, see

Jog follower axis on page 63 .

If the follower axis is synchronized with the master axis, it will resume its position when you tap AUTO or when you exit the service program.

UNSYNC Used to suspend the synchronization between follower axis and master axis, see

Unsynchronize on page 63

.

HELP Show some help for how to use the service program. The button Next shows the next help subject.




2 RobotWare-OS

2.5.3.2 Calibrate follower axis position

2.5.3.2 Calibrate follower axis position

Overview

Before the follower axis can follow the master axis, you must define the calibration positions for both master and follower.

Master axis calibrate position

Follower position

Desired follower position en0400000963

This calibration is done by following the procedures below:

1 Jog the master axis to its calibration position.

2 Unsynchronize the follower and master axes. See

Unsynchronize on page 63 .

3 Jog the follower to the desired position. See

Jog follower axis on page 63 .

4 Fine calibrate follower axis. See

Fine calibrate on page 64

.

Unsynchronize

2

3

Step

1

Action

In the main menu of the service program, tap UNSYNC.

Confirm that you want to unsynchronize the axes by tapping YES.

Restart the controller when an information text tells you to do it.

After the restart the follower axis is no longer synchronized with the master axis.

Jog follower axis

2

3

Step

1

4

Action

In the main menu of the service program, tap JOG.

Select the speed with which the follower axis should move when you jog it.

Select the step size with which the follower axis should move for each step you jog it.

Tap on Positive or Negative, depending on in which direction you want to move the follower axis.

Jog the follower axis until it is exactly in the calibration position (the position that corresponds to the master axis calibration position).





2 RobotWare-OS

2.5.3.2 Calibrate follower axis position

Continued

Fine calibrate

5

6

3

4

7

Step

1

2

Action

In the ABB menu, select Calibration.

Select the mechanical unit that the follower axis belongs to.

Tap the button Calib. Parameters.

Tap Fine Calibration....

In the warning dialog that appears, tap Yes.

Select the axis that is used as follower axis and tap Calibrate.

In the warning dialog that appears, tap Calibrate.

The follower axis is now calibrated. As soon as the follower is calibrated, it is also synchronized with the master again.




2 RobotWare-OS

2.5.3.3 Reset follower axis

2.5.3.3 Reset follower axis

Overview

If the follower offset exceeds its tolerance limits (configured with the system parameter Max follower offset), the service program must be used to move the follower back within the tolerance limits. This can be done automatically in the service program if the follower is within the AUTO range. Otherwise the follower must be manually jogged.

The range where AUTO can be used is determined by the system parameter Max

Follower Offset multiplied with the data variable offset_ratio

.

Range where AUTO in service program can be used

Range where follower automatically follow master

Desired follower position

Master axis position

Max Follower

Offset

Max Follower Offset * offset_ratio

en0400000962

Reset follower automatically

Step

1

2

Action

In the main menu of the service program, tap AUTO.

Select the speed with which the follower axis should move to its desired position.

Reset follower by manual jogging

Step

1

2

3

4

Action

In the main menu of the service program, tap JOG.

Select the speed with which the follower axis should move when you jog it.

Select the step size with which the follower axis should move for each step you jog it.

Tap on Positive or Negative, depending on which direction you want to move the follower axis.

Jog the follower until it is within the tolerance of Max Follower Offset (or use AUTO when you are close enough).




65

2 RobotWare-OS

2.5.4.1 Torque follower descriptions

2.5.4 Tuning a torque follower

2.5.4.1 Torque follower descriptions

About torque followers

The follower axis can be setup so the torque is shared between the master and the follower. This is only allowed if the follower axis is connected to the same drive module as the master axis.

Below is a simplified picture of the control loop of the follower axis.

en0900000679

Torque distribution

The sharing of torque will be done on the integral part of the control loops. By setting torque distribution to 0.5, the master and follower will have equal part of the integral part of the total torque. A value of 0.3 will make the follower axis have

30% of the integral torque and the master axis 70%.

Position accuracy reduction

If the mechanical structure is very stiff and has a mechanical misalignment or a large backlash, the proportional part will be a major part of the total torque. If this becomes a problem with too high torque difference between the master and the follower the position accuracy reduction function (PAR in the illustration) can be used. This will make the follower axis less accurate when it comes in to a position.

This will make the follower act more like a true torque follower.

Test signals that can be useful to check the behavior of this is:

Test signal

Integral part of torque

Proportional part of torque

Total torque ref (also including any feed forward torque)

Test signal number

37

36

9




2 RobotWare-OS


2.5.4.2 Using the service program

About the service program for torque follower

The part of the service program for torque follower is used to find the suitable values of some parameters. Once the values are found, system parameters are updated and a new fine calibration is made. After that, there is no need for any tuning of the torque follower.

Opening the tune torque follower menu

1

2

3

4

Action

Start the service program (as described by the first steps in

Start service program on page 62 .

Tap Menu 2.

Illustration

Tap on the name of the follower axis to tune.

Use the tune torque follower menu as described below.

Tuning the torque distribution

Use this procedure to change the distribution of torque between the master and the follower axis.

1

2

3

Action

Tap Torque distribution.

Type a number (between 0 and 1) for the follower’s share of the total torque.

For example, 0.3 will result in 30% of the torque on the follower and 70% on the master.

To update the system parameters using the new value, tap Store to cfg.

If not saved to cfg, the new value will be used until the robot controller is restarted, but the value will be lost at restart.

Illustration

Tuning the position accuracy reduction

Use this procedure to set the position accuracy reduction of the torque follower axis.

1

2

Action

Tap Position accuracy reduction.

Type a number for reduced position accuracy.

0 means no position accuracy reduction.

10 -30 is typically used for a torque follower to reduce the torque tension between the master and the follower.

Illustration





2 RobotWare-OS


Continued

3

Action

To update the system parameters using the new value, tap Store to cfg.

If not saved to cfg, the new value will be used until the robot controller is restarted, but the value will be lost at restart.

Illustration

Tuning the temporary position delta

Use this procedure to tune the position delta of the torque follower axis. This delta value is then used to adjust the fine calibration of the follower axis.

1

2

3

Action

Tap Temp. position delta.

Type a number (degrees on motor side) that will be added to the position reference for the follower axis.

Test which value results in the lowest torque tension and make a fine calibration of the master axis. This will update the follower axis with the current position delta.

Illustration




2 RobotWare-OS

2.5.5.1 Set up data for service program

2.5.5 Data setup

2.5.5.1 Set up data for service program

Overview

At start of the service routine for Electronically Linked Motors, some data variables are read from the linked motor configuration. These variables are used by the service program. If they are not read correctly, the variables need to be edited in the service program.

Data descriptions

Data variable

l_f_axis_name l_f_mecunt_n l_f_axis_no l_m_mecunt_n l_m_axis_no offset_ratio speed_ratio

Description

A name for the follower axis that will be displayed on the FlexPendant.

String array with 5 elements, one for each follower axis. If you only have one linked motor, use only the first element.

The name of the mechanical unit for the follower axis. Refers to the system parameter Name in the type Mechanical Unit.

String array with 5 elements, one for each follower axis. If you only have one linked motor, use only the first element.

Defines which axis in the mechanical unit (l_f_mecunt_n) is the follower axis.

Num array with 5 elements, one for each follower axis. If you only have one linked motor, use only the first element.

The name of the mechanical unit for the master axis. Refers to the system parameter Name in the type Mechanical Unit.

String array with 5 elements, one for each master axis. If you only have one linked motor, use only the first element.

Defines which axis in the mechanical unit ( l_m_mecunt_n

) is the master axis.

Num array with 5 elements, one for each master axis. If you only have one linked motor, use only the first element.

Defines the range where the AUTO function in the service program reset the follower axis.

offset_ratio defines this range as a multiple of the range where the follower automatically follow the master (defined with the parameter Max Follow Offset).

If the follower has a position error that is larger than Max Follower Offset

* offset_ratio

, the follower must be reset manually. For more information, see

Reset follower axis on page 65

.

Defines the speed of the follower axis when controlled by the service program. The values are given as a part of the maximum allowed manual speed (that is, the value 0.5 means half the max manual speed).

Num array with 20 elements. Elements 1-5 define the speed "very slow" for each follower axis. Elements 6-10 define "slow", elements 11-15 define

"normal" and elements 16-20 define "fast". If you only have one linked motor, use only elements 1, 6, 11 and 16.





69

2 RobotWare-OS

2.5.5.1 Set up data for service program

Continued

Data variable

displacement

Description

Defines the distance the follower axis will move for each tap on Positive or Negative when jogging the follower axis from the service program. The values are given in degrees or meters, depending on if the follower axis is circular or linear.

Num array with 20 elements. Elements 1-5 define the displacement "very short" for each follower axis. Elements 6-10 define "short", elements 11-

15 define "normal" and elements 16-20 define "long". If you only have one linked motor, use only elements 1, 6, 11 and 16.

Edit data variables

2

3

4

Step

1

7

8

5

6

9

This is a description of how to set values for the data variables from the

FlexPendant.

Action

In the ABB menu, select Program Data.

Select string and tap Show Data.

Select l_f_axis_name and tap Edit Value.

Tap the first element.

Tap the line to edit it.

Enter the name you want to give your first follower axis.

If you have more than one follower axis, repeat step 4-6 for the next elements.

Repeat step 3-7 for l_f_mecunt_n and l_m_mecunt_n.

In the Program Data menu, select num and repeat step 3-7 for l_f_axis_no,

l_m_axis_no, offset_ratio, speed_ratio and displacement.




2 RobotWare-OS

2.5.5.2 Example of data setup

2.5.5.2 Example of data setup

About this example

This is an example of how to set up the data variables for two follower axis. The first follower axis is M8C1B1, which is a follower to the additional axis M7C1B1.

The second follower axis is M9C1B1, which is a follower to robot axis 6.

l_f_axis_name

Represented axis

Follower 1

Follower 2

Follower 3

Follower 4

Follower 5

Element and value in l_f_axis_name

{1}: "follow_external"

{2}: "follow_axis6"

{3}: ""

{4}: ""

{5}: ""

l_f_mecunt_n


Follower 1

Follower 2

Follower 3

Follower 4

Follower 5

Element and value in l_f_mecunt_n

{1}: "M8DM1"

{2}: "M9DM1"

{3}: ""

{4}: ""

{5}: ""

l_f_axis_no


Follower 1

Follower 2

Follower 3

Follower 4

Follower 5

Element and value in l_f_axis_no

{1}: 1

{2}: 1

{3}: 0

{4}: 0

{5}: 0

l_m_mecunt_n


Master 1

Master 2

Master 3

Master 4

Master 5

Element and value in l_m_mecunt_n

{1}: "M7DM1"

{2}: "rob1"

{3}: ""

{4}: ""

{5}: ""





2 RobotWare-OS

2.5.5.2 Example of data setup

Continued

l_m_axis_no


Master 1

Master 2

Master 3

Master 4

Master 5

Element and value in l_m_axis_no

{1}: 1

{2}: 6

{3}: 0

{4}: 0

{5}: 0

offset_ratio


Follower 1

Follower 2

Follower 3

Follower 4

Follower 5

Element and value in offset_ratio

{1}: 10

{2}: 15

{3}: 0

{4}: 0

{5}: 0

speed_ratio


Follower 1

Follower 2

Follower 3

Follower 4

Follower 5

very slow

{1}: 0.01

{2}: 0.01

{3}: 0

{4}: 0

{5}: 0

slow

{6}: 0.05

{7}: 0.05

{8}: 0

{9}: 0

{10}: 0

normal

{11}: 0.2

{12}: 0.2

{13}: 0

{14}: 0

{15}: 0

displacement


Follower 1

Follower 2

Follower 3

Follower 4

Follower 5

very short

{1}: 0.001

{2}: 0.01

{3}: 0

{4}: 0

{5}: 0

short

{6}: 0.005

{7}: 0.1

{8}: 0

{9}: 0

{10}: 0

normal

{11}: 0.02

{12}: 1

{13}: 0

{14}: 0

{15}: 0

long

{16}: 0.1

{17}: 10

{18}: 0

{19}: 0

{20}: 0

fast

{16}: 1

{17}: 1

{18}: 0

{19}: 0

{20}: 0




2 RobotWare-OS

2.6.1 Overview

2.6 Fixed Position Events

2.6.1 Overview

Purpose

The purpose of Fixed Position Events is to make sure a program routine is executed when the position of the TCP is well defined.

If a move instruction is called with the zone argument set to fine

, the next routine is always executed once the TCP has reached its target. If a move instruction is called with the zone argument set to a distance (for example z20

), the next routine may be executed before the TCP is even close to the target. This is because there is always a delay between the execution of RAPID instructions and the robot movements.

Calling the move instruction with zone set to fine will slow down the movements.

With Fixed Position Events, a routine can be executed when the TCP is at a specified position anywhere on the TCP path without slowing down the movement.


The RobotWare base functionality Fixed Position Events gives you access to:

• instructions used to define a position event

• instructions for moving the robot and executing the position event at the same time

• instructions for moving the robot and calling a procedure while passing the target, without first defining a position event

Basic approach

Fixed Position Events can either be used with one simplified instruction calling a procedure or it can be set up following these general steps. For more detailed examples of how this is done, see

Code examples on page 77 .

1 Declare the position event.

2 Define the position event:

• when it shall occur, compared to the target position

• what it shall do

3 Call a move instruction that uses the position event. When the TCP is as close to the target as defined, the event will occur.




73

2 RobotWare-OS

2.6.2 RAPID components and system parameters

2.6.2 RAPID components and system parameters

Data types

This is a brief description of each data type in Fixed Position Events. For more information, see the respective data type in Technical reference manual - RAPID


Data type

triggdata triggios triggiosdnum triggstrgo

Description

triggdata is used to store data about a position event.

A position event can take the form of setting an output signal or running an interrupt routine at a specific position along the movement path of the robot.

triggdata also contains information on when the action shall occur, for example when the TCP is at a defined distance from the target.

triggdata is a non-value data type.

triggios is used to store data about a position event used by the instruction

TriggLIOs

.

triggios sets the value of an output signal using a num value.

triggiosdnum is used to store data about a position event used by the instruction

TriggLIOs

.

triggiosdnum sets the value of an output signal using a dnum value.

triggstrgo is used to store data about a position event used by the instruction

TriggLIOs

.

triggstrgo sets the value of an output signal using a stringdig value (string containing a number).

Instructions

This is a brief description of each instruction in Fixed Position Events. For more information, see the respective instruction in Technical reference manual - RAPID


Instruction

TriggIO

TriggEquip

TriggInt

Description

TriggIO defines the setting of an output signal and when to set that signal. The definition is stored in a variable of type triggdata

.

TriggIO can define the setting of the signal to occur at a certain distance (in mm) from the target, or a certain time from the target. It is also possible to set the signal at a defined distance or time from the starting position.

By setting the distance to 0 (zero), the signal will be set when the TCP is as close to the target as it gets (the middle of the corner path).

TriggEquip works like

TriggIO

, with the difference that

TriggEquip can compensate for the internal delay of the external equipment.

For example, the signal to a glue gun must be set a short time before the glue is pressed out and the gluing begins.

TriggInt defines when to run an interrupt routine. The definition is stored in a variable of type triggdata

.

TriggInt defines at what distance (in mm) from the target (or from the starting position) the interrupt routine shall be called. By setting the distance to 0 (zero), the interrupt will occur when the TCP is as close to the target as it gets (the middle of the corner path).





Functions

2 RobotWare-OS


Continued

Instruction

TriggCheckIO

TriggRampAO

TriggL

TriggC

TriggJ

TriggLIOs

MoveLSync

MoveCSync

MoveJSync

Description

TriggCheckIO defines a test of an input or output signal, and when to perform that test. The definition is stored in a variable of type triggdata

.

TriggCheckIO defines a test, comparing an input or output signal with a value. If the test fails, an interrupt routine is called. As an option the robot movement can be stopped when the interrupt occurs.

TriggCheckIO can define the test to occur at a certain distance (in mm) from the target, or a certain time from the target. It is also possible to perform the test at a defined distance or time from the starting position.

By setting the distance to 0 (zero), the interrupt routine will be called when the TCP is as close to the target as it gets (the middle of the corner path).

TriggRampAO defines the ramping up or down of an analog output signal and when this ramping is performed. The definition is stored in a variable of type triggdata

.

TriggRampIO defines where the ramping of the signal is to start and the length of the ramping.

TriggL is a move instruction, similar to

MoveL

. In addition to the movement the

TriggL instruction can set output signals, run interrupt routines and check input or output signals at fixed positions.

TriggL executes up to 8 position events stored as triggdata

. These must be defined before calling

TriggL

.

TriggC is a move instruction, similar to

MoveC


TriggC instruction can set output signals, run interrupt routines and check input or output signals at fixed positions.

TriggC executes up to 8 position events stored as triggdata


TriggC

.

TriggJ is a move instruction, similar to

MoveJ


TriggJ instruction can set output signals, run interrupt routines and check input or output signals at fixed positions.

TriggJ executes up to 8 position events stored as triggdata


TriggJ

.

TriggLIOs is a move instruction, similar to

MoveL


TriggLIOs instruction can set output signals at fixed positions.

TriggLIOs is similar to the combination of

TriggEquip and

TriggL

.

The difference is that

TriggLIOs can handle up to 50 position events stored as an array of datatype triggios

, triggiosdnum

, or triggstrgo

.

MoveLSync is a linear move instruction that calls a procedure in the middle of the corner path.

MoveCSync is a circular move instruction that calls a procedure in the middle of the corner path.

MoveJSync is a joint move instruction that calls a procedure in the middle of the corner path.

Fixed Position Events includes no RAPID functions.





75

2 RobotWare-OS


Continued


This is a brief description of each parameter in Fixed Position Events. For more information, see the respective parameter in Technical reference manual - System parameters.

Parameter

Event Preset Time

Description

TriggEquip takes advantage of the delay between the RAPID execution and the robot movement, which is about 70 ms. If the delay of the equipment is longer than 70 ms, then the delay of the robot movement can be increased by configuring Event preset time.

Event preset time belongs to the type Motion System in the topic

Motion.




2 RobotWare-OS

2.6.3 Code examples

2.6.3 Code examples

Example without Fixed Position Events

Without the use of Fixed Position Events, the code can look like this:

MoveJ p1, vmax, fine, tool1;


SetDO do1, 1;

MoveL p3, v1000, fine, tool1;

Result

The code specifies that the TCP should reach p2 before setting do1

. Because the robot path is delayed compared to instruction execution, do1 is set when the TCP is at the position marked with X (see illustration).

xx0300000151

Example with TriggIO and TriggL instructions

Setting the output signal 30 mm from the target can be arranged by defining the position event and then moving the robot while the system is executing the position event.

VAR triggdata do_set;

!Define that do1 shall be set when 30 mm from target

TriggIO do_set, 30 \DOp:=do1, 1;


!Move to p2 and let system execute do_set

TriggL p2, v1000, do_set, z20, tool1;






77

2 RobotWare-OS

2.6.3 Code examples

Continued

Result

The signal do1 will be set when the TCP is 30 mm from p2

.

do1 is set when the

TCP is at the position marked with X (see illustration).

xx0300000158

Example with MoveLSync instruction

Calling a procedure when the robot path is as close to the target as possible can be done with one instruction call.


!Move to p2 while calling a procedure

MoveLSync p2, v1000, z20, tool1, "proc1";


Result

The procedure will be called when the TCP is at the position marked with X (see illustration).

xx0300000165




2 RobotWare-OS

2.7.1 Introduction to File and Serial Channel Handling

2.7 File and Serial Channel Handling

2.7.1 Introduction to File and Serial Channel Handling

About File and Serial Channel Handling

The RobotWare base functionality File and Serial Channel Handling gives the robot programmer control of files, fieldbuses, and serial channels from the RAPID code.

This can, for example, be useful for:

• Reading from a bar code reader.

• Writing production statistics to a log file or to a printer.

• Transferring data between the robot and a PC.

The functionality included in File and Serial Channel Handling can be divided into groups:

Functionality group Description

Binary and character based communication

Basic communication functionality. Communication with binary or character based files or serial channels.

Raw data communication

File and directory management

Data packed in a container. Especially intended for fieldbus communication.

Browsing and editing of file structures.




79

2 RobotWare-OS

2.7.2.1 Overview

2.7.2 Binary and character based communication


Purpose

The purpose of binary and character based communication is to:

• store information in a remote memory or on a remote disk

• let the robot communicate with other devices


To handle binary and character based communication, the RobotWare base functionality File and Serial Channel Handling gives you access to:

• instructions for manipulations of a file or serial channel

• instructions for writing to file or serial channel

• instruction for reading from file or serial channel

• functions for reading from file or serial channel.

Basic approach

This is the general approach for using binary and character based communication.

For a more detailed example of how this is done, see


1 Open a file or serial channel.

2 Read or write to the file or serial channel.

3 Close the file or serial channel.

Limitations

Access to files, serial channels and field busses cannot be performed from different

RAPID tasks simultaneously. Such an access is performed by all instruction in binary and character based communication, as well as

WriteRawBytes and

ReadRawBytes

. E.g. if a

ReadBin instruction is executed in one task, it must be ready before a

WriteRawBytes can execute in another task.




2 RobotWare-OS



Data types

This is a brief description of each data type used for binary and character based communication. For more information, see the respective data type in Technical reference manual - RAPID Instructions, Functions and Data types.

Data type

iodev

Description

iodev contains a reference to a file or serial channel. It can be linked to the physical unit with the instruction

Open and then used for reading and writing.

Instructions

This is a brief description of each instruction used for binary and character based communication. For more information, see the respective instruction in Technical reference manual - RAPID Instructions, Functions and Data types.

Instruction

Open

Close

Rewind

ClearIOBuff

Write

WriteBin

WriteStrBin

WriteAnyBin

ReadAnyBin

Description

Open is used to open a file or serial channel for reading or writing.

Close is used to close a file or serial channel.

Rewind sets the file position to the beginning of the file.

ClearIOBuff is used to clear the input buffer of a serial channel. All buffered characters from the input serial channel are discarded.

Write is used to write to a character based file or serial channel.

WriteBin is used to write a number of bytes to a binary serial channel or file.

WriteStrBin is used to write a string to a binary serial channel or file.

WriteAnyBin is used to write any type of data to a binary serial channel or file.

ReadAnyBin is used to read any type of data from a binary serial channel or file.

Functions

This is a brief description of each function used for binary and character based communication. For more information, see the respective instruction in Technical reference manual - RAPID Instructions, Functions and Data types.

Function

ReadNum

ReadStr

Description

ReadNum is used to read a number from a character based file or serial channel.

ReadStr is used to read a string from a character based file or serial channel.

ReadBin ReadBin is used to read a byte (8 bits) from a file or serial channel. This function works on both binary and character based files or serial channels.

ReadStrBin ReadStrBin is used to read a string from a binary serial channel or file.




81

2 RobotWare-OS

2.7.2.3 Code examples

2.7.2.3 Code examples

Communication with character based file

This example show writing and reading to and from a character based file. The line

"The number is :8" is written to FILE1.DOC. The contents of FILE1.DOC is then read and the output to the FlexPendant is "The number is :8" followed by "The number is 8".

PROC write_to_file()

VAR iodev file;

VAR num number:= 8;

Open "HOME:" \File:= "FILE1.DOC", file;

Write file, "The number is :"\Num:=number;

Close file;

ENDPROC

PROC read_from_file()

VAR iodev file;

VAR num number;

VAR string text;

Open "HOME:" \File:= "FILE1.DOC", file \Read;

TPWrite ReadStr(file);

Rewind file; text := ReadStr(file\Delim:=":"); number := ReadNum(file);

Close file;

TPWrite text \Num:=number;

ENDPROC

Communication with binary serial channel

In this example, the string "Hello", the current robot position and the string "Hi" is written to the binary serial channel com1.

PROC write_bin_chan()

VAR iodev channel;

VAR num out_buffer{20};

VAR num input;

VAR robtarget target;

Open "com1:", channel\Bin;

! Write control character enq out_buffer{1} := 5;

WriteBin channel, out_buffer, 1;

! Wait for control character ack input := ReadBin (channel \Time:= 0.1);

IF input = 6 THEN

! Write "Hello" followed by new line

WriteStrBin channel, "Hello\0A";





2 RobotWare-OS


Continued

! Write current robot position target := CRobT(\Tool:= tool1\WObj:= wobj1);

WriteAnyBin channel, target;

! Set start text character (2=start text) out_buffer{1} := 2;

! Set character "H" (72="H") out_buffer{2} := 72;

! Set character "i" out_buffer{3} := StrToByte("i"\Char);

! Set new line character (10=new line) out_buffer{4} := 10;

! Set end text character (3=end text) out_buffer{5} := 3;

! Write the buffer with the line "Hi"

! to the channel

WriteBin channel, out_buffer, 5;

ENDIF

Close channel;

ENDPROC




83

2 RobotWare-OS

2.7.3.1 Overview

2.7.3 Raw data communication


Purpose


To handle raw data communication, the RobotWare base functionality File and

Serial Channel Handling gives you access to:

• instructions used for handling the contents of a rawbytes variable

• instructions for reading and writing raw data

• a function to get the valid data length of a rawbytes variable.

Basic approach

The purpose of raw data communication is to pack different type of data into a container and send it to a file or serial channel, and to read and unpack data. This is particularly useful when communicating via a fieldbus, such as DeviceNet or

Profibus.

This is the general approach for raw data communication. For a more detailed example of how this is done, see

Write and read rawbytes on page 86 .

1 Pack data into a rawbytes variable (data of type num

, byte or string

).

2 Write the rawbytes variable to a file or serial channel.

3 Read a rawbytes variable from a file or serial channel.

4 Unpack the rawbytes variable to num

, byte or string

.

Limitations

Device command communication also require the base functionality Device

Command Interface and the option for the industrial network in question.

Access to files, serial channels and field busses cannot be performed from different

RAPID tasks simultaneously. Such an access is performed by all instruction in binary and character based communication, as well as

WriteRawBytes and

ReadRawBytes

. For example, if a

ReadBin instruction is executed in one task, then it must be ready before a

WriteRawBytes instruction can execute in another task.




2 RobotWare-OS



Data types

This is a brief description of each data type used for raw data communication. For more information, see the respective data type in Technical reference manual - RAPID Instructions, Functions and Data types.

Data type

rawbytes

Description

rawbytes is used as a general data container. It can be filled with any data of type num

, byte

, or string

. It also store the length of the valid data (in bytes).

rawbytes can contain up to 1024 bytes of data. The supported data formats are:

• Hex (1 byte)

• long (4 bytes)

• float (4 bytes)

• ASCII (1-80 characters)

Instructions

This is a brief description of each instruction used for raw data communication.


Instruction

ClearRawBytes

PackRawBytes

Description

ClearRawBytes is used to set all the contents of a rawbytes variable to 0. The length of the valid data in the rawbytes variable is set to 0.

ClearRawBytes can also be used to clear only the last part of a rawbytes variable.

PackRawBytes is used to pack the contents of variables of type num

, byte or string into a variable of type rawbytes

.

UnpackRawBytes UnpackRawBytes is used to unpack the contents of a variable of type rawbytes to variables of type byte

, num or string

.

CopyRawBytes CopyRawBytes is used to copy all or part of the contents from one rawbytes variable to another.

WriteRawBytes

ReadRawBytes

WriteRawBytes is used to write data of type rawbytes to any binary file, serial channel or fieldbus.

ReadRawBytes is used to read data of type rawbytes from any binary file, serial channel or fieldbus.

Functions

This is a brief description of each function used for raw data communication. For more information, see the respective function in Technical reference manual - RAPID


Function

RawBytesLen

Description

RawBytesLen is used to get the valid data length in a rawbytes variable.




85

2 RobotWare-OS



About the examples

These examples are simplified demonstrations of how to use rawbytes

. For a more realistic example of how to use rawbytes in DeviceNet communication, see

Write rawbytes to DeviceNet on page 94 .

Write and read rawbytes

This example shows how to pack data into a rawbytes variable and write it to a device. It also shows how to read and unpack a rawbytes variable.

VAR iodev io_device;

VAR rawbytes raw_data;

PROC write_rawbytes()

VAR num length := 0.2;

VAR string length_unit := "meters";

! Empty contents of raw_data

ClearRawBytes raw_data;

! Add contents of length as a 4 byte float

PackRawBytes length, raw_data,(RawBytesLen(raw_data)+1) \Float4;

! Add the string length_unit

PackRawBytes length_unit, raw_data,(RawBytesLen(raw_data)+1)

\ASCII;

Open "HOME:" \File:= "FILE1.DOC", io_device \Bin;

! Write the contents of raw_data to io_device

WriteRawBytes io_device, raw_data;

Close io_device;

ENDPROC

PROC read_rawbytes()

VAR string answer;

! Empty contents of raw_data

ClearRawBytes raw_data;

Open "HOME:" \File:= "FILE1.DOC", io_device \Bin;

! Read from io_device into raw_data

ReadRawBytes io_device, raw_data \Time:=1;

Close io_device;

! Unpack raw_data to the string answer





Copy rawbytes

2 RobotWare-OS


Continued

UnpackRawBytes raw_data, 1, answer \ASCII:=10;

ENDPROC

In this example, all data from raw_data_1 and raw_data_2 is copied to raw_data_3

.

VAR rawbytes raw_data_1;



VAR num my_length:=0.2;

VAR string my_unit:=" meters";

PackRawBytes my_length, raw_data_1, 1 \Float4;

PackRawBytes my_unit, raw_data_2, 1 \ASCII;

! Copy all data from raw_data_1 to raw_data_3

CopyRawBytes raw_data_1, 1, raw_data_3, 1;

! Append all data from raw_data_2 to raw_data_3

CopyRawBytes raw_data_2, 1, raw_data_3,(RawBytesLen(raw_data_3)+1);




87

2 RobotWare-OS

2.7.4.1 Overview

2.7.4 File and directory management


Purpose

The purpose of the file and directory management is to be able to browse and edit file structures (directories and files).


To handle file and directory management, the RobotWare base functionality File and Serial Channel Handling gives you access to:

• instructions for handling directories

• a function for reading directories

• instructions for handling files on a file structure level

• functions to retrieve size and type information.

Basic approach

This is the general approach for file and directory management. For more detailed examples of how this is done, see


1 Open a directory.

2 Read from the directory and search until you find what you are looking for.

3 Close the directory.




2 RobotWare-OS



Data types

This is a brief description of each data type used for file and directory management.

For more information, see the respective data type in Technical reference manual - RAPID Instructions, Functions and Data types.

Data type

dir

Description

dir contains a reference to a directory on disk or network. It can be linked to the physical directory with the instruction

OpenDir

.

Instructions

This is a brief description of each instruction used for file and directory management.


Instruction

OpenDir

CloseDir

MakeDir

RemoveDir

CopyFile

Description

OpenDir is used to open a directory.

CloseDir is used to close a directory.

MakeDir is used to create a new directory.

RemoveDir is used to remove an empty directory.

CopyFile is used to make a copy of an existing file.

RenameFile RenameFile is used to give a new name to an existing file. It can also be used to move a file from one place to another in the directory structure.

RemoveFile RemoveFile is used to remove a file.

Functions

This is a brief description of each function used for file and directory management.


Function

ReadDir

FileSize

FSSize

IsFile

Description

ReadDir is used to retrieve the name of the next file or subdirectory under a directory that has been opened with the instruction

OpenDir

.

Note that the first items read by

ReadDir are

.

(full stop character) and

..

(double full stop characters) symbolizing the current directory and its parent directory.

FileSize is used to retrieve the size (in bytes) of the specified file.

FSSize

(File System Size) is used to retrieve the size (in bytes) of the file system in which a specified file resides.

FSSize can either retrieve the total size or the free size of the system.

IsFile test if the specified file is of the specified type. It can also be used to test if the file exist at all.




89

2 RobotWare-OS



List files

This example shows how to list the files in a directory, excluding the directory itself and its parent directory (. and ..).

PROC lsdir(string dirname)

VAR dir directory;

VAR string filename;

! Check that dirname really is a directory

IF IsFile(dirname \Directory) THEN

! Open the directory

OpenDir directory, dirname;

! Loop though the files in the directory

WHILE ReadDir(directory, filename) DO

IF (filename <> "." AND filename <> ".." THEN

TPWrite filename;

ENDIF

ENDWHILE

! Close the directory

CloseDir directory;

ENDIF

ENDPROC

Move file to new directory

This is an example where a new directory is created, a file renamed and moved to the new directory and the old directory is removed.

VAR dir directory;

VAR string filename;

! Create the directory newdir

MakeDir "HOME:/newdir";

! Rename and move the file

RenameFile "HOME:/olddir/myfile", "HOME:/newdir/yourfile";

! Remove all files in olddir

OpenDir directory, "HOME:/olddir";

WHILE ReadDir(directory, filename) DO

IF (filename <> "." AND filename <> ".." THEN

RemoveFile "HOME:/olddir/" + filename;

ENDIF

ENDWHILE

CloseDir directory;

! Remove the directory olddir (which must be empty)

RemoveDir "HOME:/olddir";





Check sizes

2 RobotWare-OS


Continued

In this example, the size of the file is compared with the remaining free space on the file system. If there is enough space, the file is copied.

VAR num freefsyssize;

VAR num f_size;

! Get the size of the file f_size := FileSize("HOME:/myfile");

! Get the free size on the file system freefsyssize := FSSize("HOME:/myfile" \Free);

! Copy file if enough space free

IF f_size < freefsyssize THEN

CopyFile "HOME:/myfile", "HOME:/yourfile";

ENDIF




91

2 RobotWare-OS

2.8.1 Introduction to Device Command Interface

2.8 Device Command Interface

2.8.1 Introduction to Device Command Interface

Purpose

Device Command Interface provides an interface to communicate with I/O devices on industrial networks.

This interface is used together with raw data communication, see

Raw data communication on page 84

.


The RobotWare base functionality Device Command Interface gives you access to:

• Instruction used to create a DeviceNet header.

Basic approach

This is the general approach for using Device Command Interface. For a more detailed example of how this is done, see

Write rawbytes to DeviceNet on page 94 .

1 Add a DeviceNet header to a rawbytes variable.

2 Add the data to the rawbytes variable.

3 Write the rawbytes variable to the DeviceNet I/O.

4 Read data from the DeviceNet I/O to a rawbytes variable.

5 Extract the data from the rawbytes variable.

Limitations

Device command communication also require the base functionality File and Serial

Channel Handling and the option for the industrial network in question.

Device Command Interface is supported by the following type of industrial networks:

• DeviceNet

• EtherNet/IP




2 RobotWare-OS


2.8.2 RAPID components and system parameters

Data types

There are no RAPID data types for Device Command Interface.

Instructions

This is a brief description of each instruction in Device Command Interface. For more information, see the respective instruction in Technical reference manual - RAPID Instructions, Functions and Data types.

Instruction

PackDNHeader

Description

PackDNHeader adds a DeviceNet header to a rawbytes variable. The header specifies a service to be done (e.g. set or get) and a parameter on a DeviceNet I/O device.

Functions

There are no RAPID functions for Device Command Interface.


There are no specific system parameters in Device Command Interface. For information on system parameters in general, see Technical reference manual - System parameters.




93

2 RobotWare-OS

2.8.3 Code example


Write rawbytes to DeviceNet

In this example, data packed as a rawbytes variable is written to a DeviceNet I/O device. For more details regarding rawbytes

, see

Raw data communication on page 84 .

PROC set_filter_value()

VAR iodev dev;

VAR rawbytes rawdata_out;

VAR rawbytes rawdata_in;

VAR num input_int;

VAR byte return_status;

VAR byte return_info;

VAR byte return_errcode;

VAR byte return_errcode2;

! Empty contents of rawdata_out and rawdata_in

ClearRawBytes rawdata_out;

ClearRawBytes rawdata_in;

! Add DeviceNet header to rawdata_out with service

"SET_ATTRIBUTE_SINGLE" and path to filter attribute on

DeviceNet I/O device

PackDNHeader "10", "6,20 1D 24 01 30 64,8,1", rawdata_out;

! Add filter value to send to DeviceNet I/O device input_int:= 5;

PackRawBytes input_int, rawdata_out,(RawBytesLen(rawdata_out) +

1) \IntX := USINT;

! Open I/O device

Open "/FCI1:" \File:="board328", dev \Bin;

! Write the contents of rawdata_out to the I/O device

WriteRawBytes dev, rawdata_out \NoOfBytes :=

RawBytesLen(rawdata_out);

! Read the answer from the I/O device

ReadRawBytes dev, rawdata_in;

! Close the I/O device

Close dev;

! Unpack rawdata_in to the variable return_status

UnpackRawBytes rawdata_in, 1, return_status \Hex1;

IF return_status = 144 THEN

TPWrite "Status OK from device. Status code:

"\Num:=return_status;





2 RobotWare-OS

2.8.3 Code example

Continued

ELSE

! Unpack error codes from device answer

UnpackRawBytes rawdata_in, 2, return_errcode \Hex1;

UnpackRawBytes rawdata_in, 3, return_errcode2 \Hex1;

TPWrite "Error code from device: " \Num:=return_errcode;

TPWrite "Additional error code from device: "

\Num:=return_errcode2;

ENDIF

ENDPROC




95

2 RobotWare-OS

2.9.1 Introduction to Logical Cross Connections

2.9 Logical Cross Connections

2.9.1 Introduction to Logical Cross Connections

Purpose

The purpose of Logical Cross Connections is to check and affect combinations of digital I/O signals (DO, DI) or group I/O signals (GO, GI). This can be used to verify or control process equipment that are external to the robot. The functionality can be compared to the one of a simple PLC.

By letting the I/O system handle logical operations with I/O signals, a lot of RAPID code execution can be avoided. Logical Cross Connections can replace the process of reading I/O signal values, calculate new values and writing the values to I/O signals.


• Interrupt program execution when either of three input signals is set to 1.

• Set an output signal to 1 when both of two input signals are set to 1.

Description

Logical Cross Connections are used to define the dependencies of an I/O signal to other I/O signals. The logical operators AND, OR, and inverted signal values can be used to configure more complex dependencies.

The I/O signals that constitute the logical expression (actor I/O signals) and the

I/O signal that is the result of the expression (resultant I/O signal) can be either digital I/O signals (DO, DI) or group I/O signals (GO, GI).


Logical Cross Connections allows you to build logical expressions with up to 5 actor I/O signals and the logical operations AND, OR, and inverted signal values.




2 RobotWare-OS

2.9.2 Configuring Logical Cross Connections

2.9.2 Configuring Logical Cross Connections


This is a brief description of the parameters for cross connections. For more information, see the respective parameter in

Configuring Logical Cross Connections on page 97 .

These parameters belong to the type Cross Connection in the topic I/O System.

Parameter

Name

Resultant

Actor 1

Invert actor 1

Operator 1

Description

Specifies the name of the cross connection.

The I/O signal that receive the result of the cross connection as its new value.

The first I/O signal to be used in the evaluation of the Resultant.

If Invert actor 1 is set to Yes, then the inverted value of Actor 1 is used in the evaluation of the Resultant.

Operand between Actor 1 and Actor 2.

Can be either of the operands:

•

AND

- Results in the value 1 if both input values are 1.

•

OR

- Results in the value 1 if at least one of the input values are 1.

Note

The operators are calculated left to right (Operator 1 first and Operator 4 last).

Actor 2

Invert actor 2

Operator 2

Actor 3

Invert actor 3

Operator 3

Actor 4

Invert actor 4

Operator 4

Actor 5

Invert actor 5

The second I/O signal (if more than one) to be used in the evaluation of the

Resultant.



See Operator 1.

The third I/O signal (if more than two) to be used in the evaluation of the

Resultant.



See Operator 1.

The fourth I/O signal (if more than three) to be used in the evaluation of the

Resultant.



See Operator 1.

The fifth I/O signal (if all five are used) to be used in the evaluation of the

Resultant.





97

2 RobotWare-OS

2.9.3 Examples

2.9.3 Examples

Logical AND

The following logical structure...

Logical OR

xx0300000457

... is created as shown below.

Resultant

do26

Actor 1 Invert actor 1

di1 No

Operator 1 Actor

2

Invert actor 2

AND do2 No


3

Invert actor 3

AND do10 No


xx0300000459


Resultant

do26

Actor

1

Invert actor 1

di1 No


2

Invert actor 2

OR do2 No


3

Invert actor 3

OR do10 No

Inverted signals

The following logical structure (where a ring symbolize an inverted signal)...

xx0300000460


Resultant

do26

Actor

1

Invert actor 1

di1 Yes


2

Invert actor 2

OR do2 No


3

Invert actor 3

OR do10 Yes

Several resultants

The following logical structure can not be implemented with one cross connection...

xx0300000462





2 RobotWare-OS

2.9.3 Examples

Continued

... but with three cross connections it can be implemented as shown below.

Resultant

di17 do26 do13

Actor 1

di1 di1 di1

Invert actor 1

No

No

No

Operator 1

AND

AND

AND

Actor 2

do2 do2 do2

Invert actor 2

No

No

No

Complex conditions


xx0300000461 do11 do14 di11 do23 do17 do15 do33 do61 do54


Resultant Actor

1

Invert actor 1

di2 No di12 di13

No

No

Operator 1 Actor 2 Invert actor 2

AND do3 No

AND

AND do3 do3

Yes

No di13 di13 do11 di11 do17 do15

No

No

No

No

No

No

AND

AND

OR

AND

AND

OR do3 do3 do14 do23 do3 do33

No

No

No

No

No

Yes


3

Invert actor 3

OR di11 Yes




99

2 RobotWare-OS

2.9.4 Limitations

2.9.4 Limitations

Evaluation order

If more than two actor I/O signals are used in one cross connection, the evaluation is made from left to right. This means that the operation between Actor 1 and Actor

2 is evaluated first and the result from that is used in the operation with Actor 3.

If all operators in one cross connection are of the same type (only AND or only

OR) the evaluation order has no significance. However, mixing AND and OR operators, without considering the evaluation order, may give an unexpected result.

Tip

Use several cross connections instead of mixing AND and OR in the same cross connection.

Maximum number of actor I/O signals

A cross connection may not have more than five actor I/O signals. If more actor

I/O signals are required, use several cross connections.

Maximum number of cross connections

The maximum number of cross connections handled by the robot system is 300.

Maximum depth

The maximum allowed depth of cross connection evaluations is 20.

A resultant from one cross connection can be used as an actor in another cross connection. The resultant from that cross connection can in its turn be used as an actor in the next cross connection. However, this type of chain of dependent cross connections cannot be deeper than 20 steps.

Do not create a loop

Cross connections must not form closed chains since that would cause infinite evaluation and oscillation. A closed chain appears when cross connections are interlinked so that the chain of cross connections forms a circle.

Do not have the same resultant more than once

Ambiguous resultant I/O signals are not allowed since the outcome would depend on the order of evaluation (which cannot be controlled). Ambiguous resultant I/O signals occur when the same I/O signal is resultant in several cross connections.

Overlapping device maps

The resultant I/O signal in a cross connection must not have an overlapping device map with any inverted actor I/O signals defined in the cross connection. Using I/O signals with overlapping device map in a cross connection can cause infinity signal setting loops.




2 RobotWare-OS

2.10.1 Overview

2.10 Remote Service Embedded

2.10.1 Overview

Description

Remote Service is a functionality available for ABB robot controllers that connects to ABB Remote Service Centre on the cloud.

Earlier the Remote Service functionality had been implemented on an external hardware (Remote Service Box) connected to the Service port of the controller.

Remote Service Box had provided service data collection and the external connectivity (Wireless GPRS, 3G, or wired).

Remote Service Embedded or RSE is the software version of Remote Service inside RobotWare.

Purpose

The primary purpose of Remote Service Embedded is to remove the need of external hardware if the robot controller are connected to Internet by the customer on its WAN port.

Remote Service Embedded is then available natively in RobotWare with the principles of plug and connect to:

• Provide internet connectivity to the controller.

• Enable and register the connected controller to Remote Service.

An ABB 3G/4G/Wifi gateway will be made available in the future to use wireless connectivity.


The RobotWare base functionality Remote Service Embedded gives you access to:

• an RSE Agent software to manage the connectivity and the Service data collection.

• System Parameters used to enable RSE and configure the connectivity.

• dedicated event logs for key events of Remote Service.

• status and information pages available in System Info.

Prerequisites

The Remote Service function requires the controller to be defined in a Remote

Service Agreement. Contact the local ABB Service to create a Remote Service

Agreement and get access to MyRobot website to perform the registration after the connection.

Note

MyRobot is the ABB website which gives access to the Service information of a

Robot Controller under a Remote Service Agreement.





2 RobotWare-OS

2.10.1 Overview

Continued

Basic workflow

Following is the basic workflow for setting up Remote Service Embedded.

1 Configure Internet connectivity to the robot controller.

2 Enable Remote Service Embedded and startup connection.

3 Register the controller through MyRobot registration page.

Once the RSE is connected and registered, the service data collection will run transparently in the background.

Note

Use System Info Remote Service pages for information and local registration.

Use MyRobot website for all Remote Service features and remote side registration

Limitations

Following are the limitations of Remote Service Embedded:

• The controller identification is done using the controller serial number and must match the serial number defined in the Remote Service Agreement.

• The customer must also provide for the robot controller the connectivity to public internet or use the ABB wireless gateway when available.




2 RobotWare-OS

2.10.2 RSE connectivity

2.10.2 RSE connectivity

RSE connection concept

The concept of Remote Service Embedded is that a virtual RSE Agent is implemented inside the controller and it communicates securely with the ABB

Remote Service Centre through Internet. The communication is secured and encrypted using HTTPS (Secure HTTP) and only from the controller to ABB RSC connector to keep the customer network isolated from any external Internet access.

The following figure describes these concepts: xx1500003224





103

2 RobotWare-OS

2.10.2 RSE connectivity

Continued

Troubleshooting

You can verify the connectivity from the controller to the RSE server from your location. This is done by connecting a PC (instead of the controller) with the same network configuration (WAN IP/Mask, DNS, Route), and open the path to the root of the server ( https://rseprod.abb.com

) in a browser. The connectivity is validated if the DNS name has been resolved, the browser presents a page indicating the

RSE server, and secured with an ABB certificate as shown in the following figure.

xx1500003225




2 RobotWare-OS

2.10.3 Configuration - system parameters

2.10.3 Configuration - system parameters

Introduction

This section provides a brief description of system parameters used for the Remote

Service Embedded. For more information see Technical reference manual - System parameters - Remote Service Connection.

Remote Service Connection

The following parameters belong to the topic Communication and the type Remote

Service Connection. For more information, see the respective parameter in

Technical reference manual - System parameters - Remote Service Connection.

Parameter

Enabled

Connection Type

Connection Cost

Description

Enable or disable RSE. If RSE is disabled there will be no communication from the Controller.

Indicates if the communication is done on Customer Network or by using ABB Mobile Gateway Solution (to be implemented in future deliveries).

Adapt the polling rates and traffic volume to the type of connectivity available:

• Command polling (low) 1 min, (medium) 10 min, (high) 1 hour.

• Register polling (low) 10 min, (medium) 30 min, (high) 2 hour.

Proxy Used, Name,

Port

Gateway IP Address

Indicates if a proxy is required to access Internet and its name and port.

IP address of the ABB Mobile Gateway Solution if used (to come in future deliveries).

WAN configuration

The WAN IP/Mask/Gateway configuration is done in the Boot Application, Settings.

The WAN Ethernet port configuration which gives access to the Internet needs to be done on the controller. The port is defined by its IP, Mask, and possible Gateway.

For details about WAN configuration, see Hardware overview in the Application manual - EtherNet/IP Scanner/Adapter.

DNS configuration

These parameters belong to the topic Communication and the type DNS Client. A

DNS server need to be defined to resolve the name of the ABB RSE Connector

(rseprod.abb.com) to its IP address if ABB Mobile Gateway is not used. For more details, see Type DNS Client in Technical reference manual - System parameters.

IP Routing configuration

These parameters belong to the topic Communication and the type IP Routing. In some cases it is necessary to define some routing parameters to indicate which specific external device is used as a gateway to access the Internet on customer network. By default, an IP route is created based on the gateway defined on the

WAN Port. But it is possible to add a specific route if the default gateway should not be used. For more details, see Type IP Route in Technical reference manual - System parameters.




105

2 RobotWare-OS

2.10.4 RSE registration

2.10.4 RSE registration

RSE startup

The RSE startup is based on the following steps:

• (0) RSE preparation

• (1) RSE configuration

• (2) RSE connectivity

• (3) RSE registration

• (4) RSE connected and registered

When these steps are done, the RSE Agent is securely connected and identified with an ABB certificate installed in the robot controller like an external Remote

Service Box. The following figure describes these concepts: xx1500003226

RSE preparation

• Verify the controller serial number with the serial number found in the controller module cabinet.

• Verify and provide Internet connectivity to the robot controller.

• Verify that the service agreement for this controller is available with ABB

Robotics Service.

RSE configuration

• Configure the connectivity parameters.

• Enable Remote Service

RSE connectivity


106

• RSE Agent connects to the ABB Remote Service Center.




2 RobotWare-OS

2.10.4 RSE registration

Continued

• An initial registration process starts at low polling rate.

• The initial registration is incomplete and not yet fully trusted.

• A registration code is received to finalize the trust relation.

• The registration code is made available on the Remote Service registration page.

RSE registration

• The customer/ABB on site provides the controller serial number and registration code to the Remote Service Administrator for registration.

• The Remote Service Administrator validates this registration code in MyRobot on its service agreement.

• The registration trust starts and implements a client certificate in the controller.

RSE connected and registered

• The controller is connected, registered, and identified in the service agreement.

• The connection is trusted with an ABB certificate.

• Remote Service is now actively running on the robot controller.




107

2 RobotWare-OS

2.10.5 Remote Service information

2.10.5 Remote Service information

Remote Service pages

Introduction

The RSE information pages are available under System Info > Software resources

> Communication > Remote Service. The following are the 4 RSE information pages:

•

Overview

•

Server Connection

•

Registration

•

Advanced

Note

The information on a page can be refreshed by changing the page or by pressing the Refresh button. The Refresh button also forces a connection with the server if the RSE agent is waiting. (for example, wait for registration acknowledgement from MyRobot). This is useful in case of slow polling when connection cost is set to High.

Overview page

The Overview page provides a summary of the RSE status and information. If the status is not active then the other pages provide more detailed information.

Field

Enabled

Status

Description Possible values Example

Displays the value of the master configuration switch for turning the

RSE on/off.

Yes/No Yes

Displays the current status to see whether there is a need to navigate to the Server connection page or

Registration page.

"-"

Failed

Initializing

Shutdown

Registration in progress

Trying to connect

Active

Active

Serial number

Displays the identifier that is used to identify the controller in Remote

Service.

Controller Serial number

12-45678

RobotWare version

Displays the RobotWare version that is sent to the server.

RobotWare version name

6.03.0088

Restart counter

Displays the number of times the

RSE Agent been auto-restarted.

This is used to see if watchdog has restarted the RSE agent.

0-N

If not Enabled, then display: 0

Script version Displays the downloaded data collector code version.

"Data Collector

Script name"

"-"

2

0116/ROBOT-

WARE-

6.02.0000+/5196





2 RobotWare-OS


Continued

Field

Service Agreement


To verify that the controller is associated to the expected service agreement.

"Name of the service agreement"

"-"

SA_FR12_16

Customer name


"Customer Name of the service agreement"

"-"

ABB Robotics

Country

France

Refresh button


"Country of the service agreement"

"-"

On refresh, the RSE Agent replies with the current data and breaks the waiting state (if waiting) to contact the server and refreshes the information.

Server Connection page

The Server Connection page provides a summary of the RSE connectivity to the server.

Field

Status

Connection

Status

Last updated

Server name

Server IP

Server certificate name


Displays the current status to see whether there is a need to to navigate to the Server connection page or Registration page.

"-"

Failed

Initializing

Shutdown


Trying to connect

Active

Active

Displays the status of of communication with the server and the type of error.

Initializing

Server not reachable

Server not authenticated

Server error (HT-

TP xxxx)

Connected

Connected

"HH:MM:SS ago" Displays the relative time since the information on the Server connec-

tion page has been generated.

Displays the name of the server that

RSE Agent is configured with.

""

Server name rseprod.abb.com

Displays the IP address of the server and the port number used for connection. The IP address is the result of DNS name resolution done by RSE Agent.

""

Server IP

138.227.175.43

Displays the certificate name information.

""

Server name

Untrusted (Server) rseprod.abb.com





2 RobotWare-OS


Continued

Field

Server certificate issuer

Server certificate valid until

Controller time

DNS server

Refresh button

Description Possible values

Displays the name of the certificate issuer.

""

Issuer

Untrusted (Issuer)

Display the certificate date.

""

Issuer

Expired (Date)

Example

ABB issuing CA

6

Nov 21 07:09:28

2017 GMT

Displays the controller date and time details.

Displays the DNS information.

Not Available

DNS value

16-01-08

13:52:33

10.0.23.45


Registration page

The Registration page provides a summary of the RSE registration.

Field

Status

Registration

Status

Registration code

Refresh button


Displays the current status to see whether there is a need to navigate to the Server connection page or

Registration page.

"-"

Failed

Initializing

Shutdown


Trying to connect

Active

Active

Displays the registration status and code.

Register with code in MyRobot


Registered

Failed

Register with code in MyRobot

Displays the registration code. This code can be used to login to MyRobot.

"-"

Code value


456735





2 RobotWare-OS


Continued

Advanced page

The Advanced page provides advanced information about the dialog between RSE

Agent and server.

Field

Last HTTP message

Description

Displays the last message sent.

Last HTTP date

Displays the date and time when the last message was sent.

Possible values Example

Register

CheckRegister

GetLoginInfo

GetMessage

...

GetMessage

Sent hh:mm:ss ago

Last HTTP error

Next message

Last command

Refresh button

Displays the HTTP error when the last message was sent and the message ID if 4XX.

Displays the next message to send and the date to send the message.

Not Available

Error HTTP XXX

+ Message

Not Available

GetMessage in

70 seconds

Not Available Displays the last command received from server.

Not Available

Reboot

Reset

Ping

Diagnostic

...


Remote Service logs

The RSE Agent generates some event logs in the central controller event log. Event logs are generated during starting, registering, unregistering, loosing connectivity, and during other key events.

The events logs are in the range of 170XXX and are described with all the others controller event logs documentation. For more details, see Operating manual - Trouble shooting IRC5.

Force a reset of the RSE agent

It is possible to reset the RSE agent. When you reset, the RSE agent erases all its internal information including the registration information, the data collector script, and all the locally stored service information. The configuration will not be reset, but a new registration is required to reactivate the Remote Service.

Use the following procedure to reset the RSE agent:

1

Action

Tap the ABB button to display the ABB menu.

Process applications are listed in the menu.





2 RobotWare-OS


Continued

2

Action

Tap Program Editor -> Debug -> Call Routine.

Note

Tap PP to Main if Debug is disabled.

3

4

Tap RemoteServiceReset -> Go to. Press the Motors on button on the controller.

Press the Play button to execute the reset routine - > tap Reset.




3 Motion performance

3.1.1 About Absolute Accuracy


3.1 Absolute Accuracy [603-1, 603-2]

3.1.1 About Absolute Accuracy

Purpose

Absolute Accuracy is a calibration concept that ensures that the TCP accuracy in most cases is better than ±1 mm in the entire working range.

The difference between an ideal robot and a real robot can be several millimeters, resulting from mechanical tolerances and deflection in the robot structure. Absolute

Accuracy compensate for these differences, ensuring that the given coordinates coincide with the actual robot position.

Here are some examples of when this accuracy is important:

• Off-line programming with minimum touch-up.

• Exchangeability of robots

• On-line programming with accurate reorientation of tool

• Re-use of programs between applications


Every Absolute Accuracy robot is delivered with:

• compensation parameters saved on the robot’s serial measurement board

• a birth certificate representing the Absolute Accuracy measurement protocol for the calibration and verification sequence.

Recognizing an Absolute Accuracy robot

A robot with Absolute Accuracy calibration is marked with a sign on the manipulator

(close to the identification plate) that looks like this: xx0300000314

Basic approach

These are the basic steps to set up Absolute Accuracy on your robot. For a more detailed description, see

Activate Absolute Accuracy on page 117 .

1 Activate Absolute Accuracy.

2 Restart the controller.

Limitations

Absolute Accuracy works on a robot target in Cartesian coordinates, not on the individual joints. Therefore, joint based movements (e.g. MoveAbsJ) will not be affected. See

When is Absolute Accuracy being used on page 115

.






3.1.1 About Absolute Accuracy

Continued

If the robot is suspended, the Absolute Accuracy calibration must be performed when the robot is suspended. The compensation parameters differ depending on if the robot is floor mounted or suspended.





3.1.2 When is Absolute Accuracy being used

3.1.2 When is Absolute Accuracy being used

General

When Absolute Accuracy is activated the robot is used as normal, but with Absolute

Accuracy active. However, Absolute Accuracy is only used in connection with

Cartesian coordinates (i.e. robtargets). Joint based movement (i.e. jointtargets) is not affected by Absolute Accuracy.

The list below for Absolute Accuracy active defines when it is active. To further explain it is followed by some examples of when it is not active.

Absolute Accuracy active

Absolute Accuracy will be active in the following cases:

• Any motion function based on robtargets (e.g. MoveL) and ModPos on robtargets

• Reorientation jogging

• Linear jogging

• Tool definition (4, 5, 6 point tool definition, room fixed TCP, stationary tool)

• Work object definition

Absolute Accuracy not active

The following are examples of when Absolute Accuracy is not active:

• Any motion function based on a jointtarget (MoveAbsJ)

• Independent joint

• Joint based jogging

• Additional axes

• Track motion




115


3.1.3 Useful tools

3.1.3 Useful tools

Overview

The following products are recommended for operation and maintenance of

Absolute Accurate robots:

• Load Identification

• Calibration Pendulum (standard robot calibration tool)

• CalibWare (Absolute Accuracy calibration tool)

Load Identification

Absolute Accuracy calculates the robot's deflection depending on payload. It is very important to have an accurate description of the load.

Load Identification is a tool that determines the mass, center of gravity, and inertia of the payload.

For more information, see Operating manual - IRC5 with FlexPendant.

Calibration Pendulum

Calibration Pendulum is used to calibrate the robot's resolver offset. This means that the robot is in its home position (all axes angels set to zero) and the resolver angles are calibrated.

There are different recommended resolver offset calibration tools, depending on the robot model. The most commonly used is Calibration Pendulum. Information about calibration for a specific robot is found in the product manual for the respective robot, and in Operating manual - Calibration Pendulum.

Calibration Pendulum is used at initial calibration and when servicing the robot.

CalibWare

CalibWare, provided by ABB, is a tool for calibrating Absolute Accuracy. The documentation to CalibWare describes the Absolute Accuracy calibration procedure in detail.

CalibWare is used at initial calibration and when servicing the robot.





3.1.4 Configuration


Activate Absolute Accuracy

Use RobotStudio and follow these steps (see Operating manual - RobotStudio for more information):

1

2

3

4

5

6

Action

If you do not already have write access, click Request Write Access and wait for grant from the FlexPendant.

Click Configuration Editor and select Motion.

Click the type Robot.

Configure the parameter Use Robot Calibration and change the value to "r1_calib".

For a MultiMove system, repeat step 3 and 4 for each robot. Use Robot Calibration is then set to "r2_calib" for robot 2, "r3_calib" for robot 3 and "r4_calib" for robot

4.

Restart the controller for the changes to take effect.

Tip

To verify that Absolute Accuracy is active, look at the Jogging window on the

FlexPendant. When Absolute Accuracy is active, the text "Absolute Accuracy

On" is shown in the left window. In a MultiMove system, check this status for all mechanical units.

Deactivate Absolute Accuracy


1

2

3

4

5

6

Action

If you do not already have write access, click Request Write Access and wait for grant from the FlexPendant.

Click Configuration Editor and select the topic Motion.

Click the type Robot.

Configure the parameter Use Robot Calibration and change the value to "r1_uncalib".

For a MultiMove system, repeat step 3 and 4 for each robot. Use Robot Calibration is then set to "r2_uncalib" for robot 2, "r3_uncalib" for robot 3 and "r4_uncalib" for robot 4.






117


3.1.4 Configuration

Continued

Change calibration data

If you exchange the manipulator, the calibration data for the new manipulator must be loaded. This is done by copying the calibration data from the robot’s serial measurement board to the robot controller.

Use the FlexPendant and follow these steps (for more information, see Operating manual - IRC5 with FlexPendant):

4

5

6

1

2

3

7

8

9

Action

Tap the ABB menu and then Calibration.

Tap on the robot you wish to update.

Tap the tab Robot Memory.

Tap Advanced.

Tap Clear Controller Memory.

Tap Clear and then confirm by tapping Yes.

Tap Close.

Tap Update.

Tap Cabinet or robot has been exchanged and confirm by tapping Yes.





3.1.5.1 Maintenance that affect the accuracy

3.1.5 Maintenance

3.1.5.1 Maintenance that affect the accuracy

Overview

This section will focus on those maintenance activities that directly affect the accuracy of the robot, summarized as follows:

• Tool recalibration

• Motor replacement

• Wrist replacement (large robots)

• Arm replacement (lower arm, upper arm, gearbox, foot)

• Manipulator replacement

• Loss of accuracy

Tool recalibration

For information about tool recalibration, see

Tool calibration on page 135 .

Motor replacement

Replacement of all motors on small robots and motors for axes 1 through 4 on large robots (for example IRB 6700) requires a re-calibration of the corresponding resolver offset parameter using Calibration Pendulum.

For description of the calibration process, see the product manual for the respective robot.

Wrist replacement

Replacement of the wrist unit on large robots (for example IRB 6700) requires a re-calibration of the resolver offsets for axes 5 and 6 using Calibration Pendulum.

For description of the calibration process, see the product manual for the respective robot.

Arm replacement

1

2

Replacement of any of the robot arms, or other mechanical structure (excluding wrist), changes the structure of the robot to the extent that a robot recalibration is required. It is recommended that, after an arm replacement, the entire robot should be recalibrated to ensure optimal Absolute Accuracy functionality. This is typically performed with CalibWare and a separate measurement system. CalibWare can be used together with any generic 3Dmeasurement system.

For more information about the calibration process, see documentation for

CalibWare.

A summary of the calibration process is presented as follows:

Action

Replace the affected component.

Perform a resolver offset calibration for all axes. See the product manual for the respective robot.






3.1.5.1 Maintenance that affect the accuracy

Continued

3

4

5

6

7

Action

Recalibrate the TCP.

Check the accuracy by comparison to a fixed reference point in the cell.

Check the accuracy of the work objects.

Note

An update of the defined work objects will make the deviation less in positioning.

Check the accuracy of the positions in the current application.

If the accuracy still is unsatisfactory, perform an Absolute Accuracy calibration of the entire robot. See documentation for CalibWare.

Manipulator replacement

When a robot manipulator is replaced without replacing the controller cabinet, it is necessary to update the Absolute Accuracy parameters in the controller cabinet and realign the robot to the cell. The Absolute Accuracy parameters are updated by loading the replacement robot’s calibration parameters into the controller as described in

Change calibration data on page 118

. Ensure that the calibration data is loaded and that Absolute Accuracy is activated.

The alignment of the replacement robot to the cell depends on the robot alignment technique chosen at installation. If the robot mounting pins are aligned to the cell then the robot need only be placed on the pins - no further alignment is necessary.

If the robot was aligned using a robot program then it is necessary to measure the cell fixture(s) and measure the robot in several positions (for best results use the same program as the original robot). See

Measure robot alignment on page 133 .





3.1.5.2 Loss of accuracy

3.1.5.2 Loss of accuracy

Cause and action

Loss of accuracy usually occur after robot collision or large temperature variations.

It is necessary to determine the cause of the errors, and take adequate action.

If...

...then...

the tool is not properly calibrated recalibrate if the TCP has changed.

the tool load is not correctly defined run Load Identification to ensure correct mass, centre of gravity and inertia for the active tool.

the resolver offsets are no longer valid the robot’s relationship to the fixture(s) has changed the robot structure has changed

1 Check that the axis scales show that the robot stands correctly in the home position.

2 If the indicators are not aligned, move the robot to correct position and update the revolution counters.

3 If the indicators are close to aligned but not correct, re-calibrate with Calibration Pendulum.

1 Check by moving the robot to a predefined position on the fixture(s).

2 Visually assessing whether the deviation is excessive.

3 If excessive, realign robot to fixture(s).

1 Visually assess whether the robot is damaged.

2 If damaged then replace entire manipulator -or- replace affected arm(s) -or- recalibrate affected arm(s).




121


3.1.6.1 Error sources

3.1.6 Compensation theory

3.1.6.1 Error sources

Types of errors

The errors compensated for in the controller derive from the mechanical tolerances of the constituent robot parts. A subset of these are detailed in the illustration below.

Compliance errors are due to the effect of the robot’s own weight together with the weight of the current payload. These errors depend on gravity and the characteristics of the load. The compensation of these errors is most efficient if you use Load Identification (see Operating manual - IRC5 with FlexPendant).

Kinematic errors are caused by position or orientational deviations in the robot axes. These are independent of the load.

Illustration

There are several types of errors that can occur in each joint.

en0300000232





3.1.6.2 Absolute Accuracy compensation

3.1.6.2 Absolute Accuracy compensation

Introduction

Both compliance and kinematic errors are compensated for with "fake targets".

Knowing the deflection of the robot (i.e. deviation from ordered position), Absolute

Accuracy can compensate by ordering the robot to a fake target.

The compensation works on a robot target in cartesian coordinates, not on the individual joints. This means that it is the position of the TCP (marked with an arrow in the following illustrations) that is correctly compensated.

Desired position

The following illustration shows the position you want the robot to have.

xx0300000225

Position due to deflection

The following illustration shows the position the robot will get without Absolute

Accuracy. The weight of the robot arms and the load will make a deflection on the robot. Note that the deflection is exaggerated.

Fake target

xx0300000227

In order to get the desired position, Absolute Accuracy calculates a fake target.

When you enter a desired position, the system recalculates it to a fake target that after the deflection will result in the desired position.

xx0300000226





123


3.1.6.2 Absolute Accuracy compensation

Continued

Compensated position

The actual position will be the same as your desired position. As a user you will not notice the fake target or the deflection. The robot will behave as if it had no deflection.

xx0300000224





3.1.7.1 ABB calibration process

3.1.7 Preparation of Absolute Accuracy robot

3.1.7.1 ABB calibration process

Overview

This section describes the calibration process that ABB performs on each Absolute

Accuracy robot, regardless of robot type or family, before it is delivered.

The process can be divided in four steps:

1 Resolver offset calibration

2 Absolute Accuracy calibration

3 Calibration data stored on the serial measurement board

4 Absolute Accuracy verification

5 Generation of a birth certificate

Resolver offset calibration

The resolver offset calibration process is used to calibrate the resolver offset parameters.

For information on how to do this, see the product manual for the respective robot.

Absolute Accuracy calibration

The Absolute Accuracy calibration is performed on top of the resolver offset calibration, hence the importance of having repeatable methods for both processes.

Each robot is calibrated with maximum load to ensure that the correct compensation parameters are detected (calibration at lower load might not result in a correct determination of the robot flexibility parameters.) The process runs the robot to

100 jointtarget poses and measures each corresponding measurement point coordinate. The list of poses and measurements are fed into the CalibWare calibration core and a set of robot compensation parameters are created.





125


3.1.7.1 ABB calibration process

Continued

For information on how to do this, see documentation for CalibWare.

en0300000248

Absolute Accuracy verification

The parameters are loaded onto the controller and activated. The robot is then run to a set of 50 robtarget poses. Each pose is measured and the deviation from nominal determined.

For information on how to do this, see documentation for CalibWare.

The requirements for acceptance vary between robot types, but typically 90% of the poses (all non-singular) have to show an absolute deviation of less than 1 mm.

Compensation parameters and birth certificate

The compensation parameters are saved on the robot’s serial measurement board

(see

Compensation parameters on page 128

).

A birth certificate is created representing the Absolute Accuracy measurement protocol for the calibration and verification sequence (see

Birth certificate on page 127

).





3.1.7.2 Birth certificate

3.1.7.2 Birth certificate

About the birth certificate

All Absolute Accuracy robots are shipped with a birth certificate. It represents the

Absolute Accuracy measurement protocol for the calibration and verification sequence.

The birth certificate comprises the following key information:

• Robot information (robot type, serial number)

• Accuracy information (maximum, average and standard deviation for finepoint error distribution)

• Tool information (TCP, mass, center of gravity)

• Description of measurement protocol (measurement and calibration system, number of points, measurement point location)

Example of birth certificate

xx0300000230




127


3.1.7.3 Compensation parameters

3.1.7.3 Compensation parameters

About the compensation parameters

All Absolute Accuracy robots are shipped with a set of compensation parameters.

As the resolver offset calibration is integral in the Absolute Accuracy calibration, the resolver offset parameters are also stored on the robot’s serial measurement board.

The compensation parameters

The compensation parameters contains the following sections:

• ROBOT_CALIB

• ARM_CALIB

• JOINT_CALIB

• PARALLEL_ARM_CALIB

• TOOL_INTERFACE

• MOTOR_CALIB

The ROBOT_CALIB section defines the top level of the calibration structure. Default for the system is "uncalib", which results in Absolute Accuracy being deactivated.

The "r1_calib" instance activates the Absolute Accuracy functionality by specifying the "-absacc" flag. Furthermore, a tool interface is chosen, in this case "r1_tool".

Note that Absolute Accuracy must be activated manually, see

Activate Absolute

Accuracy on page 117 .

The sections ARM_CALIB, JOINT_CALIB, PARALLEL_ARM_CALIB and

MOTOR_CALIB are reserved by the system and are chosen automatically when the Absolute Accuracy functionality is activated. The parameter values can be changed by importing a new configuration file, however the keywords must remain as stated. Alteration of the keywords will result in a corrupted configuration file.

The compensation parameters can be viewed by creating a backup and reading the moc.cfg file.

Example of compensation parameters (as found in the backup moc.cfg)

MOC:CFG_1.0::

# ROBOT_CALIB - ?

ROBOT_CALIB:

-name "r1_calib"

-use_tool_interface "r1_tool" -absacc

# ARM_CALIB - ?

ARM_CALIB:

-name "rob1_1"

-error_offset_x 0.0000000 -error_offset_y 0.0000000 -error_offset_z

0.0000000 \

-error_roll 0.0000000 -error_pitch 0.0000000 -error_jaw 0.0000000

-arm_compliance_y 0.0000000

-name "rob1_2" \







Continued


0.0000000 \

-error_roll 0.0001903 -error_pitch -0.0003469 -error_jaw 0.0000000

-name "rob1_3" \


0.0005485 \

-error_roll 0.0000537 -error_pitch 0.0006959 -error_jaw 0.0003361

-arm_compliance_x 0.0000000 -arm_compliance_z 0.0000000

-name "rob1_4" \

-error_offset_x 0.0000000 -error_offset_y -0.0003586 -error_offset_z

0.0004580 \

-error_roll 0.0000965 -error_pitch 0.0000000 -error_jaw -0.0002578

-name "rob1_5" \

-error_offset_x -0.0005467 -error_offset_y 0.0000000 -error_offset_z

0.0000032 \


-name "rob1_6" \

-error_offset_x 0.0000000 -error_offset_y -0.0000449 -error_offset_z

-0.0000365 \


# JOINT_CALIB - ?

JOINT_CALIB:

-name "rob1_1" -compl 0.00000000

-name "rob1_2" -compl 0.00000004

-name "rob1_3" -compl 0.00000107

-name "rob1_4" -compl 0.00000257

-name "rob1_5" -compl 0.00000490

-name "rob1_6" -compl 0.00000941

# PARALLEL_ARM_CALIB - ?

PARALLEL_ARM_CALIB:

-name "rob1_2" -error_length 0.0004324

-name "rob1_3" -error_length -0.0000744

# TOOL_INTERFACE - ?

TOOL_INTERFACE:

-name "r1_tool" -compl 0.0 -mass 0.0 -mass_centre_x 0.0 \

-offset_x -0.0000465 -offset_y 0.0011064 -offset_z -0.0005255 \

-orient_u0 1.0 -orient_u1 0.0 -orient_u2 0.0 -orient_u3 0.0

# MOTOR_CALIB - ?

MOTOR_CALIB:

-name "rob1_1" -valid_com_offset -cal_offset 1.301100

-valid_cal_offset


-valid_cal_offset







Continued


-valid_cal_offset


-valid_cal_offset


-valid_cal_offset


-valid_cal_offset





3.1.8.1 Overview

3.1.8 Cell alignment


About cell alignment

The compensation parameters for the Absolute Accuracy robot are determined from the physical base plate to the robot tool. For many applications this is enough, the robot can be used as any other robot. However, it is common that Absolute

Accuracy robots are aligned to the coordinates in their cells. This section describes this alignment procedure. For a more detailed description, see documentation for

CalibWare.

Alignment procedure

In order for the robot to be accurate with respect to the entire robot cell, it is necessary to install the robot correctly. In summary, this involves:

1

2

3

4

Action

Measure fixture alignment

Measure robot alignment

Calculate frame relationships

Calibrate tool

Description

Determine the relationship between the measurement system and the fixture. See

Measure fixture alignment on page 132

.

Determine the relationship between the measurement system and the robot. See

Measure robot alignment on page 133

.

Determine the relationship between, for example, the robot and the fixture. See

Frame relationships on page 134 .

Determine the relationship between the robot tool and other cell components. See

Tool calibration on page 135 .

Illustration

en0300000239




131


3.1.8.2 Measure fixture alignment

3.1.8.2 Measure fixture alignment

About fixture alignment

A fixture is defined as a cell component that is associated with a particular coordinate system. The interaction between the robot and the fixture requires an accurate relationship in order to ensure Absolute Accuracy.

Absolute Accuracy fixtures must be equipped with at least three (preferably four) reference points, each with clearly marked position information.

Fixture measurement procedure

The alignment of the fixture is done in the following steps:

1 Enter the reference point names and positions into the alignment software

(e.g. CalibWare).

2 Measure the reference points and assign the same names.

3 Use the alignment software to match the reference to measured points and determine the relationship frame. All measurement systems support this form of transformation.

Illustration

en0300000237





3.1.8.3 Measure robot alignment

3.1.8.3 Measure robot alignment

Select method

The relationship between the measurement system and the robot can be determined in two separate ways:

Alignment procedure

Alignment to physical base

Description

The equivalent to the fixture alignment in which the physical base pins are measured and aligned with respect to the reference positions detailed in that particular robot’s User

Manual.

Alignment to theoretical base Measuring several robot poses and letting the alignment software determine the robot alignment.

Alignment to physical base

The advantage of aligning the robot as a fixture is in its simplicity - the robot is treated as another fixture in the cell and its base points measured accordingly.

The disadvantage is that small errors in the subsequent placement of the robot on the pins can result is large TCP errors due to the reach of the robot (i.e. the placement of the robot is not calibrated.)

In order to determine the reference point coordinates, it is necessary to consult the product manual for that robot type.

Once the correct point have been measured, the alignment software is used to determine the frame relationship between the measurement system and robot base.

Alignment to theoretical base

The advantage of aligning the robot to a theoretical base is that any errors resulting from mounting the robot can be eliminated. Furthermore, the alignment process details the robot accuracy at the measured points, confirming correct Absolute

Accuracy functionality. The disadvantage is that a robot program must be created

(either manually or automatically from CalibWare) and the robot measured (ideally with correct tool however the TCP can also be calibrated as a part of this procedure.)

Once the correct point is measured, the alignment software is used to determine the frame relationship between the measurement system and robot base.




133


3.1.8.4 Frame relationships

3.1.8.4 Frame relationships

About frame relationships

Once the relationships between the measurement system and all other cell components are measured, the relationships between cell components can be determined.

The relationship between the world coordinate system and the robot shall be stored in the robot base. The relationship between the robot and the fixture shall be stored in the workobject data type.

The measurement system is initially the active coordinate system as both world and robot are measured relative to the measurement system.

Determine robot base

Use a standard measurement system software to determine the robot base in world coordinates:

1 Set the world coordinate system to be active (the origin).

2 Read the coordinates of the robot base frame (now relative to the world).

The fixture relationship is similarly determined by setting the robot to be active and reading the coordinates of the fixture frame.





3.1.8.5 Tool calibration

3.1.8.5 Tool calibration

About tool calibration

The Absolute Accuracy robot compensation parameters are calculated to be tool independent. This allows any tool with a correctly pre-defined TCP to be connected to the robot flange and used without requiring a tool re-calibration. In practice, however, it is difficult to perform a correct TCP calibration with, for example, a

Coordinate Measurement Machine (CMM) as this does not take into account the connection of the tool to the robot nor the tool flexibility.

Each tool should be calibrated on a regular basis to ensure optimal robot accuracy.

Tool calibration procedures

Suggested tool recalibration procedures are detailed as follows:

• SBCU (Single Beam Calibration Unit) such as the ABB BullsEye for arc-welding or spot-welding applications.

• Geometry calibration such as the 4, 5 or 6 Point tool center point calibration routine available in the controller. A measurement system can be used to ensure that the single point used is accurate.

• RAPID tool calibration routines: MToolTCPCalib (calibration of TCP for moving tool), SToolTCPCalib (calibration of TCP for stationary tool), MToolRotCalib

(calibration of rotation for moving tool), SToolRotCalib (calibration of TCP and rotation for stationary tool.)

• Using theoretical data, for example from a CAD model.

Tip

As the tool load characteristics are used in the Absolute Accuracy models, it is essential that all parameters be as accurate as possible. Use of Load Identification is an efficient method of determining tool load characteristics.




135


3.2 Advanced robot motion [687-1]

3.2 Advanced robot motion [687-1]

About Advanced robot motion

The option Advanced robot motion gives you access to:

• Advanced Shape Tuning, see

Advanced Shape Tuning [included in 687-1] on page 137

.

• Changing Motion Process Mode from RAPID, see

Motion Process Mode

[included in 687-1] on page 145 .

• Wrist Move, see

Wrist Move [included in 687-1] on page 153

.





3.3.1 About Advanced Shape Tuning

3.3 Advanced Shape Tuning [included in 687-1]

3.3.1 About Advanced Shape Tuning

Purpose


Advanced Shape Tuning is included in the RobotWare option Advanced robot motion and gives you access to:

• Instructions

FricIdInit

,

FricIdEvaluate and

FricIdSetFricLevels that automatically optimize the joint friction model parameters for a programmed path.

• The system parameters Friction FFW On, Friction FFW level and Friction

FFW Ramp for manual tuning of the joint friction parameters.

• The tune types tune_fric_lev and tune_fric_ramp that can be used with the instruction

TuneServo

.

Basic approach

The purpose of Advanced Shape Tuning is to reduce the path deviation caused by joint friction of the robot.

Advanced Shape Tuning is useful for low speed cutting (10-100 mm/s) of, for example, small circles. Effects of robot joint friction can cause path deviation of typically 0.5 mm in these cases. By tuning parameters of a friction model in the controller, the path deviation can be reduced to the repeatability level of the robot, for example, 0.1 mm for a medium sized robot.

This is a brief description of how Advanced Shape Tuning is most commonly used:

1 Set system parameter Friction FFW On to TRUE. See

System parameters on page 142

.

2 Perform automatic tuning of the joint friction levels using the instructions

FricIdInit and

FricIdEvaluate

. See

Automatic friction tuning on page 138 .

3 Compensate for the friction using the instruction

FricIdSetFricLevels

.




137


3.3.2 Automatic friction tuning

3.3.2 Automatic friction tuning

About automatic friction tuning

A robot’s joint friction levels are automatically tuned with the instructions

FricIdInit and

FricIdEvaluate

. These instructions will tune each joint’s friction level for a specific sequence of movements.

The automatically tuned levels are applied for friction compensation with the instruction

FricIdSetFricLevels

.

Program execution

To perform automatic tuning for a sequence of movements, the sequence must begin with the instruction

FricIdInit and end with the instruction

FricIdEvaluate

. When program execution reaches

FricIdEvaluate

, the robot will repeat the movement sequence until the best friction level for each joint axis is found. Each iteration consists of a backward and a forward motion, both following the programmed path. Typically the sequence has to be repeated approximately

20-30 times, in order to iterate to correct joint friction levels.

If the program execution is stopped in any way while the program pointer is on the instruction

FricIdEvaluate and then restarted, the results will be invalid. After a stop, friction identification must therefore be restarted from the beginning.

Once the correct friction levels are found they have to be set with the instruction

FricIdSetFricLevels

, otherwise they will not be used. Note that the friction levels are tuned for the particular movement between

FricIdInit and

FricIdEvaluate

. For movements in another region in the robot’s working area, a new tuning is needed to obtain the correct friction levels.

For a detailed description of the instructions, see Technical reference manual - RAPID Instructions, Functions and Data types.

Limitations

There are the following limitations for friction tuning:

• Friction tuning cannot be combined with synchronized movement. That is,

SyncMoveOn is not allowed between

FricIdInit and

FricIdEvaluate

.

• The movement sequence for which friction tuning is done must begin and end with a finepoint. If not, finepoints will automatically be inserted during the tuning process.

• Automatic friction tuning works only for TCP robots.

• Automatic joint friction tuning can only be done for one robot at a time.

• Tuning can be made to a maximum of 500%. If that is not enough, set a higher value for the parameter Friction FFW Level, see

Starting with an estimated value on page 143 .

• It is not possible to view any test signals with Test Signal Viewer during automatic friction tuning.

• The movement sequence between

FricIdInit and

FricIdEvaluate cannot be longer than 10 seconds.





Example


3.3.2 Automatic friction tuning

Continued

Note

To use Advanced Shape Tuning, the parameter Friction FFW On must be set to

TRUE.

This example shows how to program a cutting instruction that encapsulates the friction tuning. When the instruction is run the first time, without calculated friction parameters, the friction tuning is done. During the tuning process, the robot will repeatedly move back and forth along the programmed path. Approximately 25 iterations are needed.

At all subsequent runs the friction levels are set to the tuned values identified in the first run. By using the instruction

CutHole

, the friction can be tuned individually for each hole.

PERS num friction_levels1{6} := [9E9,9E9,9E9,9E9,9E9,9E9];

PERS num friction_levels2{6} := [9E9,9E9,9E9,9E9,9E9,9E9];

CutHole p1,20,v50,tool1,friction_levels1;

CutHole p2,15,v50,tool1,friction_levels2;

PROC CutHole(robtarget Center, num Radius, speeddata Speed, PERS tooldata Tool, PERS num FricLevels{*})

VAR bool DoTuning := FALSE;

IF (FricLevels{1} >= 9E9) THEN

! Variable is uninitialized, do tuning

DoTuning := TRUE;

FricIdInit;

ELSE

FricIdSetFricLevels FricLevels;

ENDIF

! Execute the move sequence

MoveC p10, p20, Speed, z0, Tool;

MoveC p30, p40, Speed, z0, Tool;

IF DoTuning THEN

FricIdEvaluate FricLevels;

ENDIF

ENDPROC

Note

A real program would include deactivating the cutting equipment before the tuning phase.




139


3.3.3 Manual friction tuning

3.3.3 Manual friction tuning

Overview

It is possible to make a manual tuning of a robot's joint friction (instead of automatic friction tuning). The friction level for each joint can be tuned using the instruction

TuneServo

. How to do this is described in this section.

There is usually no need to make changes to the friction ramp.

Note

To use Advanced Shape Tuning, the parameter Friction FFW On must be set to

TRUE.

Tune types

A tune type is used as an argument to the instruction

TuneServo

. For more information, see tunetype in Technical reference manual - RAPID Instructions,


There are two tune types that are used expressly for Advanced Shape Tuning:

Tune type

TUNE_FRIC_LEV

TUNE_FRIC_RAMP

Description

By calling the instruction

TuneServo with the argument

TUNE_FRIC_LEV the friction level for a robot joint can be adjusted during program execution. A value is given in percent (between 1 and 500) of the friction level defined by the parameter Friction FFW

Level.

By calling the instruction

TuneServo with the argument

TUNE_FRIC_RAMP the motor shaft speed at which full friction compensation is reached can be adjusted during program execution. A value is given in percent (between 1 and 500) of the friction ramp defined by the parameter Friction FFW Ramp.

There is normally no need to tune the friction ramp.

Configure friction level

The friction level is set for each robot joint. Perform the following steps for one joint at a time:

1

2

3

Action

Test the robot by running it through the most demanding parts of its tasks (the most advanced shapes). If the robot shall be used for cutting, then test it by cutting with the same tool as at manufacturing.

Observe the path deviations and test if the joint friction levels need to be increased or decreased.

Tune the friction level with the RAPID instruction

TuneServo and the tune type

TUNE_FRIC_LEV

. The level is given in percent of the Friction FFW Level value.

Example: The instruction for increasing the friction level with 20% looks like this:

TuneServo MHA160R1, 1, 120 \Type:= TUNE_FRIC_LEV;

Repeat step 1 and 2 until you are satisfied with the path deviation.






3.3.3 Manual friction tuning

Continued

4

Action

The final tuning values can be transferred to the system parameters.

Example: The Friction FFW Level is 0.5 and the final tune value (

TUNE_FRIC_LEV

) is

120%. Set Friction FFW Level to 0.6 and tune value to 100% (default value), which is equivalent.

Tip

Tuning can be made to a maximum of 500%. If that is not enough, set a higher value for the parameter Friction FFW Level, see

Setting tuning system parameters on page 143 .




141



3.3.4 System parameters



This is a brief description of each parameter in Advanced Shape Tuning. For more information, see the respective parameter in Technical reference manual - System parameters.

Friction Compensation / Control Parameters

These parameters belong to the type Friction Compensation in the topic Motion, except for the robots IRB 1400 and IRB 1410 where they belong to the type Control

Parameters in the topic Motion.

Parameter

Friction FFW On

Friction FFW Level

Description

Advanced Shape Tuning is active when Friction FFW On is set to

TRUE.

Friction FFW Level is the friction level for the robot joint. See illustration below.

Friction FFW Ramp Friction FFW Ramp is the speed of the robot motor shaft, at which the friction has reached the friction level defined by Friction FFW

Level. See illustration below.

There is normally no need to make changes to Friction FFW Ramp.

Illustration

en0900000117





3.3.4.2 Setting tuning system parameters

3.3.4.2 Setting tuning system parameters

Automatic tuning rarely requires changes in system parameters

For automatic tuning, if the friction levels are saved in a persistent array, the tuning is maintained after a power failure. The automatic tuning can also be used to set different tuning levels for different robot movement sequences, which cannot be achieved with system parameters. When using automatic tuning, there is no need to change the system parameters unless the default values are very much off, see

Starting with an estimated value on page 143

.

Transfer tuning to system parameters

When using manual tuning, the tuning values are reset to default (100%) at power failure. System parameter settings are, however, permanent.

If a temporary tuning is made, that is only valid for a part of the program execution, it should not be transferred.

To transfer the friction level tuning value (

TUNE_FRIC_LEV

) to the parameter

Friction FFW Level follow these steps:

1

2

3

Action

In RobotStudio, open the Configuration Editor, Motion topic, and select the type

Friction comp (except for the robots IRB 1400 and IRB 1410 where they belong to the type Control parameters).

Multiply Friction FFW Level with the tuning value. Set this value as the new Friction

FFW Level and set the tuning value (

TUNE_FRIC_LEV

) to 100%.

Example: The Friction FFW Level is 0.5 and the final tune value (

TUNE_FRIC_LEV

) is

120%. Set Friction FFW Level to 0.6 (1.20x0.5) and the tuning value to 100% (default value), which is equivalent.


Starting with an estimated value

The parameter Friction FFW Level will be the starting value for the tuning. If this value is very far from the correct value, tuning to the correct value might be impossible. This is unlikely to happen, since Friction FFW Level is by default set to a value approximately correct for most situations.

If the Friction FFW Level value, for some reason, is too far from the correct value, it can be changed to an new estimated value.

1

2

3

Action

In RobotStudio, open the Configuration Editor, Motion topic, and select the type

Friction comp (except for the robots IRB 1400 and IRB 1410 where they belong to the type Control parameters).

Set the parameter Friction FFW Level to an estimated value. Do not set the value 0

(zero), because that will make tuning impossible.





143





This is an overview of all instructions, functions, and data types in Advanced Shape

Tuning.



Instructions

Instructions

FricIdInit

FricIdEvaluate

FricIdSetFricLevels

Description

Initiate friction identification

Evaluate friction identification

Set friction levels after friction identification

Functions

Advanced Shape Tuning includes no functions.

Data types

Advanced Shape Tuning includes no data types.





3.4.1 About Motion Process Mode

3.4 Motion Process Mode [included in 687-1]

3.4.1 About Motion Process Mode

Purpose

The purpose of Motion Process Mode is to simplify application specific tuning, i.e.

to optimize the performance of the robot for a specific application.

For most applications the default mode is the best choice.

Available motion process modes

A motion process mode consists of a specific set of tuning parameters for a robot.

Each tuning parameter set, that is each mode, optimizes the robot tuning for a specific class of applications.

There following modes are predefined:

• Optimal cycle time mode – this mode gives the shortest possible cycle time and is normally the default mode.

• Accuracy mode – this mode improves path accuracy. The cycle time will be slightly increased compared to Optimal cycle time mode. This is the recommended choice for improving path accuracy on small and medium size robots, for example IRB 2400 and IRB 2600.

• Low speed accuracy mode – this mode improves path accuracy. The cycle time will be slightly increased compared to Accuracy mode. This is the recommended choice for improving path accuracy on large size robots, for example IRB 4600.

• Low speed stiff mode - this mode is recommended for contact applications where maximum servo stiffness is important. Could also be used in some low speed applications, where a minimum of path vibrations is desired. The cycle time will be increased compared to Low speed accuracy mode.

There are also four modes available for application specific user tuning:

• MPM User mode 1 – 4

Selection of mode

The default mode is automatically selected and can be changed by changing the system parameter Use Motion Process Mode for type Robot.

Changing the Motion Process Mode from RAPID is only possible if the option

Advanced Robot Motion is installed. The mode can only be changed when the robot is standing still, otherwise a fine point is enforced.

The following example shows a typical use of the RAPID instruction

MotionProcessModeSet

.

MotionProcessModeSet OPTIMAL_CYCLE_TIME_MODE;

! Do cycle-time critical movement

MoveL *, vmax, ...;

...

MotionProcessModeSet ACCURACY_MODE;






3.4.1 About Motion Process Mode

Continued

! Do cutting with high accuracy

MoveL *, v50, ...;

...

Limitations

• The Motion Process Mode concept is currently available for all six- and seven-axes robots except paint robots.

• The Mounting Stiffness Factor parameters are only available for the following robots:

IRB 120, IRB 140, IRB 1200, IRB 1520, IRB 1600, IRB 2600, IRB 4600, IRB

6620 (not LX), IRB 6640, IRB 6700.

• For IRB 1410, only the Accset and the geometric accuracy parameters are available.

• The following robot models do not support the use of World Acc Factor (i.e.

only World Acc Factor = -1 is allowed):

IRB 340, IRB 360, IRB 540, IRB 1400, IRB 1410





3.4.2 User-defined modes

3.4.2 User-defined modes

Available tune parameters

If a more specific tuning is needed, some tuning parameters can be modified in each motion process mode. The four predefined modes and the four user modes can all be modified. In this way, the user can create a specific tuning for a specific application.

The following list contains a short description of the available tune parameters.

• Use Motion Process Mode Type - selects predefined parameters for a user mode.

• Accset Acc Factor – changes acceleration

• Accset Ramp Factor – changes acceleration ramp

• Accset Fine Point Ramp Factor – changes deceleration ramp in fine points

• Joint Acc Factor - changes acceleration for a specific joint.

• World Acc Factor - activates dynamic world acceleration limitation if positive, typical value is 1, deactivated if -1.

• Geometric Accuracy Factor - improves geometric accuracy if reduced.

• Dh Factor – changes path smoothness (effective system bandwidth)

• Df Factor – changes the predicted resonance frequency for a particular axis

• Kp Factor – changes the equivalent gain of the position controller for a particular axis

• Kv Factor – changes the equivalent gain of the speed controller for a particular axis

• Ti Factor – changes the integral time of the controller for a particular axis

• Mounting Stiffness Factor X – describes the stiffness of the robot foundation in x direction

• Mounting Stiffness Factor Y – describes the stiffness of the robot foundation in y direction

• Mounting Stiffness Factor Z – describes the stiffness of the robot foundation in z direction

For a detailed description, see Motion Process Mode in Technical reference manual - System parameters.

Tuning parameters from RAPID

Most parameters can also be changed using the

TuneServo and

AccSet instructions.

Note

All parameter settings are relative adjustments of the predefined parameter values. Although it is possible to combine the use of motion process modes and

TuneServo/Accset instructions, it is recommended to choose either motion process modes or

TuneServo/AccSet

.






3.4.2 User-defined modes

Continued

Example 1

Relative adjustment of acceleration = [Predefined AccSet Acc Factor] * [AccSet

Acc Factor] * [

AccSet

instruction acceleration factor / 100]

Example 2

Relative adjustment of Kv = [Predefined Kv Factor] * [Kv Factor] * [Tune value of

TuneServo(TYPE_KV)

instruction / 100]

Predefined parameter values

The predefined parameter values for each mode varies for different robot types.

Generally, all predefined parameters are set to 1.0 for Optimal cycle time mode.

For Low speed accuracy mode and Low speed stiff mode, the

AccSet and Dh parameters are lowered for a smoother movement and a more accurate path, and the Kv Factor, Kp Factor, and Ti Factor are changed for higher servo stiffness.

For some robots, it might not be possible to increase the Kv Factor in Low speed accuracy mode and Low speed stiff mode. Always be careful and be observant for increased motor noise level when adjusting Kv Factor and do not use higher values than needed for fulfilling the application requirement. A Kp Factor which is too high, or a Ti Factor which is too low, can also increase vibrations due to mechanical resonances.

Accuracy Mode uses a dynamic world acceleration limitation (World Acc Factor) and increased geometric accuracy (Geometric Accuracy Factor) to improve the path accuracy.

The Df Factor and the Mounting Stiffness Factors are always set to 1.0 in the predefined modes, since the optimal values of these parameters depends the specific installation, for example, the stiffness of the foundation on which the robot is mounted. These parameters can be optimized using TuneMaster. More information can be found in the TuneMaster application. Also note the limitations of Mounting Stiffness Factor.

WARNING

Incorrect setting of the Motion Process Mode parameters can cause oscillating movements or torques that can damage the robot.





3.4.3 General information about robot tuning

3.4.3 General information about robot tuning

Minimizing cycle time

For best possible cycle time, the motion process mode Optimal cycle time mode should be used. This mode is normally the default mode. The user only needs to define the tool load, payload, and arm loads if any. Once the robot path has been programmed, the ABB QuickMove motion technology automatically computes the optimal accelerations and speeds along the path. This results in a time-optimal path with the shortest possible cycle time. Hence, no tuning of acceleration is needed. The only way to improve the cycle time is to change the geometry of the path or to work in another region of the work space. This type of optimization, if needed, can be performed by simulation in RobotStudio.

Increasing path accuracy and reducing vibrations

For most applications, the Optimal cycle time mode will result in a satisfactory behavior in terms of path accuracy and vibrations. This is due to the ABB TrueMove motion technology. However, there are applications where the accuracy needs to be improved by modifying the tuning of the robot. This tuning has previously been performed by using the

TuneServo and

AccSet instructions in the RAPID program.

The concept of motion process modes will simplify this application specific tuning and the four predefined modes should be useful in many cases with no further adjustments needed.

Here follows some general advice for solving accuracy problems, assuming that the default choice Optimal cycle time mode has been tested and that accuracy problems have been noticed:

1 Verify that tool load, payload, and arm loads are properly defined.

2 Inspect tool and process equipment attached to the robot arms. Make sure that everything is properly fastened and that rigidity of the tool is adequate.

3 Inspect the foundation on which the robot is mounted, see

Compensating for foundation flexibility on page 149

.

Compensating for foundation flexibility

If the foundation does not fulfill the stiffness requirement of the robot product manual, then the foundation flexibility should be compensated for. See section

Requirements on foundation, Minimum resonance frequency in the robot product manual.

This is performed by Df Factor for axis 1 and 2 or Mounting Stiffness Factor depending on robot type, see

Limitations on page 152 .





149



Continued

TuneMaster is used for finding the optimal value of Df Factor / Mounting Stiffness

Factor. The obtained Df Factor / Mounting Stiffness Factor is then defined for the

Motion Process Modes used.

Note

A foundation that does not fulfill the requirements always impairs the accuracy to some extent, even if the described compensation is used. If the foundation rigidity is very low, there might not be possible to solve the problem using Df

Factor / Mounting Stiffness Factor.

In this case, the foundation must be improved or any of the solutions below used, for example, Optimal cycle time mode with a low Dh Factor, Accset Acc Factor, or Accset Fine Point Ramp Factor depending on the application.

If accuracy still needs to be improved

• For applications with high demands on path accuracy, for example cutting,

Advanced Shape Tuning and Accuracy mode/Low speed accuracy mode should be used. The choice of motion mode depends both on the robot type and the specific application. In general, Accuracy mode is recommended for small and medium size robots (up to IRB 2400/2600) and Low speed accuracy mode is recommended for larger robots.

• If the path accuracy still needs improvement, the accuracy modes can be adjusted with the tune parameters, some examples:

Tuning of Accuracy mode for improved accuracy:

1) Reduce World Acc Factor, for example from 1 to 0.5.

2) Reduce Dh Factor to 0.5 or lower. Note that a low value of Dh factor can change the corner zones at high speed.

Tuning of Low speed accuracy mode for improved accuracy:

1) Set World Acc Factor to 1, and set Geometric Accuracy Factor to

0.1.

2) Reduce Dh Factor to 0.5 or lower.

• The programmed speed must sometimes be reduced for best possible accuracy, e.g. in cutting applications. For example, a circle with radius 1 mm should not be programmed with a higher speed than 20 mm/s.

• For contact applications, for example milling and pre-machining, Low speed stiff mode is recommended. This mode can also be useful for large robots in some low speed applications (up to 100 mm/s) where a minimum of path vibrations is required, for example below 0.1 mm. Note that this mode has a very stiff servo tuning and that there may be cases where the Kv Factor needs to be reduced due to motor vibrations and noise.

• If overshoots and vibrations in fine points needs to be reduced. Use Optimal cycle time mode and decrease the value of Accset Fine Point Ramp Factor or Dh Factor until the problem is solved.

• If accuracy problems occur when starting or ending reorientation. Define a new zone with increased pzone_ori and pzone_eax

. These should always







Continued have the same value, even if there are no external axes in the system. Also increase zone_ori

. Always strive for smooth reorientations when programming.

• Finally, if the cycle time needs to be reduced after the tuning for accuracy is finished. Use different motion process modes in different sections of the

RAPID program.




151


3.4.4 Additional information

3.4.4 Additional information

Motion Process Mode compared to TuneServo and AccSet

Motion process modes simplifies application specific tuning and makes it possible to define the tuning by system parameters instead of the RAPID program.

In general, motion process modes should be the first choice for solving accuracy problems. However, application specific tuning can still be performed using the

TuneServo and

AccSet instructions in the RAPID program.

There are a few situations where

TuneServo and

AccSet might be a better choice.

One example of this is if an acceleration reduction in a section of the RAPID program solves the accuracy problem and the cycle time is to be optimized. In this case it might be better to use

AccSet which can be changed without fine point whereas change of motion process mode requires a fine point.

Limitations

• The Motion Process Mode concept is currently available for all six- and seven-axes robots except paint robots.

• The Mounting Stiffness Factor parameters are only available for the following robots:

IRB 120, IRB 140, IRB 1200, IRB 1520, IRB 1600, IRB 2600, IRB 4600, IRB

6620 (not LX), IRB 6640, IRB 6700.

• For IRB 1410, only the Accset and the geometric accuracy parameters are available.

• The following robot models do not support the use of World Acc Factor (i.e.

only World Acc Factor = -1 is allowed):

IRB 340, IRB 360, IRB 540, IRB 1400, IRB 1410

Related information

For information about

Configuration of Motion Process Mode parameters.

See

Technical reference manual - System parameters

RAPID instructions:

•

AccSet

- Reduces the acceleration

•

MotionProcessModeSet

- Set motion process mode

•

TuneServo

- Tuning servos

Technical reference manual - RAPID Instructions, Functions and Data types





3.5.1 Introduction to Wrist Move

3.5 Wrist Move [included in 687-1]

3.5.1 Introduction to Wrist Move

Purpose

The purpose of Wrist Move is to improve the path accuracy when cutting geometries with small dimensions. For geometrical shapes like small holes, friction effects from the main axes (1-3) of the robot often degrade the visual appearance of the shape. The key idea is that instead of controlling the robot's TCP, a wrist movement controls the point of intersection between the laser beam (or water jet or routing spindle, etc) and the cutting plane. For controlling the point of intersection, only two wrist axes are needed. Instead of using all axes of the robot, only two wrist axes are used, thereby minimizing the friction effects on the path. Which wrist axis pair to be used is decided by the programmer.

Using Wrist Move

Wrist Move is included in the RobotWare option Advanced robot motion.

Wrist Move is used together with the RAPID instruction

CirPathMode and movement instructions for circular arcs, that is,

MoveC

,

TrigC

,

CapC etc. The wrist movement mode is activated by the instruction

CirPathMode together with one of the flags

Wrist45

,

Wrist46

, or

Wrist56

. With this mode activated, all subsequent

MoveC instructions will result in a wrist movement. To go back to normal

MoveC behavior, then

CirPathMode has to be set with a flag other than

Wrist45

,

Wrist46

, and

Wrist56

, for example,

PathFrame

.

Note

During a wrist movement, the TCP height above the surface will vary. This is an unavoidable consequence of using only two axes. The height variation will depend on the robot position, the tool definition, and the radius of the circular arc. The larger the radius, the larger the height variation will be. Due to the height variation it is recommended that the movement is run at a very low speed the first time to verify that the height variation does not become too large. Otherwise it is possible that the cutting tool collides with the surface being cut.

Limitations

The Wrist Move option cannot be used if:

• The work object is moving

• The robot is mounted on a track or another manipulator that is moving

The Wrist Move option is only supported for robots running QuickMove, second generation.

The tool will not remain at right angle against the surface during the cutting. As a consequence, the holes cut with this method will be slightly conical. Usually this will not be a problem for thin plates, but for thick plates the conicity will become apparent.






3.5.1 Introduction to Wrist Move

Continued

The height of the TCP above the surface will vary during the cut. The height variation will increase with the size of the shape being cut. What limits the possible size of the shape are therefore, beside risk of collision, process characteristics like focal length of the laser beam or the water jet.





3.5.2 Cut plane frame

3.5.2 Cut plane frame

Defining the cut plane frame

Crucial to the wrist movement concept is the definition of the cut plane frame. This frame provides information about position and orientation of the object surface.

The cut plane frame is defined by the robot's starting position when executing a

MoveC instruction. The frame is defined to be equal to the tool frame at the starting position. Note that for a sequence of

MoveC instructions, the cut plane frame stays the same during the whole sequence.

Illustration, cut plane

The left illustration shows how the cut plane is defined, and the right illustration shows the tool- and cut plane frames during cutting.

en0900000118

Prerequisites

Due to the way the cut plane frame is defined, the following must be fulfilled at the starting position:

• The tool must be at right angle to the surface

• The z-axis of the tool must coincide with the laser beam or water jet

• The TCP must be as close to the surface as possible

If the first two requirements are not fulfilled, then the shape of the cut contour will be affected. For example, a circular hole would look more like an ellipse. The third requirement is normally easy to fulfill as the TCP is often defined to be a few mm in front of, for example, the nozzle of a water jet. However, if the third requirement is not fulfilled, then it will only affect the radius of the resulting circle arc. That is, the radius of the cut arc will not agree with the programmed radius. For a linear segment, the length will be affected.

Tip

In the jog window of the FlexPendant there is a button for automatic alignment of the tool against a chosen coordinate frame. This functionality can be used to ensure that the tool is at a right angle against the surface when starting the wrist movement.






3.5.2 Cut plane frame

Continued

Tip

Wrist movement is not limited to circular arcs only: If the targets of

MoveC are collinear, then a straight line will be achieved.







Instruction

This is a brief description of the instruction used in Wrist Move. For more information, see the description of the instruction in Technical reference manual - RAPID Instructions, Functions and Data types.

Instruction

CirPathMode

Descriptions

CirPathMode makes it possible to select different modes to reorientate the tool during circular movements.

The arguments

Wrist45

,

Wrist46

, and

Wrist56 are used specifically for the Wrist Move option.




157


3.5.4 RAPID code, examples

3.5.4 RAPID code, examples

Basic example

This example shows how to do two circular arcs, first using axes 4 and 5, and then using axes 5 and 6. After the two arcs, wrist movement is deactivated by

CirPathMode

.

! This position will define the cut plane frame

MoveJ p10, v100, fine, tWaterJet;

CirPathMode \Wrist45;

MoveC p20, p30, v50, z0, tWaterJet;

! The cut-plane frame remains the same in a sequence of MoveC


MoveC p40, p50, v50, fine, tWaterJet;

! Deactivate Wrist Movement, could use \ObjectFrame or \CirPointOri as well

CirPathMode \PathFrame;

Advanced example

This example shows how to cut a slot with end radius

R and length

L+2R

, using wrist movement. See

Illustration,

pSlot

and

wSlot

on page 159

. The slot both begins and ends at the position pSlot

, which is the center of the left semi-circle.

To avoid introducing oscillations in the robot, the cut begins and ends with semi-circular lead-in and lead-out paths that connect smoothly to the slot contour.

All coordinates are given relative the work object wSlot

.

! Set the dimensions of the slot

R := 5;

L := 30;

! This position defines the cut plane frame, it must be normal to the surface

MoveJ pSlot, v100, z1, tLaser, \wobj := wSlot;


! Lead-in curve

MoveC Offs(pSlot, R/2, R/2, 0), Offs(pSlot, 0, R, 0), v50, z0, tLaser, \wobj := wSlot;

! Left semi-circle

MoveC Offs(pSlot, -R, 0, 0), Offs(pSlot, 0, -R, 0), v50, z0, tLaser,

\wobj := wSlot;

! Lower straight line, circle point passes through the mid-point of the line

MoveC Offs(pSlot, L/2, -R, 0), Offs(pSlot, L, -R, 0), v50, z0, tLaser, \wobj := wSlot;


158

! Right semi-circle





3.5.4 RAPID code, examples

Continued

MoveC Offs(pSlot, L+R, 0, 0), Offs(pSlot, L, R, 0), v50, z0, tLaser,

\wobj := wSlot;

! Upper straight line, circle point passes through the mid-point of the line

MoveC Offs(pSlot, L/2, R, 0), Offs(pSlot, 0, R, 0), v50, z0, tLaser,

\wobj := wSlot;

! Lead-out curve back to the starting point

MoveC Offs(pSlot, -R/2, R/2, 0), pSlot, v50, z1, tLaser, \wobj := wSlot;

Deactivate Wrist Movement

CirPathMode \ObjectFrame;

Illustration, pSlot and wSlot

wSlot pSlot

xx0900000111




159


3.5.5 Trouble shooting

3.5.5 Trouble shooting

Unexpected cut shape

If the cut shape is not the expected, then check the following:

• The tool z-axis coincides with the laser beam or the water jet

• The tool z-axis is at right angle to the surface at the starting position of the first

MoveC

• If you have the option Advanced Shape Tuning, then try tuning the friction for the involved wrist axes.

Mismatching radius

If the radius of the circular arc does not agree with the programmed radius, then check that the TCP is as close to the surface as possible at the starting position.

Impossible movement with chosen axis pair

If the movement is not possible with the selected axis pair, then try activating another pair by using one of the flags

Wrist45

,

Wrist46

, or

Wrist56

. As a last resort, try reaching the starting position with another robot configuration.




4 Motion coordination

4.1.1 Overview


4.1 Machine Synchronization [607-1], [607-2]

4.1.1 Overview

Two options

Machine Synchronization consists of two options, Sensor Synchronization and

Analog Synchronization. The functionality is very similar for both these options, it is the hardware and configuration that differs.

The difference between the two options is that:

• Analog Synchronization is used together with a sensor that shows the position of the external mechanical unit as an analog signal.

• Sensor Synchronization requires an encoder that counts pulses as the external mechanical unit move, and an encoder interface unit which transforms the pulses into a sensor position.

All information in this chapter refers to both options, unless something else is specified. The term synchronization option refers to both options. Information that is only valid for one of the options is said to be specific for Sensor Synchronization or Analog Synchronization.

Purpose

The synchronization option adjusts the robot speed to an external moving device

(for example a press or conveyor) with the help of a sensor. It can also be used to synchronize two robots with each other.

Description

For the synchronization, a sensor is used to detect the movements of a press door, conveyor, turn table or similar device. The speed of the robot TCP will be adjusted in correlation to the sensor output, so that the robot will reach its programmed target at the same time as the external device reaches its programmed position.

The synchronization with the external device does not affect the path of the robot

TCP, but it affects the speed at which the robot moves along this path.

Functionality

The external device connected to the sensor cannot be controlled by the robot controller. However, in some ways it has similarities with a mechanical unit controlled by the robot controller:

• the sensor positions appears in the Jogging Window on the FlexPendant

• the sensor positions appears in the robtarget when a MODPOS operation is performed

• the mechanical unit may be activated, and deactivated






4.1.1 Overview

Continued

Basic approach

This is the general approach for setting up the synchronization option. For a more detailed description of how this is done, see the respective section.

• Install and connect hardware.

• Install the synchronization software.

• Configure the system parameters.

• Write a program that connects to the sensor and uses synchronization for robot movements (or a program for a master/slave robot application).





4.1.2 What is needed

4.1.2 What is needed

Sensor Synchronisation

The Sensor Synchronization application consist of the following components:

A

C

B

F

D

E en0400000655

A

B

E

F

C

D

B+C+D

External device that dictates the robot speed, e.g. a press door

Synchronization switch

Encoder

Encoder interface unit (DSQC 377)

Controller

Robot

Act as a sensor, giving input to the controller





163


4.1.2 What is needed

Continued

Analog Synchronization

The Analog Synchronization application consist of the following components: xx0700000431

A

B

C

D

Mold press that dictates the robot speed

Analog sensor for press position

Controller

Robot





4.1.3 Synchronization features

4.1.3 Synchronization features

Features

The synchronization option provides the following features:

Feature

Accuracy

Object queue

RAPID access to sensor data

Multiple sensors

Description

In Auto operation at constant sensor speed, the Tool Center Point (TCP) of the robot will stay within the programmed position corresponding to the sensor, with an error margin of:

• +/- 50 ms for Sensor Synchronization

• +/- 100 ms for Analog Synchronization

This is valid as long as the robot is within its dynamic limits with the added sensor motion. This figure depends on the calibration of the robot and sensor and is applicable for linear synchronization only.

Only for Sensor Synchronization:

Each time the external device trigger the synchronization switch, a sensor object is created in the object queue. The encoder interface unit will maintain the object queue, although for Sensor Synchronization the queue normally does not contain more than one object.

A RAPID program has access to the current position and speed of the external device, via the sensor.

Up to 2 sensors are supported.

For Sensor Synchronization, each sensor must have a DSQC 377.




165


4.1.4 General description of the synchronization process

4.1.4 General description of the synchronization process

Example with a press

This example shows the very basic steps when synchronization is used for material handling for a press.

When...

the press is closed and ready to start the press starts open the press is open enough for the robot to enter

Then...

a signal from the robot controller (or PLC) orders the press to start.

For Sensor Synchronization, the synchronization switch is triggered and a sensor object is created in the object queue.

The robot connects to the object.

For both Sensor Synchronization and Analog Synchronization, the robot moves, synchronized with the press, towards the press and reaches it when the press is open enough.

the robot places (or removes) a work piece in the press. The synchronization is ended.

For Sensor Synchronization, the sensor object is then dropped

(removed from the object queue).





4.1.5 Limitations


Limitations on additional axes

Each sensor is considered an additional axis. Thus the system limitation of 6 active additional axes must be reduced by the number of active and installed sensors.

The first installed sensor will use measurement node 6 and the second sensor will use measurement node 5. These measurement nodes are not available for additional axes and no resolvers should be connected to these nodes on any additional axes measurement boards.

Object queue lost on warm start or power failure


The object queue is kept on the encoder interface unit (DSQC 377). If the system is restarted or if the power supply to either the controller or the encoder interface unit fails, then the object queue will be lost.

Minimum speed

In order to maintain a smooth and accurate motion, there is a minimum speed of the external device that is detected. The device is considered to be still if its movement is slower than the minimum speed. This speed depends on the selection of encoder. It can vary from 4mm/s - 8mm/s.

Maximum speed

There is no determined maximum speed for the external device. Accuracy will decrease at speeds over those specified, and the robot will no longer be able to follow the sensor at very high sensor speeds (>1000mm/s) or with robot dynamic limitations.

Compatibility with the option Conveyor Tracking

If both Machine Synchronization and Conveyor Tracking options are installed, only one of the mechanical units SSYNC1 and CNV2 should be active at the same time.

For Machine Synchronization (Sensor Synchronization or Analog Synchronization),

CNV2 must be deactivated.

For Conveyor Tracking, SSYNC1 must be deactivated.




167


4.1.6.1 Encoder specification

4.1.6 Hardware installation for Sensor Synchronization

4.1.6.1 Encoder specification

Two phase type

The encoder must be of two phase type for quadrature pulses, to enable registration of reverse sensor motion, and to avoid false counts due to vibration etc. when the sensor is not moving.

Technical data

Output signal:

Voltage:

Current:

Phase:

Duty cycle:

Max. frequency:

Open collector PNP output

10 - 30 V (normally supplied by 24 VDC from encoder interface unit)

50 - 100 mA

2 phase with 90 degree phase shift

50%

20 kHz

Example encoder

An example of an encoder that fills these criteria, is the Lenord & Bauer GEL 262.





4.1.6.2 Encoder description

4.1.6.2 Encoder description

Overview

The encoder provides a series of pulses indicating the motion detected by the sensor. This is used to synchronize the motion between the robot and the external device.

Pulse channels

The encoder has two pulse channels, A and B which differ in phase by 90°. Each channel will send a fixed number of pulses per revolution depending on the construction of the encoder.

• The number of pulses per revolution for the encoder must be selected in relation to the gear reduction between the moving devices.

• The pulse ratio from the encoder should be in the range of 1250 - 2500 pulses per meter of sensor motion.

• The pulses from channel A and B are used in quadrature to multiply the pulse ratio by four to get counts.

This means that the control software will measure 5000 - 10000 counts per meter for an encoder with the pulse ratio 1250 - 2500.

en0300000556

Synchronization

To get an accurate synchronization, the movements of the external device must remain within some limits relative to robot movements. For every meter the robot moves, the external device movement must be between 0.2 and 5 meters (or radians).




169


4.1.6.3 Installation recommendations

4.1.6.3 Installation recommendations

Overview

The encoder must be installed in such a way that it gives precise feedback of the sensor output (reflects the true motion of the external device). This means that the encoder should be installed as close to the robot as practically possible, no further away than 30 meters.

The encoder is normally installed on the drive unit of the external device. The encoder may be connected to an output shaft on the drive unit, directly or via a gear belt arrangement.

Note

The encoder is a sensitive measuring device and for that reason it is important that no other forces than the shaft rotation are transferred from the sensor to the encoder and that the encoder is mounted using shock absorbers etc. to prevent damage from vibration.

Placement

The following is to be considered before start-up

If...

the drive unit includes a clutch arrangement

Then...

the encoder must be connected on the sensor side of the clutch.

the encoder is connected directly to a drive unit shaft it is important to install a specially designed flexible coupling to prevent applying mechanical forces to the encoder rotor..

the drive unit of the external device is located far away from the encoder the moving device itself may be a source of inaccuracy as the moving device will stretch or flex over the distance from the drive unit to the encoder cell. In such a case it may be better to mount the encoder closer to the drive unit with a different coupling arrangement.





4.1.6.4 Connecting encoder and encoder interface unit

4.1.6.4 Connecting encoder and encoder interface unit

Overview

If the cable from the robot to the encoder is too long, the inductance in the cable will produce spike pulses on the encoder signal. This signal will over a period of time damage the opto couplers in the encoder interface unit.

See Product manual - IRC5 for details on connecting to the encoder interface unit.

Reduce noise

To reduce noise, connect the encoder with a screened cable.

Reduce spike pulses

To reduce spike pulses, install a capacitor between the signal wire and ground for each of the two phases. The correct capacitance value can be determined by viewing the encoder signal on an oscilloscope.

The capacitor:

• should be connected on the terminal board where the encoder is connected.

• values are 100 nF - 1 µF, depending on the length of the cable.

Encoder power supply

The encoder is normally supplied with 24 VDC from the encoder interface unit.

When connecting two encoder interface units to the same encoder, let only one of the encoder interface units supply power to the encoder. If both encoder interface units supply power, a diode must be installed on each of the 24 V DC connections to make sure the power supplies do not interfere with each other.

Connecting encoder and the synchronization switch

The following procedure describes how to install the encoder and the synchronization switch to the encoder interface unit.

• One encoder can be connected to several encoder interface units.

• each controller must have an encoder interface unit if more than one robot is to use the sensor.

1

Action

Connect the encoder to the encoder interface unit (DSQC 377) on the controller.

Illustration




en0300000611


171


4.1.6.4 Connecting encoder and encoder interface unit

Continued

2

Action

Connect the synchronization switch to the encoder interface unit (DSQC 377) on the controller.

Illustration

Finding the Encoder rotating direction

The following procedure describes how to find the encoder rotating direction.

1

2

3

4

5

Action

On the FlexPendant, tap Inputs and Outputs.

Tap View and select I/O Units

Scroll down and selected Qtrack - d377

Scroll down to c1position

Run the encoder in forward direction while checking the value for C1Position.

If the number counts up:

• No action is required.

If the number counts down:

• the connection of the two encoder faces

(0° and 90°) must be interchanged.

Illustration

Encoder 1

24VDC

0V

A (0°)

B (90°)

24VDC

0V

Encoder 2

A (0°)

B (90°)

23

24

25

26

19

20

21

22

+2-AX12

29

+24 VDC

17

0 Volt

P_ENC1_A+

P_ENC1_A–

P_ENC1_B+

P_ENC1_B–

30

18

+24 VDC

0 Volt

P_ENC2_A+

P_ENC2_A–

P_ENC2_B+

P_ENC2_B–

Connection for PNP encoder en0300000584





4.1.7.1 Required hardware

4.1.7 Hardware installation for Analog Synchronization

4.1.7.1 Required hardware

Analog input board

An analog input board is required, for example DSQC355A. See Application manual - DeviceNet Master/Slave.

Analog linear sensor

An analog linear sensor is required, with analog signal input between 0 and 10 V.




173


4.1.8.1 Sensor installation

4.1.8 Software installation

4.1.8.1 Sensor installation

Overview

Normally the synchronization option and the DeviceNet option are preloaded at

ABB, and do not need to be re-installed. For more information on how to add options to the system, see Operating manual - RobotStudio.

The synchronization option automatically installs one sensor into the system parameters. To add more than one sensor, see

Installation of several sensors on page 177

.

About the installation

The options will install three additional configurations:

• I/O for the encoder interface unit (only for Sensor Synchronization)

• Sensor process description

• Motion mechanical description

Configuration of the default installation for Sensor Synchronization

This procedure describes how to configure system parameters for Sensor

Synchronization in the configuration editor in RobotStudio.

1

2

3

Action

Change the parameter Connected to Bus for the unit from "Virtual1" to the correct bus, for example "DeviceNet1".

Specify the correct address for the unit, parameter DeviceNet Address.

If the parameter DeviceNet Master Address (in topic I/O, type Bus) is changed, then the parameter Default Value (in topic I/O, type Fieldbus Command Type) for the instance

TimeKeeperInit must be changed to the same value.

Configuration of the default installation for Analog Synchronization

This procedure describes how to configure system parameters for Analog

Synchronization in the configuration editor in RobotStudio.

1

2

3

4

Action

Change the unit type, parameter Type of Unit, for the unit from "Virtual" to the correct unit type, for example "d355A".

Change the parameter Connected to Bus for the unit from "Virtual1" to the correct bus, for example "DeviceNet1".

Specify the correct address for the unit, parameter DeviceNet Address.

Change the communication interval for the unit type (e.g d355A) from 50 to 20 ms, parameter Connection 1 Interval.

For more information about this parameter, see Application manual - DeviceNet Master/Slave.






4.1.8.1 Sensor installation

Continued

How to add a sensor manually for Sensor Synchronization

Use the following procedure to add a sensor manually.

6

7

1

2

3

4

5

Action

Connect the encoder interface unit to the CAN bus. Note the address on the CAN bus.

In RobotStudio, click Load Parameters.

Select: Load Parameters if no duplicates and click Open.

Installation of a master sensor, connected to DeviceNet1 (first board).

Load the following files one by one from the OPTIONS/CNV directory:

• syvm1_eio.cfg

• syvm1_prc.cfg

• syvm1_moc.cfg

Installation of a slave sensor, connected to DeviceNet2 (second board).

Load the following files one by one from the OPTIONS/CNV directory:

• syvs1_eio.cfg

• syvs1_prc.cfg

• syvs1_moc.cfg

Restart the system.

If necessary, correct the address for the new encoder interface units. The default addresses in the file syvxx_eio.cfg should be replaced by the actual address of the board.

How to add a sensor manually for Analog Synchronization

There are no prepared files for adding a sensor for Analog Synchronization. It can be accomplished by copying the following files and edit them for the second sensor:

• synvaileio.cfg

• synvailprc.cfg

• syim1.moc




175


4.1.8.2 Reloading saved Motion parameters

4.1.8.2 Reloading saved Motion parameters

Overview

During installation of the synchronization option, a specific sensor configuration for additional axes will be loaded into the Motion system parameters.

Note

If these parameters were loaded before the synchronization option, then the mechanical unit SSYNC1 will not appear on the FlexPendant under the Jogging

window.

Reloading the SSYNC1 parameter


1

4

5

2

3

Action

Open the Configuration Editor and select the topic Motion.

Select the type File.

Click Load parameters and select mode.

Click Open and select the file syn1_moc from the RobotWare installation.


Result

The mechanical unit SSYNC1 should now be available on the FlexPendant under the Jogging window.





4.1.8.3 Installation of several sensors

4.1.8.3 Installation of several sensors

About the installation

Normally the synchronization option and the DeviceNet option are preloaded at

ABB, and do not need to be re-installed. For more information how to add options to the system, see Operating manual - RobotStudio.

The synchronization option automatically installs one sensor into the system parameters.

DeviceNet Dual option

When DeviceNet Dual is included, the following three sensors will be installed in the system:

• One sensor with "Robot to press syncro type": SSYNC1

• One virtual master sensor: SSYNM1

• One virtual slave sensor: SSYNCS1

Adding sensors manually

Up to four sensors can be used with the same controller, but the parameters for the three extra sensors must be loaded manually.

Use the following procedure to load the sensors manually.

1

2

3

4

5

6

7

8

Action

For Sensor Synchronization, connect the encoder interface unit to the CAN bus. Note the address on the CAN bus.

Use RobotStudio to add new parameters.

Click Load Parameters.

Select: Load Parameters if no duplicates and click Open.

Installation of a master sensor, connected to DeviceNet1 (first board).

Load the following files one by one from the OPTION/CNV directory:

• for second sensor: syvm2_eio.cfg, syvm2_prc and syvm2_moc.cfg

• for third sensor: syvm3_eio.cfg, syvm3_prc.cfg and syvm3_moc.cfg

• for fourth sensor: syvm4_eio.cfg, syvm4_prc.cfg and syvm4_moc.cfg

Installation of a slave sensor, connected to DeviceNet2 (second board).

Load the following files one by one from the OPTION/CNV directory:

• for second sensor: syvs2_eio.cfg, syvs2_prc.cfg and syvs2_moc.cfg

• for third sensor: syvs3_eio.cfg, syvs3_prc.cfg and syvs3_moc.cfg

• for fourth sensor: syvs4_eio.cfg, syvs4_prc.cfg and syvs4_moc.cfg

Restart the system.

For Sensor Synchronization: If necessary, correct the address for the new encoder interface units. Find the respective encoder interface unit in the system parameters under the topic I/O. The default addresses in the file syvxx_eio.cfg should be replaced by the actual address of the board.

Available sensors

The second and third sensor (SSYNC2, SSYNC3) should now appear in

Motion/mechanical unit and in the Jogging window on the FlexPendant.




177


4.1.9.1 General issues when programming with the synchronization option

4.1.9 Programming the synchronization

4.1.9.1 General issues when programming with the synchronization option

Activate sensor

The sensor must be activated before it may be used for work object coordination, just like any other mechanical unit. The usual

ActUnit instruction is used to activate the sensor and

DeactUnit is used to deactivate the sensor.

By default, the sensor is installed inactive on start. If desired, the sensor may be configured to always be active upon start. See

Mechanical unit on page 213

.

Automatic connection


When a sensor mechanical unit is activated, it first checks the state of the encoder interface unit to see whether the sensor was previously connected. If the encoder interface unit, via the I/O signal c1Connected, indicates connection, then the sensor will automatically be connected upon activation. The purpose of this feature is to automatically reconnect in case of a power failure with power backup on the encoder interface unit.

Connection via WaitSensor instruction

Motions that are to be synchronized with the external device cannot be programmed until an object has been connected to the sensor with a

WaitSensor instruction.

If the object is already connected with a previous

WaitSensor instruction, or if connection was established during activation, then execution of a second

WaitSensor instruction will cause an error.

After connection to an object with a

WaitSensor instruction the synchronized motion is started using

SyncToSensor\On instruction.

For details about the instructions

WaitSensor and

SyncToSensor\On

, see

Technical reference manual - RAPID Instructions, Functions and Data types.

Programming Sensor Synchronization

In the following instructions, there are references to programming examples.

Information

1

Action

Create a program with the following instructions:

ActUnit SSYNC1;

MoveL waitp, v1000, fine, tool;

WaitSensor SSYNC1;

2 Single-step the program past the

WaitSensor instruction.

The instruction will return if there is an object in the object queue. If the is no object, the execution will stop while waiting for an object (i.e. a sync signal).






4.1.9.1 General issues when programming with the synchronization option

Continued

3

4

5

6

7

8

9

Action Information

Run the external device until a sync signal is generated by the synchronization switch.

The program should exit the

WaitSensor and is now

“connected” to the object.

Stop the external device in the position that should correspond to the robot target you are about to program.

Start the synchronized motion with a

SyncToSensor

SSYNC1\On instruction. See

Programming examples on page 180 .

Program move instructions.

For every time you modify a position, run the external device to the position that should correspond to the robot target.

Use corner zones for the move instructions, see

Finepoint programming on page 184 .

End the synchronized motion with a

SyncToSensor

SSYNC1\Off instruction. See

Programming examples on page 180 .


Program a

DropSensor SSYNC1; instruction. See

Programming examples on page 180

.

Program a

DeactUnit SSYNC1; instruction if this is the end of the program, or if the sensor is no longer needed. See

Programming examples on page 180

.

Synchronize the sensor

If it is not possible to move the external device to the desired position, modify the position first and then edit the sensor value in the robtarget (as for any additional axis).




179


4.1.9.2 Programming examples

4.1.9.2 Programming examples

Sensor Synchronization program


!Activate sensor

ActUnit SSYNC1;

!Connect to the object

WaitSensor SSYNC1;

!Start the Synchronized motion

SyncToSensor SSYNC1\On;

!Instructions with coordinated robot targets




!Stop the synchronized motion

SyncToSensor SSYNC1\Off;

!Exit coordinated motion


!Disconnect from current object

DropSensor SSYNC1;

MoveL p0, v1000, fine;

!Deactivate sensor

DeactUnit SSYNC1;

Analog Synchronization program

VAR num startdist := 600;


!Activate sensor

ActUnit SSYNC1;

WaitSensor SSYNC1 \RelDist:=startdist;











!Exit coordinated motion




MoveL p0, v1000, fine;

!Deactivate sensor

DeactUnit SSYNC1;


4.1.9.2 Programming examples

Continued




181


4.1.9.3 Entering and exiting coordinated motion in corner zones

4.1.9.3 Entering and exiting coordinated motion in corner zones

Corner zones can be used

Once a

WaitSensor instruction is connected to an object it is possible to enter and exit synchronized motion with the sensor via corner zones.

Dropping object after corner zone

If an instruction using a corner zone is used to exit coordinated motion, it cannot be followed directly by the

DropSensor instruction. This would cause the object to be dropped before the robot has left the corner zone, when the motion still requires the conveyor coordinated work object.

If the work object is dropped when motion still requires its position, then a stop will occur.

To avoid this, either call a finepoint instruction or at least two corner zone instructions before dropping the work object.

Correct example

This is an example of how to enter and exit coordinated motion via corner zones.


WaitSensor SSYNC1;


!start synchronization after zone around p20

SyncToSensor SSYNC1\On





!Exit synchronization after zone around p60



DropSensor SSYNC1;


Incorrect example

This is an incorrect example of exiting coordination in corner zones. This will cause the program to stop with an error.



!Exit coordination in zone


DropSensor SSYNC1;

If coordinated motion is ended in a corner zone, another move instruction must be executed before the sensor is dropped.





4.1.9.4 Use several sensors

4.1.9.4 Use several sensors

Overview

When several sensors are used the program must have at least one move instruction without any synchronization between parts of the path that are synchronized with two different sensors.

Program example


WaitSensor SSYNC1\RelDist:=Pickdist;


SyncToSensor SSYNC1\MaxSync:=1653\On;


MoveL p30, v400, z20, currtool;






WaitSensor SSYNC2\RelDist:=1720;




SyncToSensor SSYNC2\MaxSync:=2090\On;








183


4.1.9.5 Finepoint programming

4.1.9.5 Finepoint programming

Overview

Avoid the use of fine points when using synchronized motion. The robot will stop and lose the synchronization with the sensor for 100 ms. Then the RAPID execution will continue.

Finepoint programming can be used on the last synchronized move instruction if the synchronization does not need to be accurate at the last target.

Program example

The following program example shows how synchronized motion may be stopped.

WaitSensor SSYNC1;

SyncToSensor SSYNC1 \On;



SyncToSensor SSYNC1 \Off;



DropSensor SSYNC1;

At p4 the robot is no longer synchronized with the external device, and there are no restrictions for using fine points.

At p2 the synchronization will end and a fine point can be used, but the accuracy of the synchronization will be reduced.





4.1.9.6 Drop sensor object

4.1.9.6 Drop sensor object

Overview

For Sensor Synchronization, a connected object may be dropped, with a

DropSensor instruction, once the synchronized motion has ended.

Example:

DropSensor SSYNC1;

For Analog Synchronization, the instruction

DropSensor must not be used.

Considerations

The following considerations must be considered when dropping an object:

• It is important to make sure that the robot motion is no longer using the sensor position when the object is dropped. If robot motion still requires the sensor position then a stop will occur when the object is dropped.

• As long as the

SyncToSensor \Off instruction has not been issued, the robot motion will be synchronized with the sensor.

• It is not necessary to be connected in order to execute a

DropSensor instruction. No error will be returned if there was no connected object.




185


4.1.9.7 Information on the FlexPendant

4.1.9.7 Information on the FlexPendant

Overview

The user has access to the sensor position and speed via the FlexPendant

Jogging window

The position (in millimeters) of the sensor object is shown in the Jogging window.

This value will be negative if a Queue Tracking Distance is defined. When the synchronization switch is triggered, the position will automatically be updated in the Jogging window.

I/O window

Sensor Synchronization

From the I/O window the user has access to all the signals that are defined on the encoder interface unit. From this window it is possible to view the sensor object position (in meters) and the sensor object speed (in m/s). The speed will be 0 m/s until the synchronization switch registers a sensor object.

Analog Synchronization

For Analog Synchronization, only the sensor position is shown in the I/O window.





4.1.9.8 Programming considerations

4.1.9.8 Programming considerations

Performance limits

The synchronization will be lost if joint speed limits are reached, particularly in singularities. It is the responsibility of the programmer to ensure that the path during synchronized movement does not exceed the speed and motion capabilities of the robot.

Motion commands

All motion commands are allowed during synchronization.

Manual mode

The synchronization is not active in manual mode.

Speed reduction % button

The synchronization works only with 100% speed. As the robot speed is adjusted to sensor movements the defined robot speed percentage will be overridden.

Programmed speed

The best performance of the synchronization will be obtained if the programmed speed is near the real execution speed. The programmed speed should be chosen as the most probable execution speed. Large changes in speed between two move instructions should be avoided.

Finepoints

Finepoints are allowed during synchronization motion, but the robot will stop at the fine point and the synchronization will be lost if the external device is still moving. See

Finepoint programming on page 184

.

Position warnings

If robot_to_sensor position ratio is higher than 10 or lower than 0.1 a warning will appear. The user should modify the robtarget position or the sensor value in the robtarget according to the warning text.

Speed warnings

If programmed sensor_speed is higher than:

•

(max_sync_speed*sensor_nominal_speed)/robot_tcp_speed then a speed warning will appear and the user should modify robot speed or sensor_nominal_speed or max_sync_speed according to the warning text.

If the programmed sensor_speed is lower than:

•

(min_sync_speed*sensor_nominal_speed)/robot_tcp_speed a similar warning will appear:

• Programmed_sensor_speed equals sensor_distance/robot_interpolation_time.






4.1.9.8 Programming considerations

Continued

Change of tools

Changing the tool is not allowed during synchronization if corvec is used.

Instructions that will deactivate the synchronization

The instructions

ActUnit

,

DeactUnit

, and

ClearPath will deactivate any

SyncToSensor or

SupSyncSensorOn instruction. So the instructions

ActUnit

,

DeactUnit

, and

ClearPath should not be used between

SyncToSensor or

SupSyncSensorOn instruction and the move instructions related to synchronized path or supervised path.

The correct order is:

ActUnit SSYNC1;

WaitSensor SSYNC1;


! move instructions

...


Other RAPID limitations

• The commands,

StorePath

,

RestoPath do not work during synchronization.

•

EoffsSet

,

EoffsOn

,

EoffsOff have an effect on the sensor taught position.

• Power fail restart is not possible with the synchronization option.





4.1.9.9 Modes of operation

4.1.9.9 Modes of operation

Operation in manual reduced speed mode (< 250 mm/s)

The forward and backward hard buttons can be used to step through the program.

New instructions may be added and MODPOS may be used to modify programmed positions.

The robot will recover as normal if the enabling device is released during motion.

The robot will not perform synchronized motions to the sensor while in Manual

Reduced Speed mode.

Operation in automatic mode

Once a

SyncToSensor instruction has been executed, then it is no longer possible to step through the program with the forward and backward buttons while the sensor is moving.

Start/Stop

The robot will stop and loose synchronization with the sensor if the STOP button is pressed or if RAPID instruction

Stop or

StopMove is executed between the

SyncToSensor and

DropSensor instructions.

The sensor object will not be lost but if the sensor is moving then the object will quickly move out of the max dist. Restart synchronization from the current instruction is not allowed if sensor is moving. The program must be restarted from

MAIN

. If a restart is forced the robot will stop with max_dist error where the sensor has stopped.

Emergency Stop/Restart

When the emergency stop is pressed the robot will stop immediately. If the program was stopped after a

SyncToSensor then the sensor object will not be lost but if the sensor is moving then the object will quickly move out of the max distance.

Restart synchronization from the current instruction is not possible and the program must be restarted from

MAIN

. If a restart is forced after the question “Do you want to regain“, the robot will move unsynchronized to the sensor at programmed speed.

Operation under manual full speed mode (100%)

Operation in manual full speed mode is similar to operation in automatic mode.

The program may be run by pressing and holding the start button, but once a

SyncToSensor instruction has been executed then it is no longer possible to step through the program with the forward or backward buttons while the sensor is moving.

Hold to run button

Pressing and releasing the hold to run button will make the robot stop and restart.

The synchronization is lost at robot stop. At restart the robot will try to regain synchronization at max_adjustment_speed.





189


4.1.9.9 Modes of operation

Continued

Stop/Restart

When the stop button is pressed, or emergency stop is pressed, the robot will stop immediately. If the program was stopped after a

SyncToSensor then the synchronized object will not be lost but if the sensor is moving then the object will quickly move out of the max distance. Restart from the current instruction is not possible and the program must be restarted from

MAIN

.





4.1.10.1 Introduction

4.1.10 Robot to robot synchronization

4.1.10.1 Introduction

Overview

It is possible to synchronize two robot systems in a synchronization application.

This is done with a master and a slave robot setup.

Requirements

For cable connection and setup, see Application manual - DeviceNet Master/Slave.




191


4.1.10.2 The concept of robot to robot synchronization

4.1.10.2 The concept of robot to robot synchronization

Description

The basic idea of robot to robot synchronization is that two robot should use a common virtual sensor. The master robot controls the virtual motion of this sensor.

The slave robot uses the sensor’s virtual position and speed to adjust its speed.

The synchronization is achieved by defining positions where the two robots should be at the same time, and assigning a sensor value for each of these points.

Illustration

0

1

200

2

400

3

600

C

800

4

1000

4

2

3

1

2

1

4

3

B

A xx0400001145





4.1.10.3 Master robot configuration parameters

4.1.10.3 Master robot configuration parameters

Overview

Use the following parameters to set up the master robot.

Use RobotStudio to change the parameters.

Topic: Motion

SINGLE_TYPE/Parameter

Name mechanics process_name use_path

Value

SSYNC2

SS_LIN

SSYNC2

PSSYNC

Topic: Process

SENSOR_SYSTEM/Parameter

Name sensor_type use_sensor adjustment_speed min_dist max_dist correction_vector_ramp_length

Value

SSYNC1

CAN

CAN1

1000

600

20000

10

Topic: I/O

EIO_UNIT

EIO_UNIT/Parameter

Name

UnitType

Bus

DN_Address

Value

MASTER1

DN_SLAVE

DeviceNet1

1

EIO_SIGNAL

EIO_SIGNAL/Parameter

Name

SignalType

Unit

UnitMap

MaxLog

MaxPhys

MaxPhysLimit

1

1

Value

ao1Position

AO

MASTER1

0-15

10.0







Continued

EIO_SIGNAL/Parameter

MaxBitVal

MinLog

MinPhys

MinPhysLimit

MinBitVal

EIO_SIGNAL/Parameters

Name

SignalType

Unit

UnitMap

MaxLog

MaxPhys

MaxPhysLimit

MaxBitVal

MinLog

MinPhys

MinPhysLimit

MinBitVal


Name

SignalType

Unit

UnitMap

MaxLog

MaxPhys

MaxPhysLimit

MaxBitVal

MinLog

MinPhys

MinPhysLimit

MinBitVal


Name

SignalType

Unit

UnitMap





Value

32767

-10.0

-1

-1

-32767

1

1

32767

-10.0

-1

-1

-32767

Value

ao1Speed

AO

MASTER1

16-31

10.0

1

32767

-10.0

-1

-1

-32767

Value

ao1PredTime

AO

MASTER1

32-47

10.0

1

Value

do1Dready

DO

MASTER1

48


Name

SignalType

Unit

UnitMap



Continued

Value

do1Sync2

DO

MASTER1

50




195


4.1.10.4 Slave robot configuration parameters

4.1.10.4 Slave robot configuration parameters

Overview

For default configuration, see


.

Use RobotStudio to change the parameters and to set up the slave robot.

Description

To make the slave robot stop and restart synchronized with the master robot:

• Set the parameter value min_sync_speed to 0.0

The slave robot will also stop if a fine point is defined in the master robot path.

Topic: Process

SENSOR_SYSTEM

SENSOR_SYSTEM/Parameter

Name sensor_type use_sensor adjustment_speed min_dist max_dist correction_vector_ramp_length nominal_speed

CAN_INTERFACE

CAN_INTERFACE/Parameters

Name

Signal delay

Connected signal

Position signal

Velocity signal

Null speed signal

Data ready signal

Waitwobj signal

Dropwobj signal

Data Time stamp

RemAllPObj signal

Virtual sensor

Sensor Speed filter

Value

SSYNCS1

CAN

CAN1

1000

600

20000

10

1000

Value

CAN1

34 c1Connected c1Position c1Speed c1NullSpeed c1WaitWObj c1DropWobj c1DTimestamp c1RemAllPObj

NO

0,33







Continued

Topic: I/O

EIO_UNIT

EIO_SIGNAL

EIO_UNIT/Parameters

Name

UnitType

Bus

DN_Address


Name

SignalType

Unit

UnitMap

MaxLog

MaxPhys

MaxPhysLimit

MaxBitVal

MinLog

MinPhys

MinPhysLimit

MinBitVal


Name

SignalType

Unit

UnitMap

MaxLog

MaxPhys

MaxPhysLimit

MaxBitVal

MinLog

MinPhys

MinPhysLimit

MinBitVal


Name

SignalType

Value

SLAVE1

DN_SLAVE

DeviceNet2

1

1

1

32767

-10.0

-1

-1

-32767

Value

ai1Speed

AI

SLAVE1

16-31

10.0

Value

ai1PredTime

AI

1

1

0-15

10.0

Value

ai1Position

AI

SLAVE1

32767

-10.0

-1

-1

-32767





197



Continued


Unit

UnitMap

MaxLog

MaxPhys

MaxPhysLimit

MaxBitVal

MinLog

MinPhys

MinPhysLimit

MinBitVal


Name

SignalType

Unit

UnitMap


Name

SignalType

Unit

UnitMap

Value

di1Dready

DI

SLAVE1

48

Value

di1Sync2

DI

SLAVE1

50

Value

SLAVE1

32-47

10.0

1

1

32767

-10.0

-1

-1

-32767





4.1.10.5 Programming example for master robot

4.1.10.5 Programming example for master robot

Overview

The following program is an example of how to program a master robot.

Master robot programming

syncstart:=20;

Syncpos1:=300;

Syncpos2:=600;

Syncpos3:=900;

Syncpos4:=1200;

!Synchronized motion between master and slave robpos1.extax.eax_e:=syncpos1; robpos2.extax.eax_e:=syncpos2; robpos3.extax.eax_e:=syncpos3; robpos4.extax.eax_e:=syncpos4; robpos5.extax.eax_e:=syncstart;

!Init of external axis pOutsideNext.extax.eax_e:=syncstart;

!Activate sensor

ActUnit SSYNC1;

!Instruction with coordinated robot targets

MoveJ pOutsideNext, v1000, fine, tool1;

!Init of external axis robposstart.extax.eax_e:=syncstart;

!Set digital output

SetDO Dosync 1,0


MoveJ robposstart, v2000, z50, tool1;

!Set digital output

PulseDO\PLength:= 0.1, doSync1;


MoveJ robpos1, v2000, z10, tool1;









199


4.1.10.5 Programming example for master robot

Continued

Considerations

The following is to be considered

• The values of extax.eax_e

should increase for every robtarget during synchronization. The first move instruction of the master robot, after the synchronization, should also have a higher extax.eax_e

value than the previous instruction. Otherwise the value of extax.eax_e

may decrease, and the synchronization end, before the slave robot has reached its target.

• The movement back to syncstart

(move instruction to robpos5 in the example) may be slower than the ordered speed ( v2000

). If this robot movement is short and the value of extax.eax_e

is large, the maximum speed will be limited by the virtual sensor speed.

• Do not use

WaitSensor or

DropSensor

.

• Verify that the virtual sensor max speed (speed_out) is less than 1m/s.





4.1.10.6 Programming example for slave robot

4.1.10.6 Programming example for slave robot

Overview

The following program is an example of how to program a slave robot.

Slave robot programming

syncstart:=20;

Syncpos1:=300;

Syncpos2:=600;

Syncpos3:=900;

!Synchronized motion between master and slave robpos1.extax.eax_e:=syncpos1; robpos2.extax.eax_e:=syncpos2; robpos3.extax.eax_e:=syncpos3;


MoveJ posstart, v500, z50, tool1;

!Wait for digital input

WaitDI diSync1; 1;


WaitSensor SSYNC1;\RelDist:=100;









Considerations

The following is to be considered:

• Do not use

DropSensor

.

• Do not use any corvecs.




201



4.1.11 Synchronize with hydraulic press using recorded profile


Overview

This section describes how to use a recorded machine profile to improve the accuracy of robot’s synchronization with a hydraulic press. This profile is used for modeling of press path. Not using a recorded profile will require a bigger distance between robot and press model when teaching the path.

Principles of hydraulic press synchronization

1 Record the movement of the hydraulic press.

2 Activate the record to be used in the next cycle.

3 Activate the sensor synchronization with the RAPID instruction

SyncToSensor

.





4.1.11.2 Configuration of system parameters

4.1.11.2 Configuration of system parameters

Introduction

This section describes how to configure the parameters to get the best result when using recorded sensor profiles with a hydraulic press. Start the tuning with the general settings. If the system is not using a DSQC377A encoder, see

Settings for analog input with no DSQC377A encoder on page 203

If the sensor is using group input, see

Settings for sensor using Group input on page 204 . Descriptions of the

system parameters are found in

System parameters on page 211 .

General settings

This parameter belong to the configuration type Fieldbus Command in the topic

I/O.

Parameter Value

Parameter Value for the instance where Type of

Fieldbus Command is

IIRFFP.

10-15 Hz, Change this value to get good accuracy during start and stop.

This parameter belong to the configuration type Path Sensor Synchronization in the topic Motion.

Parameter

Synchronization Type

Value

ROBOT_TO_HPRES

The parameters belong to the configuration type Sensor systems in the topic

Process.

Parameter

Sensor start signal

Stop press signal

Sync Alarm signal

Value

Type the name of the I/O signal



Settings for analog input with no DSQC377A encoder

The parameters belong to the configuration type Can Interface in the topic Process.

Parameter

Virtual sensor

Position signal

Value

Yes

Type the name of the analog input.

Note

All other signals except Position signal should be empty (i.e. "").

Tip

WaitSensor and

DropSensor are not needed in the RAPID program.







Continued

Settings for sensor using Group input


Process.

Parameter

Pos Group IO scale

Value

Define the number of input data per meter, the default value is set to 10000.


Parameter

Virtual sensor

Position signal

Value

Yes

Type the name of the used group input.

Note

All other signals except Position signal should be empty (i.e. "")

Tip

WaitSensor and






4.1.11.3 Program example

4.1.11.3 Program example

Overview

This section describes the programming cycles that are typical for programming a hydraulic press.

Program example

First press cycle

Second press cycle

A pulse on sensor_start_signal is needed to synchronize readings of record and actual positions for each cycle.

During press opening the robot moves synchronized with press.

PrxActivAndStoreRecord SSYNC1, 0, "profile.log";

WaitSensor Ssync1;

MoveL p10, v1000, z10, tool, \WObj:=wobj0;

SyncToSensor Ssync1\On;



SyncToSensor Ssync1\Off;

Third press cycle

A pulse on sensor_start_signal will start storing position in a record array.

During this cycle the robot is not synchronized with press.

ActUnit SSYNC1;

WaitSensor SSYNC1;

! Set up a recording for 2 seconds

PrxStartRecord SSYNC1, 2, PRX_HPRESS_PROF;

! Process waiting for sensor_start_signal

! then waiting for press movement and record it during 2 sec.

No special instruction is needed, but a pulse on sensor_start_signal is needed to synchronize readings of record and actual positions for each cycle. A new record can also be started.


WaitSensor Ssync1;









205



4.1.12 Synchronize with molding machine using recorded profile


Overview

This section describes how to use a recorded machine profile to improve the accuracy of a robot’s synchronization with a molding machine. This profile is used for modeling of mold path. Not using a recorded profile will require a bigger distance between robot and machine model when teaching the path.

Principles of mold synchronization

1 Record the movement of the Molding machine.

2 Activate the record to be used in the next cycle.

3 Activate the sensor synchronization with the RAPID instruction

SynctoSensor

.

Tip

When the molding machine is closing, supervision can be used instead of synchronization. For more information, see

Supervision on page 210

.






4.1.12.2 Configuration of system parameters

Introduction

This section describes how to configure the parameters to get the best result when using recorded sensor profiles with a molding machine. Start the tuning with the general settings. If the system is not using a DSQC377A encoder, see

Settings for analog input with no DSQC377A encoder on page 207

If the sensor is using group input, see

Settings for sensor using Group input on page 208 . Descriptions of the

system parameters are found in


General settings

This parameter belong to the configuration type Fieldbus Command in the topic

I/O.

Parameter Value

Parameter Value for the instance where Type of

Fieldbus Command is

IIRFFP.

10-15 Hz, Change this value to get good accuracy during start and stop.

This parameter belong to the configuration type Path Sensor Synchronization in the topic Motion.

Parameter

Synchronization Type

Value

SYNC_TO_IMM


Process.

Parameter

Sensor start signal

Stop press signal

Sync Alarm signal

Value




Settings for analog input with no DSQC377A encoder


Parameter

Virtual sensor

Position signal

Value

Yes

Type the name of the analog input.

Note

All other signals except Position signal should be empty (i.e. "").

Tip

WaitSensor and








Continued

Settings for sensor using Group input


Process.

Parameter

Pos Group IO scale

Value

Define the number of increments per meter for the group input.

The default value is set to 10000.


Parameter

Virtual sensor

Position signal

Value

Yes

Type the name of the used group input.

Note

All other signals except Position signal should be empty (i.e. "")

Tip

WaitSensor and






4.1.12.3 Program example

4.1.12.3 Program example

Overview

This section describes the programming cycles that are typical for programming a molding machine.

Program example

First press cycle

Second press cycle

A pulse on sensor_start_signal is needed to synchronize readings of record and actual positions for each cycle.


PrxActivAndStoreRecord SSYNC1, 0, "profile.log";

WaitSensor Ssync1;






Third press cycle

A pulse on sensor_start_signal will start storing position in a record array.

During this cycle the robot is not synchronized with press.

ActUnit SSYNC1;

WaitSensor SSYNC1;

! Set up a recording for 2 seconds

PrxStartRecord SSYNC1, 2, PRX_PROFILE_T1;

! Process waiting for sensor_start_signal

! then waiting for press movement and record it during 2 sec.

No special instruction is needed, but a pulse on sensor_start_signal is needed to synchronize readings of record and actual positions for each cycle. A new record can also be started.


WaitSensor Ssync1;









209


4.1.13 Supervision

4.1.13 Supervision

Introduction

The supervision can be used to save cycle time when robot moves outside the mold or press. Instead of waiting to be outside the machine to enable close mold the robot enable close mold when it starts to move outside the mold after picking the part.

The supervision can stop the mold if it comes too near the robot by setting the output signal defined by the system parameter Sync Alarm signal.

SupSyncSensorOn is used to supervise the movement of the robot with the mold or press. Usually supervision is used until the robot is moved outside the mold or press. With supervision it is possible to turn off the synchronization and turn on supervision when a workpiece is dropped or collected in the molding machine.

SupSyncSensorOn protects the robot and machine from damaging.

Supervision does not deactivate the synchronization.

Example

For the case you cannot move the sensor to defined position you have to set the external axis value in your rapid program p10.extax.eax_f:=sens10; p20.extax.eax_f:=sens20; p30.extax.eax_f:=sens30;

WaitSensor Ssync1;

MoveL p10, v1000, fine, tool, \WObj:=wobj0;

SupSyncSensorOn Ssync1, 150, -100, 650\SafetyDelay:=0;;


MoveL p30, v1000, fine, tool, \WObj:=wobj0;

SupSyncSensorOff Ssync1;

Sens10 is the expected position of the machine (model of the machine movement related to robot movement) when robot will be at p10 and sens20 is the expected position of the machine when robot will be at p20

.

The supervision will be done between the sensor position 650 and 150 mm and triggers the output if the distance between the robot and the mould is smaller than

100 mm.

Safetydist

(in this case

-100

) is the limit of the difference between expected machine position and the real machine position. It must be negative, i.e. the model should always be moving in advance of the real machine. In the case of decreasing machine positions the limit must be negative corresponding to maximum negative position difference (and minimum advance distance). In the case of increasing machine positions the limit must be positive corresponding to minimum positive position difference (and minimum advance distance).





4.1.14 System parameters


About system parameters

This section describes the system parameters in a general way. For more information about the parameters, see Technical reference manual - System parameters.

Fieldbus Command

Only for Sensor Synchronization.

These are different instances of the type Fieldbus Command in the topic I/O.

Type of Fieldbus

Command

Counts Per Meter

Sync Separation

Description

The number of counts per meter of the external device motion.

Defines the minimum distance that the external device must move after a sync signal before a new sync signal is accepted as a valid object.

For Sensor Synchronization, there is no need to change the default value.

Queue Tracking Distance

Defines the placement of the synchronization switch relative to the

0.0 meter point on the sensor.


Start Window Width

IIRFFP

Defines the size of the start window. It is possible to connect to objects within this window with the instruction

WaitSensor

.


Specifies the location of the real part of the poles in the left-half plane

(in Hz).

Sensor systems

These parameters belong to the topic Process and the type Sensor System.

Parameter

Sensor nominal speed

Description

Adjustment speed When entering sensor synchronization, the robot speed must be adjusted to the speed of the external device. The speed (in mm/s) at which the robot‘ catches up’ to this speed for the first motion is defined by

Adjustment Speed.

Min dist

Max dist

The minimum distance (in millimeters) that a connected object may have before being automatically dropped.


Not used for Analog Synchronization.

The maximum distance (in millimeters) that a connected object may have before being automatically dropped.



The nominal work speed of the external device. If the speed of the device exceeds 200 mm/s this parameter must be increased.







Continued


Stop press signal Name of the digital input signal telling that press is stopping. This signal is needed for safe stop of robot.

Sensor start signal

Name of the digital input signal to synchronize recorded profile and new machine movement. The signal must be set before start of machine movement. The signal must be triggered 100 ms before the press moves.

Start ramp Defines for how many calculation steps the position error may exceed

Max Advance Distance. During this ramping period, the position error may be 5 times Max Advance Distance.

Sync Alarm signal Name of the digital output signal to stop the synchronized machine.This

signal may be set during supervision of sync sensor.

CAN Interface

These parameters belong to the topic Process and the type CAN Interface.

Parameter

Connected signal

Position signal

Velocity signal

Null speed signal

Description

Name of the digital input signal for connection.


Name of the analog input signal for sensor position.

Name of the analog input signal for sensor speed.

Data ready signal

Waitwobj signal

Dropwobj signal

Name of the digital input signal indicating zero speed on the sensor.


Name of the digital input signal indicating a poll of the encoder unit.


Name of the digital output signal to indicate that a connection is desired to an object in the queue.


Name of the digital output signal to drop a connected object on the encoder unit


PassStartW signal Name of the digital output signal to indicate that an object has gone past the start window without being connected.


Pos Update time Time (in ms) at which the synchronization process read the sensor position.

Motion Planner

These parameters belong to the topic Motion and the type Motion planner.

Parameter

Path resolution

Process update time

CPU load equalization

Description

The period at which steps along the path are calculated.

The time (in seconds) at which the sensor process updates the robot kinematics on the sensor position.

CPU load equalization needs to be lowered for the synchronization option. The default value is 2 but for the synchronization option it should be set equal to 1 to have a stable synchronization speed.







Continued

Mechanical unit

These parameters belong to the topic Motion and the type Mechanical unit.

Parameter

Name

Activate at start up

Deactivate Forbidden

Description

The name of the unit (max. 7 characters).

The sensor is to be activated automatically at start up.

The sensor cannot be deactivated.

Single type

This parameter belongs to the topic Motion and the type Single type.

Parameter

Mechanics

Description

Specifies the mechanical structure of the sensor.

Transmission

This parameter belong to the topic Motion and the type Transmission.

Parameter

Rotating move

Description

Specifies if the sensor is rotating (Yes) or linear (No).

Path Sensor Synchronization

These parameters belong to the topic Motion and the type Path Sensor

Synchronization. They are used to set allowed deviation between calculated and actual position of the external device, and minimum/maximum TCP speed for the robot.


Max Advance Distance The max advance distance allowed from calculated position to actual position of the external device.

Max Delay Distance The max delay distance allowed from calculated position to actual position of the external device.

The max robot TCP speed allowed in m/s.

Max Synchronization

Speed

Min Synchronization

Speed

The min robot TCP speed allowed in m/s.




213


4.1.15 I/O signals

4.1.15 I/O signals

Overview

Sensor Synchronization provides several I/O signals which allow a user or RAPID program to monitor and control the object queue on the encoder interface unit.

The object queue is designed for the option Conveyor Tracking and has more functionality than required by Sensor Synchronization. Since each closing of a press is considered an object in the object queue, signals for the object queue may occasionally be useful.

Object queue signals

The following table shows the I/O signals in the encoder unit DSQC 354 which impact the object queue.

Instruction

c1ObjectsInQ c1Rem1PObj c1RemAllPObj c1DropWObj

Description

Group input showing the number of objects in the object queue. These objects are registered by the synchronization switch and have not been dropped.

Digital output that removes the first pending object from the object queue.

Pending objects are objects that are in the queue but are not connected to a work object.

Digital output that removes all pending objects. If an object is connected, then it is not removed.

Digital output that will cause the encoder interface unit to drop the tracked object and disconnect it. The object is removed from the queue.

Do not use c1DropWObj in RAPID code. Use the

DropWobj instruction instead.








This is an overview of all instructions, functions, and data types in Machine

Synchronization.



Instructions

Instructions

DropSensor

Description

Drop object on sensor

PrxActivAndStoreRecord

Activate and store the recorded profile data

PrxActivRecord

PrxDbgStoreRecord

Activate the recorded profile data

Store and debug the recorded profile data

PrxDeactRecord

PrxResetPos

PrxResetRecords

PrxSetPosOffset

Deactivate a record

Reset the zero position of the sensor

Reset and deactivate all records

Set a reference position for the sensor

PrxSetRecordSampleTime

Set the sample time for recording a profile

PrxSetSyncalarm

PrxStartRecord

PrxStopRecord

Set sync alarm behavior

Record a new profile

Stop recording a profile

PrxStoreRecord

PrxUseFileRecord

SupSyncSensorOff

SupSyncSensorOn

SyncToSensor

WaitSensor

Store the recorded profile data

Use the recorded profile data

Stop synchronized sensor supervision

Start synchronized sensor supervision

Sync to sensor

Wait for connection on sensor

Functions

Functions

PrxGetMaxRecordpos

Description

Get the maximum sensor position

Data types

Machine Synchronization includes no data types.




215


5 Motion Events

5.1.1 Overview

5 Motion Events

5.1 World Zones [608-1]

5.1.1 Overview

Purpose

The purpose of World Zones is to stop the robot or set an output signal if the robot is inside a special user-defined zone. Here are some examples of applications:

• When two robots share a part of their respective work areas. The possibility of the two robots colliding can be safely eliminated by World Zones supervision.

• When a permanent obstacle or some temporary external equipment is located inside the robot’s work area. A forbidden zone can be created to prevent the robot from colliding with this equipment.

• Indication that the robot is at a position where it is permissible to start program execution from a Programmable Logic Controller (PLC).

A world zone is supervised during robot movements both during program execution and jogging. If the robot’s TCP reaches the world zone or if the axes reaches the world zone in joints, the movement is stopped or a digital output signal is set.

WARNING

For safety reasons, this software shall not be used for protection of personnel.

Use hardware protection equipment for that.


The RobotWare option World Zones gives you access to:

• instructions used to define volumes of various shapes

• instructions used to define joint zones in coordinates for axes

• instructions used to define and enable world zones

Basic approach

This is the general approach for setting up World Zones. For a more detailed example of how this is done, see

Code examples on page 221

.

1 Declare the world zone as stationary or temporary.

2 Declare the shape variable.

3 Define the shape that the world zone shall have.

4 Define the world zone (that the robot shall stop or that an output signal shall be set when reaching the volume).





217

5 Motion Events

5.1.1 Overview

Continued

Limitations

Supervision of a volume only works for the TCP. Any other part of the robot may pass through the volume undetected. To be certain to prevent this, you can supervise a joint world zone (defined by

WZLimJointDef or

WZHomeJointDef

).

A variable of type wzstationary or wztemporary can not be redefined. They can only be defined once (with

WZLimSup or

WZDOSet

).




5 Motion Events



Data types

This is a brief description of each data type in World Zones. For more information, see respective data type in Technical reference manual - RAPID Instructions,


Data type

wztemporary wzstationary shapedata

Description

wztemporary is used to identify a temporary world zone and can be used anywhere in the RAPID program.

Temporary world zones can be disabled, enabled again, or erased via RAPID instructions. Temporary world zones are automatically erased when a new program is loaded or when program execution start from the beginning in the MAIN routine.

wzstationary is used to identify a stationary world zone and can only be used in an event routine connected to the event POWER ON.

For information on defining event routines, see Operating manual - IRC5 with FlexPendant.

A stationary world zone is always active and is reactivated by a restart

(switch power off then on, or change system parameters). It is not possible to disable, enable or erase a stationary world zone via

RAPID instructions.

Stationary world zones shall be used if security is involved.

shapedata is used to describe the geometry of a world zone.

World zones can be defined in 4 different geometrical shapes:

• a straight box, with all sides parallel to the world coordinate system

• a cylinder, parallel to the z axis of the world coordinate system

• a sphere

• a joint angle area for the robot axes and/or external axes

Instructions

This is a brief description of each instruction in World Zones. For more information, see respective instruction in Technical reference manual - RAPID Instructions,


Instruction

WZBoxDef

WZCylDef

WZSphDef

Description

WZBoxDef is used to define a volume that has the shape of a straight box with all its sides parallel to the axes of the world coordinate system. The definition is stored in a variable of type shapedata

.

The volume can also be defined as the inverse of the box (all volume outside the box).

WZCylDef is used to define a volume that has the shape of a cylinder with the cylinder axis parallel to the z-axis of the world coordinate system. The definition is stored in a variable of type shapedata

.

The volume can also be defined as the inverse of the cylinder (all volume outside the cylinder).

WZSphDef is used to define a volume that has the shape of a sphere.

The definition is stored in a variable of type shapedata

.

The volume can also be defined as the inverse of the sphere (all volume outside the sphere).





5 Motion Events


Continued

Instruction

WZLimJointDef

WZHomeJointDef

WZLimSup

WZDOSet

WZDisable

WZEnable

WZFree

Description

WZLimJointDef is used to define joint coordinate for axes, to be used for limitation of the working area. Coordinate limits can be set for both the robot axes and external axes.

For each axis

WZLimJointDef defines an upper and lower limit. For rotational axes the limits are given in degrees and for linear axes the limits are given in mm.


.

WZHomeJointDef is used to define joint coordinates for axes, to be used to identify a position in the joint space. Coordinate limits can be set for both the robot axes and external axes.

For each axis

WZHomeJointDef defines a joint coordinate for the middle of the zone and the zones delta deviation from the middle. For rotational axes the coordinates are given in degrees and for linear axes the coordinates are given in mm.


.

WZLimSup is used to define, and enable, stopping the robot with an error message when the TCP reaches the world zone. This supervision is active both during program execution and when jogging.

When calling

WZLimSup you specify whether it is a stationary world zone, stored in a wzstationary variable, or a temporary world zone, stored in a wztemporary variable.

WZDOSet is used to define, and enable, setting a digital output signal when the TCP reaches the world zone.

When calling

WZDOSet you specify whether it is a stationary world zone, stored in a wzstationary variable, or a temporary world zone, stored in a wztemporary variable.

WZDisable is used to disable the supervision of a temporary world zone.

WZEnable is used to re-enable the supervision of a temporary world zone.

A world zone is automatically enabled on creation. Enabling is only necessary after it has been disabled with

WZDisable

.

WZFree is used to disable and erase a temporary world zone.

Functions

World Zones does not include any RAPID functions.




5 Motion Events

5.1.3 Code examples


Create protected box

To prevent the robot TCP from moving into stationary equipment, set up a stationary world zone around the equipment.

The routine my_power_on should then be connected to the event POWER ON.

For information on how to do this, read about defining event routines in Operating manual - IRC5 with FlexPendant.

xx0300000178

VAR wzstationary obstacle;

PROC my_power_on()

VAR shapedata volume;

CONST pos p1 := [200, 100, 100];

CONST pos p2 := [600, 400, 400];

!Define a box between the corners p1 and p2

WZBoxDef \Inside, volume, p1, p2;

!Define and enable supervision of the box

WZLimSup \Stat, obstacle, volume;

ENDPROC

Signal when robot is in position

When two robots share a work area it is important to know when a robot is out of the way, letting the other robot move freely.

This example defines a home position where the robot is in a safe position and sets an output signal when the robot is in its home position. The robot is standing on a travel track, handled as external axis 1. No other external axes are active.





221

5 Motion Events

5.1.3 Code examples

Continued

The shadowed area in the illustration shows the world zone.

222 xx0300000206

VAR wztemporary home;

PROC zone_output()

VAR shapedata joint_space;

!Define the home position

CONST jointtarget home_pos := [[0, -20, 0, 0, 0, 0], [0, 9E9,

9E9, 9E9, 9E9, 9E9]];

!Define accepted deviation from the home position

CONST jointtarget delta_pos := [[2, 2, 2, 2, 2, 2], [10, 9E9,

9E9, 9E9, 9E9, 9E9]];

!Define the shape of the world zone

WZHomeJointDef \Inside, joint_space, home_pos, delta_pos;

!Define the world zone, setting the

!signal do_home to 1 when in zone

WZDOSet \Temp, home \Inside, joint_space, do_home, 1;

ENDPROC




6 Motion functions

6.1.1 Overview


6.1 Independent Axes [610-1]

6.1.1 Overview

Purpose

The purpose of Independent Axes is to move an axis independently of other axes in the robot system. Some examples of applications are:

• Move an external axis holding an object (for example rotating an object while the robot is spray painting it).

• Save cycle time by performing a robot task at the same time as an external axis performs another.

• Continuously rotate robot axis 6 (for polishing or similar tasks).

• Reset the measurement system after an axis has rotated multiple revolutions in the same direction. Saves cycle time compared to physically winding back.

An axis can move independently if it is set to independent mode. An axis can be changed to independent mode and later back to normal mode again.


The RobotWare option Independent Axes gives you access to:

• instructions used to set independent mode and specify the movement for an axis

• an instruction for changing back to normal mode and/or reset the measurement system

• functions used to verify the status of an independent axis

• system parameters for configuration.

Basic approach

This is the general approach for moving an axis independently. For detailed examples of how this is done, see


.

1 Call an independent move instruction to set the axis to independent mode and move it.

2 Let the robot execute another instruction at the same time as the independent axis moves.

3 When both robot and independent axis has stopped, reset the independent axis to normal mode.

Reset axis

Even without being in independent mode, an axis might rotate only in one direction and eventually loose precision. The measurement system can then be reset with the instruction

IndReset

.

The recommendation is to reset the measurement system for an axis before its motor has rotated 10000 revolutions in the same direction.






6.1.1 Overview

Continued

Limitations

A mechanical unit may not be deactivated when one of its axes is in independent mode.

Axes in independent mode cannot be jogged.

The only robot axis that can be used as an independent axis is axis number 6. On

IRB 1600, 2600 and 4600 models (except ID version), the instruction

IndReset can also be used for axis 4.








This is a brief description of each parameter in Independent Axes. For more information, see the respective parameter in Technical reference manual - System parameters.

Arm

These parameters belongs to the type Arm in the topic Motion.


Independent Joint Flag that determines if independent mode is allowed for the axis.

Independent Upper

Joint Bound

Defines the upper limit of the working area for the joint when operating in independent mode.

Independent Lower

Joint Bound

Defines the lower limit of the working area for the joint when operating in independent mode.

Transmission

These parameters belong to the type Transmission in the topic Motion.


Transmission Gear

High

Independent Axes requires high resolution in transmission gear ratio, which is therefore defined as Transmission Gear High divided by

Transmission Gear Low. If no smaller number can be used, the transmission gear ratio will be correct if Transmission Gear High is set to the number of cogs on the robot axis side, and Transmission

Gear Low is set to the number of cogs on the motor side.

Transmission Gear

Low

See Transmission Gear High.




225




Data types

There are no data types for Independent Axes.

Instructions

This is a brief description of each instruction in Independent Axes. For more information, see respective instruction in Technical reference manual - RAPID


An independent move instruction is executed immediately, even if the axis is being moved at the time. If a new independent move instruction is executed before the last one is finished, the new instruction immediately overrides the old one.

Instruction

IndAMove

IndCMove

IndDMove

IndRMove

IndReset

Description

IndAMove

(Independent Absolute position Movement) change an axis to independent mode and move the axis to a specified position.

IndCMove

(Independent Continuous Movement) change an axis to independent mode and start moving the axis continuously at a specified speed.

IndDMove

(Independent Delta position Movement) change an axis to independent mode and move the axis a specified distance.

IndRMove

(Independent Relative position Movement) change a rotational axis to independent mode and move the axis to a specific position within one revolution.

Because the revolution information in the position is omitted,

IndRMove never rotates more than one axis revolution.

IndReset is used to change an independent axis back to normal mode.

IndReset can move the measurement system for a rotational axis a number of axis revolutions. The resolution of positions is decreased when moving away from logical position 0, and winding the axis back would take time. By moving the measurement system the resolution is maintained without physically winding the axis back.

Both the independent axis and the robot must stand still when calling

IndReset

.

Functions

This is a brief description of each function in Independent Axes. For more information, see respective function in Technical reference manual - RAPID


Function

IndInpos

IndSpeed

Description

IndInpos indicates whether an axis has reached the selected position.

IndSpeed indicates whether an axis has reached the selected speed.





6.1.4 Code examples


Save cycle time

An object in station A needs welding in two places. The external axis for station A can turn the object in position for the second welding while the robot is welding on another object. This saves cycle time compared to letting the robot wait while the external axis moves.

!Perform first welding in station A

!Call subroutine for welding weld_stationA_1;

!Move the object in station A, axis 1, with

!independent movement to position 90 degrees

!at the speed 20 degrees/second

IndAMove Station_A,1\ToAbsNum:=90,20;

!Let the robot perform another task while waiting

!Call subroutine for welding weld_stationB_1;

!Wait until the independent axis is in position

WaitUntil IndInpos(Station_A,1 ) = TRUE;

WaitTime 0.2;

!Perform second welding in station A

!Call subroutine for welding weld_stationA_2;

Polish by rotating axis 6

To polish an object the robot axis 6 can be set to continuously rotate.

Set robot axis 6 to independent mode and continuously rotate it. Move the robot over the area you want to polish. Stop movement for both robot and independent axis before changing back to normal mode. After rotating the axis many revolutions, reset the measurement system to maintain the resolution.

Note that, for this example to work, the parameter Independent Joint for rob1_6 must be set to Yes.

PROC Polish()

!Change axis 6 of ROB_1 to independent mode and

!rotate it with 180 degrees/second

IndCMove ROB_1, 6, 180;

!Wait until axis 6 is up to speed

WaitUntil IndSpeed(ROB_1,6\InSpeed);

WaitTime 0.2;

!Move robot where you want to polish

MoveL p1,v10, z50, tool1;

MoveL p2,v10, fine, tool1;






6.1.4 Code examples

Continued

Reset an axis

!Stop axis 6 and wait until it's still

IndCMove ROB_1, 6, 0;

WaitUntil IndSpeed(ROB_1,6\ZeroSpeed);

WaitTime 0.2;

!Change axis 6 back to normal mode and

!reset measurement system (close to 0)

IndReset ROB_1, 6 \RefNum:=0 \Short;

ENDPROC

This is an example of how to reset the measurement system for axis 1 in station

A. The measurement system will change a whole number of revolutions, so it is close to zero (±180°).

IndReset Station_A, 1 \RefNum:=0 \Short;





6.2.1 Overview

6.2 Path Recovery [611-1]

6.2.1 Overview

Purpose

Path Recovery is used to store the current movement path, perform some robot movements and then restore the interrupted path. This is useful when an error or interrupt occurs during the path movement. An error handler or interrupt routine can perform a task and then recreate the path.

For applications like arc welding and gluing, it is important to continue the work from the point where the robot left off. If the robot started over from the beginning, then the work piece would have to be scrapped.

If a process error occurs when the robot is inside a work piece, moving the robot straight out might cause a collision. By using the path recorder, the robot can instead move out along the same path it came in.


The RobotWare option Path Recovery gives you access to:

• instructions to suspend and resume the coordinated synchronized movement mode on the error or interrupt level.

• a path recorder, with the ability to move the TCP out from a position along the same path it came.

Limitations

The instructions

StorePath and

RestoPath only handles movement path data.

The stop position must also be stored.

Movements using the path recorder has to be performed on trap-level, i.e.

StorePath has to be executed prior to

PathRecMoveBwd

.




229




Data types

This is a brief description of each data type in Path Recovery. For more information, see the respective data type in Technical reference manual - RAPID Instructions,


Data type

pathrecid

Description

pathrecid is used to identify a breakpoint for the path recorder.

Instructions

This is a brief description of each instruction in Path Recovery. For more information, see the respective instruction in Technical reference manual - RAPID


Instruction

StorePath

RestoPath

PathRecStart

PathRecStop

Description

StorePath is used to store the movement path being executed when an error or interrupt occurs.

StorePath is included in RobotWare base.

RestoPath is used to restore the path that was stored by

StorePath

.

RestoPath is included in RobotWare base.

PathRecStart is used to start recording the robot’s path. The path recorder will store path information during execution of the robot program.

PathRecStop is used to stop recording the robot's path.

PathRecMoveBwd

PathRecMoveFwd

PathRecMoveBwd is used to move the robot backwards along a recorded path.

PathRecMoveFwd is used to move the robot back to the position where

PathRecMoveBwd was executed.

It is also possible to move the robot partly forward by supplying an identifier that has been passed during the backward movement.

SyncMoveSuspend

SyncMoveSuspend is used to suspend synchronized movements mode and set the system to independent movement mode.

SyncMoveResume

SyncmoveResume is used to go back to synchronized movements from independent movement mode.

Functions

This is a brief description of each function in Path Recovery. For more information, see the respective function in Technical reference manual - RAPID Instructions,


Function

PathRecValidBwd

PathRecValidFwd

Description

PathRecValidBwd is used to check if the path recorder is active and if a recorded backward path is available.

PathRecValidFwd is used to check if the path recorder can be used to move forward. The ability to move forward with the path recorder implies that the path recorder must have been ordered to move backwards earlier.





6.2.3 Store current path

6.2.3 Store current path

Why store the path?

The simplest way to use Path Recovery is to only store the current path to be able to restore it after resolving an error or similar action.

Let's say that an error occur during arc welding. To resolve the error the robot might have to be moved away from the part. When the error is resolved, the welding should be continued from the point it left off. This is solved by storing the path information and the position of the robot before moving away from the path. The path can then be restored and the welding resumed after the error has been handled.

Basic approach

This is the general approach for storing the current path:

1 At the start of an error handler or interrupt routine: stop the movement store the movement path store the stop position

2 At the end of the error handler or interrupt routine: move to the stored stop position restore the movement path start the movement

Example

This is an example of how to use Path Recovery in error handling. First the path and position is stored, the error is corrected and then the robot is moved back in position and the path is restored.

MoveL p100, v100, z10, gun1;

...

ERROR

IF ERRNO=MY_GUN_ERR THEN gun_cleaning();

ENDIF

...

PROC gun_cleaning()

VAR robtarget p1;

!Stop the robot movement, if not already stopped.

StopMove;

!Store the movement path and current position

StorePath; p1 := CRobT(\Tool:=gun1\WObj:=wobj0);

!Correct the error

MoveL pclean, v100, fine, gun1;







Continued

...

!Move the robot back to the stored position

MoveL p1, v100, fine, gun1;

!Restore the path and start the movement

RestoPath;

StartMove;

RETRY;

ENDPROC

Store path in a MultiMove system

In a MultiMove system the robots can keep the synchronized movement mode after

StorePath with the argument

KeepSync

. However the robots can’t switch from independent mode to synchronized mode, only the other way around.

After a Multimove system is set with the argument

KeepSync

, the system can change between synchronized, semi coordinated and independent mode on the

StorePath level. The changes are made with the instructions

SyncMoveResume and

SyncMoveSuspend.

“SyncArc” example with coordinated synchronized movement

This is an example on how to use Path Recovery and keep synchronized mode in the error handler for a MultiMove system. Two robots perform arc welding on the same work piece. To make the example simple and general, we use move instructions instead of weld instructions. The work object is rotated by a positioner.

For more information on the SyncArc example, see Application manual - MultiMove.

T_ROB1 task program

MODULE module1

VAR syncident sync1;



PERS tasks all_tasks{3} := [["T_ROB1"],["T_ROB2"],["T_STN1"]];

PERS wobjdata wobj_stn1 := [ FALSE, FALSE, "STN_1", [ [0, 0, 0],

[1, 0, 0 ,0] ], [ [0, 0, 250], [1, 0, 0, 0] ] ];

TASK PERS tooldata tool1 := ...

CONST robtarget p100 := ...


PROC main()

...

SyncMove;

ENDPROC

PROC SyncMove()

MoveJ p100, v1000, z50, tool1;

WaitSyncTask sync1, all_tasks;


SyncMoveOn sync2, all_tasks;

MoveL p102\ID:=10, v300, z10, tool1 \WObj:=wobj_stn1;

MoveC p103, p104\ID:=20, v300, z10, tool1 \WObj:=wobj_stn1;








Continued

MoveC p106, p101\ID:=40, v300, fine, tool1 \WObj:=wobj_stn1;

SyncMoveOff sync3;


ERROR

IF ERRNO = ERR_PATH_STOP THEN gun_cleaning();

ENDIF

UNDO

SyncMoveUndo;

ENDPROC

PROC gun_cleaning()

VAR robtarget p1;


! and keep syncronized mode.

StorePath \KeepSync; p1 := CRobT(\Tool:=tool1 \WObj:=wobj_stn1);

!Correct the error

MoveL pclean1 \ID:=50, v100, fine, tool1 \WObj:=wobj_stn1;

...


MoveL p1 \ID:=60, v100, fine, tool1 \WObj:=wobj_stn1;


RestoPath;

StartMove;

RETRY;

ENDPROC

ENDMODULE


MODULE module2




PERS tasks all_tasks{3};

PERS wobjdata wobj_stn1;




PROC main()

...

SyncMove;

ENDPROC

PROC SyncMove()














Continued


SyncMoveOff sync3;


ERROR


ENDIF

UNDO

SyncMoveUndo;

ENDPROC

PROC gun_cleaning()

VAR robtarget p2;

!Store the movement path and current position.


!Correct the error

MoveL pclean2 \ID:=50, v100, fine, tool2 \WObj:=wobj_stn1;

...

!Move the robot back to the stored position.



RestoPath;

StartMove;

RETRY;

ENDPROC

ENDMODULE

T_STN1 task program

MODULE module3





CONST jointtarget angle_neg20 :=[ [ 9E9, 9E9, 9E9, 9E9, 9E9,

9E9], [ -20, 9E9, 9E9, 9E9, 9E9, 9E9] ];

...

CONST jointtarget angle_340 :=[ [ 9E9, 9E9, 9E9, 9E9, 9E9, 9E9],[

340, 9E9, 9E9, 9E9, 9E9, 9E9] ];

PROC main()

...

SyncMove;

...

ENDPROC

PROC SyncMove()

MoveExtJ angle_neg20, vrot50, fine;


! Wait for the robots


MoveExtJ angle_20\ID:=10, vrot100, z10;









Continued

MoveExtJ angle_340\ID:=40, vrot100, fine;

SyncMoveOff sync3;

ERROR


ENDIF

UNDO

SyncMoveUndo;

ENDPROC

PROC gun_cleaning()

VAR jointtarget resume_angle;

!Store the movement path and current angle.

StorePath \KeepSync; resume_angle := CJointT();

!Correct the error

MoveExtJ clean_angle \ID:=50, vrot100, fine;

...


MoveExtJ resume_angle \ID:=60, vrot100, fine;


RestoPath;

StartMove;

RETRY;

ENDPROC

ENDMODULE

Suspend and resume synchronized movements in the “SyncArc” example

SyncMoveSuspend is used to suspend synchronized movements mode and set the system to independent or semi coordinated movement mode.

SyncMoveResume is used to go back once more to synchronized movements.

These instructions can only be used after

StorePath\KeepSync has been executed.

T_ROB1

PROC gun_cleaning()

VAR robtarget p1;


! and keep syncronized mode.


!Move in synchronized motion mode


SyncMoveSuspend;

!Move in independent mode

MoveL pclean1, v100, fine, tool1;

...


SyncMoveResume;









Continued

T_ROB2

T_STN1

RestoPath;

StartMove;

RETRY;

ENDPROC

PROC gun_cleaning()

VAR robtarget p2;

!Store the movement path and current position.




SyncMoveSuspend;

!Move in independent mode

MoveL pclean2 v100, fine, tool2;

...


SyncMoveResume;




RestoPath;

StartMove;

RETRY;

ENDPROC

PROC gun_cleaning()

VAR jointtarget resume_angle;

!Store the movement path and current angle.

StorePath \KeepSync; resume_angle := CJointT();


MoveExtJ p1clean_angle \ID:=50, vrot100, fine;

SyncMoveSuspend;

! Move in independent mode

MoveExtJ p2clean_angle,vrot, fine;

...


SyncMoveResume;

! Move in synchronized motion mode

MoveExtJ resume_angle \ID:=60, vrot100, fine;


RestoPath;

StartMove;

RETRY;

ENDPROC





6.2.4 Path recorder

6.2.4 Path recorder

What is the path recorder

The path recorder can memorize a number of move instructions. This memory can then be used to move the robot backwards along that same path.

How to use the path recorder

This is the general approach for using the path recorder:

1 Start the path recorder

2 Move the robot with regular move, or process, instructions

3 Store the current path

4 Move backwards along the recorded path

5 Resolve the error

6 Move forward along the recorded path

7 Restore the interrupted path

Lift the tool

When the robot moves backward in its own track, you may want to avoid scraping the tool against the work piece. For a process like arc welding, you want to stay clear of the welding seam.

By using the argument

ToolOffs in the instructions

PathRecMoveBwd and

PathRecMoveFwd

, you can set an offset for the TCP. This offset is set in tool coordinates, which means that if it is set to [0,0,10] the tool will be 10mm from the work object when it moves back along the recorded path.

xx0400000828

Note

When a MultiMove system is in synchronized mode all tasks must use

ToolOffs if a tool is going to be lifted.

However if you only want to lift one tool, set

ToolOffs=[0,0,0] in the other tasks.

Simple example

If an error occurs between p1 and p4, the robot will return to p1 where the error can be resolved. When the error has been resolved, the robot continues from where the error occurred.






6.2.4 Path recorder

Continued

When p4 is reached without any error, the path recorder is switched off. The robot then moves from p4 to p5 without the path recorder.

...

VAR pathrecid start_id;

...

MoveL p1, vmax, fine, tool1;

PathRecStart start_id;

MoveL p2, vmax, z50, tool1;



PathRecStop \Clear;


ERROR

StorePath;

PathRecMoveBwd;

! Fix the problem

PathRecMoveFwd;

RestoPath;

StartMove;

RETRY;

ENDIF

...

Complex example

In this example, the path recorder is used for two purposes:

• If an error occurs, the operator can choose to back up to p1 or to p2. When the error has been resolved, the interrupted movement is resumed.

• Even if no error occurs, the path recorder is used to move the robot from p4 to p1. This technique is useful when the robot is in a narrow position that is difficult to move out of.

Note that if an error occurs during the first move instruction, between p1 and p2, it is not possible to go backwards to p2. If the operator choose to go back to p2,

PathRecValidBwd is used to see if it is possible. Before the robot is moved forward to the position where it was interrupted,

PathRecValidFwd is used to see if it is possible (if the robot never backed up it is already in position).

...

VAR pathrecid origin_id;

VAR pathrecid corner_id;

VAR num choice;

...

MoveJ p1, vmax, z50, tool1;

PathRecStart origin_id;

MoveJ p2, vmax, z50, tool1;

PathRecStart corner_id;



! Use path record to move safely to p1






6.2.4 Path recorder

Continued

StorePath;

PathRecMoveBwd \ID:=origin_id

\ToolOffs:=[0,0,10];

RestoPath;

PathRecStop \Clear;

Clear Path;

Start Move;

ERROR

StorePath;

! Ask operator how far to back up

TPReadFK choice,"Extract to:", stEmpty, stEmpty, stEmpty, "Origin", "Corner";

IF choice=4 THEN

! Back up to p1

PathRecMoveBwd \ID:=origin_id


ELSEIF choice=5 THEN

! Verify that it is possible to back to p2,

IF PathRecValidBwd(\ID:=corner_id) THEN

! Back up to p2

PathRecMoveBwd \ID:=corner_id


ENDIF

ENDIF

! Fix the problem

! Verify that there is a path record forward

IF PathRecValidFwd() THEN

! Return to where the path was interrupted

PathRecMoveFwd \ToolOffs:=[0,0,10];

ENDIF

! Restore the path and resume movement

RestoPath;

StartMove;

RETRY;

...

Resume path recorder

If the path recorder is stopped, it can be started again from the same position without loosing its history.

In the example below, the

PathRecMoveBwd instruction will back the robot to p1.

If the robot had been in any other position than p2 when the path recorder was restarted, this would not have been possible.






6.2.4 Path recorder

Continued

For more information, see the section about

PathRecStop in Technical reference manual - RAPID Instructions, Functions and Data types.

...


PathRecStart id1;


PathRecStop;




PathRecStart id2;


StorePath;

PathRecMoveBwd \ID:=id1;

RestoPath;

...

"SyncArc" example with coordinated synchronized movement

This is an example on how to use Path Recorder in error handling for a MultiMove system.

In this example two robots perform arc welding on the same work piece. To make the example simple and general, we use move instructions instead of weld instructions. The work object is rotated by a positioner.

For more information on the SyncArc example, see Application manual - MultiMove.


MODULE module1




PERS tasks all_tasks{3} := [["T_ROB1"],["T_ROB2"],["T_STN1"]];

PERS wobjdata wobj_stn1 := [ FALSE, FALSE, "STN_1",[ [0, 0, 0],

[1, 0, 0 ,0] ], [ [0, 0,250], [1, 0, 0, 0] ] ];




PROC main()

...

SyncMove;

ENDPROC

PROC SyncMove()



! Start recording

PathRecStart HomeROB1;










6.2.4 Path recorder

Continued



!Stop recording

PathRecStop \Clear;

SyncMoveOff sync3;


ERROR

! Weld error in this program task

IF ERRNO = AW_WELD_ERR THEN gun_cleaning();

ENDIF

UNDO

SyncMoveUndo;

ENDPROC

PROC gun_cleaning()

VAR robtarget p1;

!Store the movement path

IF IsSyncMoveOn() THEN

StorePath \KeepSync;

ELSE

StorePath;

ENDIF

!Move this robot backward to p100.

PathRecMoveBwd \ID:=HomeROB1 \ToolOffs:=[0,0,10];

!Correct the error

MoveJ pclean1 ,v100, fine, tool1;

...

!Move the robot back to p100

MoveJ p100, v100, fine, tool1;



RestoPath;

StartMove;

RETRY;

ENDPROC

ENDMODULE


MODULE module2





PERS wobjdata wobj_stn1;




PROC main()

...

SyncMove;

ENDPROC






6.2.4 Path recorder

Continued

PROC SyncMove()



PathRecStart HomeROB2;







PathRecStop \Clear;

SyncMoveOff sync3;


ERROR

IF ERRNO = ERR_PATH_STOP THEN gun_move_out();

ENDIF

UNDO

SyncMoveUndo;

ENDPROC

PROC gun_move_out()



ELSE

StorePath;

ENDIF

! Move this robot backward to p201

PathRecMoveBwd \ToolOffs:=[0,0,10];

! Wait for the other gun to get clean



RestoPath;

StartMove;

RETRY;

ENDPROC

ENDMODULE

T_STN1 task program

MODULE module3





CONST jointtarget angle_neg20 :=[ [ 9E9, 9E9, 9E9, 9E9, 9E9,

9E9], [ -20, 9E9, 9E9, 9E9, 9E9, 9E9] ];

...

CONST jointtarget angle_340 :=[ [ 9E9, 9E9, 9E9, 9E9, 9E9, 9E9],[

340, 9E9, 9E9, 9E9,9E9, 9E9] ];

PROC main()

...

SyncMove;






6.2.4 Path recorder

Continued

...

ENDPROC

PROC SyncMove()


MoveExtJ angle_neg20, vrot50, fine;

PathRecStart HomeSTN1;





MoveExtJ angle_340\ID:=40, vrot100, fine;

PathRecStop \Clear;

SyncMoveOff sync3;

ERROR

IF ERRNO = ERR_PATH_STOP THEN gun_move_out();

ENDIF

UNDO

SyncMoveUndo;

ENDPROC

PROC gun_move_out()

!Store the movement



ELSE

StorePath;

ENDIF

!Move the manipulator backward to angle_neg 20

PathRecMoveBwd \ToolOffs:=[0,0,0];

...

!Wait for the gun to get clean


RestoPath;

StartMove;

RETRY;

ENDPROC




243


6.3.1 Overview

6.3 Path Offset [612-1]

6.3.1 Overview

Purpose

The purpose of Path Offset is to be able to make online adjustments of the robot path according to input from sensors. With the set of instructions that Path Offset offers, the robot path can be compared and adjusted with the input from sensors.


The RobotWare option Path Offset gives you access to:

• the data type corrdescr

• the instructions

CorrCon

,

CorrDiscon

,

CorrClear and

CorrWrite

• the function

CorrRead

Basic approach

This is the general approach for setting up Path Offset. For a detailed example of how this is done, see

Code example on page 247

.

1 Declare the correction generator.

2 Connect the correction generator.

3 Define a trap routine that determines the offset and writes it to the correction generator.

4 Define an interrupt to frequently call the trap routine.

5 Call a move instruction using the correction. The path will be repeatedly corrected.

Note

If two or more move instructions are called after each other with the

\Corr switch it is important to know that all

\Corr offsets are reset each time the robot starts from a finepoint. So ,when using finepoints, on the second move instruction the controller does not know that the path already has an offset. To avoid any strange behavior it is recommended only to use zones together with the

\Corr switch and avoid finepoints.

Limitations

It is possible to connect several correction generators at the same time (for instance one for corrections along the Z axis and one for corrections along the Y axis).

However, it is not possible to connect more than 5 correction generators at the same time.

After a controller restart, the correction generators have to be defined once again.

The definitions and connections do not survive a controller restart.

The instructions can only be used in motion tasks.







Data types

This is a brief description of each data type in Path Offset. For more information, see the respective data type in Technical reference manual - RAPID Instructions,


Data type

corrdescr

Description

corrdescr is a correction generator descriptor that is used as the reference to the correction generator.

Instructions

This is a brief description of each instruction in Path Offset. For more information, see the respective instruction in Technical reference manual - RAPID Instructions,


Instruction

CorrCon

CorrDiscon

CorrClear

CorrWrite

Description

CorrCon activates path correction. Calling

CorrCon will connect a correction generator. Once this connection is made, the path can be continuously corrected with new offset inputs (for instance from a sensor).

CorrDiscon deactivates path correction. Calling

CorrDiscon will disconnect a correction generator.

CorrClear deactivate path correction. Calling

CorrClear will disconnect all correction generators.

CorrWrite sets the path correction values. Calling

CorrWrite will set the offset values to a correction generator.

Functions

This is a brief description of each function in Path Offset. For more information, see the respective function in Technical reference manual - RAPID Instructions,


Function

CorrRead

Description

CorrRead reads the total correction made by a correction generator.




245


6.3.3 Related RAPID functionality

6.3.3 Related RAPID functionality

The argument \Corr

The optional argument

\Corr can be set for some move instructions. This will enable path corrections while the move instruction is executed.

The following instructions have the optional argument

\Corr

:

• MoveL

• MoveC

• SearchL

• SearchC

• TriggL (only if the controller is equipped with the base functionality Fixed

Position Events)

• TriggC (only if the controller is equipped with the base functionality Fixed

Position Events)

• CapL (only if the controller is equipped with the option Continuous Application

Platform)

• CapC (only if the controller is equipped with the option Continuous Application

Platform)

• ArcL (only if the controller is equipped with the option RobotWare Arc)

• ArcC (only if the controller is equipped with the option RobotWare Arc)

For more information on these instructions, see respective instruction in Technical reference manual - RAPID Instructions, Functions and Data types.

Interrupts

To create programs using Path Offset, you need to be able to handle interrupts.

For more information on interrupts, see Technical reference manual - RAPID overview.





6.3.4 Code example


Linear movement with correction

This is a simple example of how to program a linear path with online path correction.

This is done by having an interrupt 5 times per second, calling a trap routine which makes the offset correction.

Program code

VAR intnum int_no1;

VAR corrdescr id;

VAR pos sens_val;

PROC PathRoutine()

!Connect to the correction generator

CorrCon id;

!Setup a 5 Hz timer interrupt.

CONNECT int_no1 WITH UpdateCorr;

ITimer\Single, 0.2, int_no1

!Position for start of contour tracking

MoveJ p10,v100,z10,tool1;

!Run MoveL with correction.

MoveL p20,v100,z10,tool1\Corr;

!Remove the correction generator.

CorrDiscon id;

!Remove the timer interrupt.

IDelete int_no1;

ENDPROC

TRAP UpdateCorr

!Call a routine that read the sensor

ReadSensor sens_val.x, sens_val.y, sens_val.z;

!Execute correction

CorrWrite id, sens_val;

!Setup interrupt again

IDelete int_no1;

CONNECT int_no1 WITH UpdateCorr;

ITimer\Single, 0.2, int_no1;

ENDTRAP




247


7 Motion Supervision

7.1.1 Overview


7.1 Collision Detection [613-1]

7.1.1 Overview

Purpose

Collision Detection is a software option that reduces collision impact forces on the robot. This helps protecting the robot and external equipment from severe damage.

WARNING

Collision Detection cannot protect equipment from damage at a full speed collision.

Description

The software option Collision Detection identifies a collision by high sensitivity, model based supervision of the robot. Depending on what forces you deliberately apply on the robot, the sensitivity can be tuned as well as turned on and off.

Because the forces on the robot can vary during program execution, the sensitivity can be set on-line in the program code.

Collision detection is more sensitive than the ordinary supervision and has extra features. When a collision is detected, the robot will immediately stop and relieve the residual forces by moving in reversed direction a short distance along its path.

After a collision error message has been acknowledged, the movement can continue without having to press Motors on on the controller.


The RobotWare option Collision Detection gives you access to:

• system parameters for defining if Collision Detection should be active and how sensitive it should be (without the option you can only turn detection on and off for Auto mode)

• instruction for on-line changes of the sensitivity:

MotionSup

Basic approach

Collision Detection is by default always active when the robot is moving. In many cases this means that you can use Collision Detection without having to take any active measures.

If necessary, you can turn Collision Detection on and off or change its sensitivity in two ways:

• temporary changes can be made on-line with the RAPID instruction

MotionSup

• permanent changes are made through the system parameters.




249


7.1.2 Limitations


Load definition

In order to detect collisions properly, the payload of the robot must be correctly defined.

Tip

Use Load Identification to define the payload. For more information, see Operating manual - IRC5 with FlexPendant.

Robot axes only

Collision Detection is only available for the robot axes. It is not available for track motions, orbit stations, or any other external axes.

Independent joint

The collision detection is deactivated when at least one axis is run in independent joint mode. This is also the case even when it is an external axis that is run as an independent joint.

Soft servo

The collision detection may trigger without a collision when the robot is used in soft servo mode. Therefore, it is recommended to turn the collision detection off when the robot is in soft servo mode.

No change until the robot moves

If the RAPID instruction

MotionSup is used to turn off the collision detection, this will only take effect once the robot starts to move. As a result, the digital output

MotSupOn may temporarily have an unexpected value at program start before the robot starts to move.

Reversed movement distance

The distance the robot is reversed after a collision is proportional to the speed of the motion before the collision. If repeated low speed collisions occur, the robot may not be reversed sufficiently to relieve the stress of the collision. As a result, it may not be possible to jog the robot without the supervision triggering. In this case, turn Collision Detection off temporarily and jog the robot away from the obstacle.

Delay before reversed movement

In the event of a stiff collision during program execution, it may take a few seconds before the robot starts the reversed movement.

Robot on track motion

If the robot is mounted on a track motion the collision detection should be deactivated when the track motion is moving. If it is not deactivated, the collision detection may trigger when the track moves, even if there is no collision.





7.1.3 What happens at a collision

7.1.3 What happens at a collision

Overview

Collision illustration

When the collision detection is triggered, the robot will stop as quickly as possible.

Then it will move in the reverse direction to remove residual forces. The program execution will stop with an error message. The robot remains in the state motors on so that program execution can be resumed after the collision error message has been acknowledged.

A typical collision is illustrated below.

xx0300000361

Robot behavior after a collision

This list shows the order of events after a collision. For an illustration of the sequence, see the diagram below.

When ...

the collision is detected the robot has stopped the residual forces are removed

then ...

the motor torques are reversed and the mechanical brakes applied in order to stop the robot the robot moves in reversed direction a short distance along the path in order to remove any residual forces which may be present if a collision or jam occurred the robot stops again and remains in the motors on state





251


7.1.3 What happens at a collision

Continued

Speed and torque diagram

en0300000360





7.1.4 Additional information

7.1.4 Additional information

Motion error handling

For more information regarding error handling for a collision, see Technical reference manual - RAPID kernel.




253



7.1.5 Configuration and programming facilities


About system parameters

The parameters for Collision Detection do not require a restart to take effect.

For more information about the parameters, see Technical reference manual - System parameters.

Motion Supervision

These parameters belong to the type Motion Supervision in the topic Motion.

Parameter

Path Collision Detection

Jog Collision Detection

Description

Turn the collision detection On or Off for program execution.

Path Collision Detection is by default set to On.

Turn the collision detection On or Off for jogging.

Jog Collision Detection is by default set to On.

Path Collision Detection

Level

Modifies the Collision Detection supervision level for program execution by the specified percentage value. A large percentage value makes the function less sensitive.

Path Collision Detection Level is by default set to 100%.

Jog Collision Detection Level Modifies the Collision Detection supervision level for jogging by the specified percentage value. A large percentage value makes the function less sensitive.

Jog Collision Detection Level is by default set to 100%.

Collision Detection Memory Defines how much the robot moves in reversed direction on the path after a collision, specified in seconds. If the robot moved fast before the collision it will move away a larger distance than if the speed was slow.

Collision Detection Memory is by default set to 75 ms.

Manipulator Supervision

Manipulator Supervision

Level

Turns the supervision for the loose arm detection on or off for IRB 340 and IRB 360. A loose arm will stop the robot and cause an error message.

Manipulator Supervision is by default set to On.

Modifies the supervision level for the loose arm detection for the manipulators IRB 340 and IRB 360. A large value makes the function less sensitive.

Manipulator Supervision Level is by default value set to 100%.

Motion Planner

These parameters belong to the type Motion Planner in the topic Motion.

Parameter

Motion Supervision Max

Level

Description

Set the maximum level to which the total collision detection tune level can be changed. It is by default set to 300%.







Continued

General RAPID

These parameters belong to the type General RAPID in the topic Controller.

Parameter

Collision Error Handler

Description

Enables RAPID error handling for collision. Collision Error

Handler is default set to Off.

For more information regarding error handling for a collision, see Technical reference manual - RAPID kernel




255




Instructions

This is a brief description of the instructions in Collision Detection. For more information, see respective instruction in Technical reference manual - RAPID


Instruction

MotionSup

Description

MotionSup is used to:

• activate or deactivate Collision Detection. This can only be done if the parameter Path Collision Detection is set to On.

• modify the supervision level with a specified percentage value

(1-300%). A large percentage value makes the function less sensitive.





7.1.5.3 Signals

7.1.5.3 Signals

Digital outputs

This is a brief description of the digital outputs in Collision Detection. For more information, see respective digital output in Technical reference manual - System parameters.

Digital output

MotSupOn

MotSupTrigg

Description

MotSupOn is high when Collision Detection is active and low when it is not active.

Note that a change in the state takes effect when a motion starts. Thus, if Collision Detection is active and the robot is moving, MotSupOn is high. If the robot is stopped and Collision Detection turned off, Mot-

SupOn is still high. When the robot starts to move, MotSupOn switches to low.

MotSupTrigg goes high when the collision detection triggers. It stays high until the error code is acknowledged from the FlexPendant.




257


7.1.6.1 Set up system parameters

7.1.6 How to use Collision Detection

7.1.6.1 Set up system parameters

Activate supervision

To be able to use Collision Detection during program execution, the parameter

Path Collision Detection must be set to On.

To be able to use Collision Detection during jogging, the parameter Jog Collision

Detection must be set to On.

Define supervision levels

Set the parameter Path Collision Detection Level to the percentage value you want as default during program execution.

Set the parameter Jog Collision Detection Level to the percentage value you want as default during jogging.





7.1.6.2 Adjust supervision from FlexPendant

7.1.6.2 Adjust supervision from FlexPendant

Speed adjusted supervision level

Collision Detection uses a variable supervision level. At low speeds it is more sensitive than at high speeds. For this reason, no tuning of the function should be required by the user during normal operating conditions. However, it is possible to turn the function on and off and to tune the supervision levels.

Separate tuning parameters are available for jogging and program execution. These parameters are described in


.

Set jog supervision on FlexPendant

On the FlexPendant, select Control Panel from the ABB menu and then tap

Supervision.

Supervision can be turned on or off and the sensitivity can be adjusted for both programmed paths and jogging. The sensitivity level is set in percentage. A large value makes the function less sensitive.

If the motion supervision for jogging is turned off in the dialog box and a program is executed, Collision Detection can still be active during execution of the program.

Note

The supervision settings correspond to system parameters of the type Motion

Supervision. These can be set using the supervision settings on the FlexPendant, as described above. They can also be changed using RobotStudio or FlexPendant configuration editor or Quickset Mechanical unit menu.




259


7.1.6.3 Adjust supervision from RAPID program

7.1.6.3 Adjust supervision from RAPID program

Default values

If Collision Detection is activated with the system parameters, it is by default active during program execution with the tune value 100%. These values are set automatically:

• when using the restart mode Reset system.

• when a new program is loaded.

• when starting program execution from the beginning.

Note

If tune values are set in the system parameters and in the RAPID instruction, both values are taken into consideration.

Example: If the tune value in the system parameters is set to 150% and the tune value is set to 200% in the RAPID instruction the resulting tune level will be 300%.

Temporarily deactivate supervision

If external forces will affect the robot during a part of the program execution, temporarily deactivate the supervision with the following instruction:

MotionSup \Off;

Reactivate supervision

If the supervision has been temporarily deactivated, it can be activated with the following instruction:

MotionSup \On;

Note

If the supervision is deactivated with the system parameters, it cannot be activated with RAPID instructions.

Tuning

The supervision level can be tuned during program execution with the instruction

MotionSup. The tune values are set in percent of the basic tuning where 100% corresponds to the basic values. A higher percentage gives a less sensitive system.

This is an example of an instruction that increase the supervision level to 200%:

MotionSup \On \TuneValue:=200;





7.1.6.4 How to avoid false triggering

7.1.6.4 How to avoid false triggering

About false triggering

Because the supervision is designed to be very sensitive, it may trigger if the load data is incorrect or if there are large process forces acting on the robot.

Actions to take

If ...

then ...

the payload is incorrectly defined use Load Identification to define it. For more information, see

Operating manual - IRC5 with FlexPendant.

the payload has large mass or inertia increase supervision level the arm load (cables or similar) cause trigger manually define the arm load or increase supervision level the application involves many external process forces increase the supervision level for jogging and program execution in steps of 30 percent until you no longer receive the error code.

the external process forces are only temporary use the instruction

MotionSup to raise the supervision level or turn the function off temporarily.

everything else fails turn off Collision Detection.




261


8 Communication

8.1.1 Introduction to FTP Client

8 Communication

8.1 FTP Client [614-1]

8.1.1 Introduction to FTP Client

Purpose

The purpose of FTP Client is to enable the robot to access remote mounted disks, for example a hard disk drive on a PC.


• Backup to a remote computer.

• Load programs from a remote computer.

Network illustration

en0300000505

Description


The RobotWare option FTP Client gives you access to the system parameter type

Application protocol and its parameters: Name, Type, Transmission protocol, Server address, Trusted, Local path, Server path, Username, and Password

Basic approach

Several robots can access the same computer over an Ethernet network.

Once the FTP application protocol is configured, the remote computer can be accessed in the same way as the controller's internal hard disk.

This is the general approach for using FTP Client. For more detailed examples of how this is done, see

Examples on page 266 .

1 Configure an Application protocol to point out a disk or directory on a remote computer that will be accessible from the robot.





8 Communication

8.1.1 Introduction to FTP Client

Continued

2 Read and write to the remote computer in the same way as with the controller's internal hard disk.

Requirements

The external computer must have:

• TCP/IP stack

• FTP Server

Limitations

When using the FTP Client the maximum length for a file name is 99 characters.

When using the FTP Client the maximum length for a file path including the file name is 200 characters. The whole path is included in the 200 characters, not only the server path. When ordering a backup towards a mounted disk all the directories created by the backup has to be included in the max path.

Example

Parameter

Local path

Server path

Value

pc:

C:\robot_1

• A backup is saved to pc:/Backups/Backup_20130109

(27 characters)

• The path on the PC will be C:\robot_1\Backups\Backup_20130109

(34 characters)

• The longest file path inside this backup is

C:\robot_1\Backups\Backup_20130109\RAPID\TASK1\PROGMOD\myprogram.mod

(54+13 characters)

The maximum path length for this example first looks like 27 characters but is actually 67 characters.




8 Communication



Application protocol

This is a brief description of the parameters used to configure an application protocol. For more information, see the respective parameter in


These parameters belongs to the type Application protocol in the topic

Communication.

Parameter

Name

Type Type of application protocol.

Set this to "FTP".

Transmission protocol Name of the transmission protocol the protocol should use.

For FTP, this is always "TCP/IP".

Server address

Trusted

Description

Name of the application protocol.

Local path

Server path

Username

Password

The IP address of the computer with the FTP server.

This flag decides if this computer should be trusted, i.e. if losing the connection should make the program stop.

Defines what the shared unit will be called on the robot. The parameter value must end with a colon (:).

If, for example the unit is named "pc:", the name of the test.prg on this unit would be pc:test.prg

The name of the disk or folder to connect to, on the remote computer.

If not specified, the application protocol will reference the directory that is shared by the FTP server.

Note: The exported path should not be specified if communicating with an FTP server of type Distinct FTP, FileZilla or MS IIS.

The user name used by the robot when it logs on to the remote computer.

The user account must be set up on the FTP server.

The password used by the robot when it logs on to the remote computer.

Note that the password written here will be visible to all who has access to the system parameters.

Transmission protocol

There is a configured transmission protocol called TCP/IP, but no changes can be made to it. This is used by the FTP application protocol.




265

8 Communication

8.1.3 Examples

8.1.3 Examples

Example configuration

This is an example of how an application protocol can be configured for FTP.

Parameter

Name

Type

Transmission protocol

Server address

Trusted

Local path

Server path

Username

Password

Value

my FTP protocol

FTP

TCPIP1

100.100.100.100

No pc:

C:\robot_1

Robot1 robot1

Note: The value of Server path should exclude the exported path if communicating with an FTP server of type Distinct FTP, FileZilla or MS IIS.

Example with FlexPendant

This example shows how to use the FlexPendant to make a backup to the remote

PC. We assume that the configuration is done according to the example configuration shown above.

1 Tap ABB and select Backup and Restore.

2 Tap on Backup Current System.

3 Save the backup to pc:/Backup/Backup_20031008 (the path on the PC will be C:\robot_1\Backup\Backup_20031008).

Example with RAPID code

This example shows how to open the file C:\robot_1\files\file1.doc on the remote

PC from a RAPID program on the controller. We assume that the configuration is done according to the example configuration shown above.

Open "HOME:" \File:= "pc:/files/file1.doc", file;




8 Communication

8.2.1 Introduction to NFS Client

8.2 NFS Client [614-1]

8.2.1 Introduction to NFS Client

Purpose

The purpose of NFS Client is to enable the robot to access remote mounted disks, for example a hard disk drive on a PC.


• Backup to a remote computer.

• Load programs from a remote computer.

Description


The RobotWare option NFS Client gives you access to the system parameter type

Application protocol and its parameters: Name, Type, Transmission protocol, Server address, Trusted, Local path, Server path, User ID, and Group ID.

Basic approach

This is the general approach for using NFS Client. For more detailed examples of how this is done, see

Examples on page 266 .

1 Configure an Application protocol to point out a disk or directory on a remote computer that will be accessible from the robot.

2 Read and write to the remote computer in the same way as with the controller's internal hard disk.

Prerequisites

Several robots can access the same computer over an Ethernet network.

Once the NFS application protocol is configured, the remote computer can be accessed in the same way as the controller's internal hard disk.

The external computer must have:

• TCP/IP stack

• NFS Server

Limitations

When using the NFS Client the maximum length for a file name is 99 characters.

When using the NFS Client the maximum length for a file path including the file name is also 99 characters. The whole path is included in the 99 characters, not only the server path. When ordering a backup towards a mounted disk all the directories created by the backup has to be included in the max path.

Example

Parameter

Local path

Value

pc:





8 Communication

8.2.1 Introduction to NFS Client

Continued

Parameter

Server path

Value

C:\robot_1

• A backup is saved to pc:/Backups/Backup_20130109

(27 characters)

• The path on the PC will be C:\robot_1\Backups\Backup_20130109

(34 characters)

• The longest file path inside this backup is

C:\robot_1\Backups\Backup_20130109\RAPID\TASK1\PROGMOD\myprogram.mod

(54+13 characters)

The maximum path length for this example first looks like 27 characters but is actually 67 characters.




8 Communication



Application protocol

This is a brief description of the parameters used to configure an application protocol. For more information, see the respective parameter in


These parameters belongs to the type Application protocolin the topic

Communication.

Parameter

Name

Type Type of application protocol.

Set this to "NFS".

Transmission protocol Name of the transmission protocol the protocol should use.

For NFS, this is always "TCP/IP".

Server address

Trusted

Description

Name of the application protocol.

Local path

Server path

The IP address of the computer with the NFS server.

This flag decides if this computer should be trusted, i.e. if losing the connection should make the program stop.

Defines what the shared unit will be called on the robot. The parameter value must end with a colon (:).

If, for example the unit is named "pc:", the name of the test.prg on this unit would be pc:test.prg

The name of the exported disk or folder on the remote computer.

For NFS, Server Path must be specified.

User ID

Group ID

Used by the NFS protocol as a way of authorizing the user to access a specific server.

If this parameter is not used, which is usually the case on a PC, set it to the default value 0.

Note that User ID must be the same for all mountings on one robot controller.

Used by the NFS protocol as a way of authorizing the user to access a specific server.

If this parameter is not used, which is usually the case on a PC, set it to the default value 0.

Note that Group ID must be the same for all mountings on one robot controller.

Transmission protocol

There is a configured transmission protocol called TCP/IP, but no changes can be made to it. This is used by the NFS application protocol.




269

8 Communication

8.2.3 Examples

8.2.3 Examples

Example configuration

This is an example of how an application protocol can be configured for NFS.

Parameter

Name

Type

Transmission protocol

Server address

Trusted

Local path

Server path

User ID

Group ID

Value

my NFS protocol

NFS

TCP/IP

100.100.100.100

No pc:

C:\robot_1

Robot1 robot1

Example with FlexPendant

This example shows how to use the FlexPendant to make a backup to the remote

PC. We assume that the configuration is done according to the example configuration shown above.

1 Tap ABB and select Backup and Restore.

2 Tap on Backup Current System.

3 Save the backup to pc:/Backup/Backup_20031008 (the path on the PC will be C:\robot_1\Backup\Backup_20031008).

Example with RAPID code

This example shows how to open the file C:\robot_1\files\file1.doc on the remote

PC from a RAPID program on the controller. We assume that the configuration is done according to the example configuration shown above.

Open "HOME:" \File:= "pc:/files/file1.doc", file;




8 Communication

8.3.1 Introduction to PC Interface

8.3 PC Interface [616-1]

8.3.1 Introduction to PC Interface

Purpose

PC Interface is used for communication between the controller and a PC.

The option PC Interface is required when connecting to a controller over LAN with

RobotStudio.

With PC Interface, data can be sent to and from a PC. This is, for example, used for:

• Backup.

• Production statistics logging.

• Operator information presented on a PC.

• Send command to the robot from a PC operator interface.

• RobotStudio add-in that performs operations on the controller.

Note

If connecting over the service port, then the functionality is available without the option PC Interface.


The RobotWare option PC Interface gives you access to:

• An Ethernet communication interface, which is used by some ABB software products.

Basic approach

The general approach for using PC Interface is the same as setting up a PC SDK client application on a PC. For more information, see http://developercenter.robotstudio.com

.




271

8 Communication

8.3.2 Send variable from RAPID

8.3.2 Send variable from RAPID

SCWrite instruction

The instruction

SCWrite

(Superior Computer Write) can be used to send persistent variables to a client application on a PC. For more information, see Technical reference manual - RAPID Instructions, Functions and Data types.

The PC must have a client application that can subscribe to the information that is sent to or from the controller.

Code example

In this example the robot moves objects to a position where they can be treated by a process that is controlled by the PC. When the object is ready the robot moves it to its next station.

The program uses

SCWrite to inform the PC when the object is in position and when it has been moved to the next station. It also sends a message to the PC about how many objects that have been handled.

RAPID module for the sender

VAR rmqslot destination_slot;

VAR user_def

RMQFindSlot destination_slot,"RMQ_Task2";

WHILE TRUE DO

! Wait for next object

WaitDI di1,1;

! Call first routine move_obj_to_pos();

! Send message to PC that object is in position user_def = 0; in_position:=TRUE;

RMQSendMessage destination_slot, in_position \UserDef:=user_def;

! Wait for object to be ready

WaitDI di2,1;

! Call second routine move_obj_to_next();

! Send message to PC that object is gone in_position:=FALSE;

RMQSendMessage destination_slot, in_position \UserDef:=user_def;


272

! Inform PC how many object has been handled nbr_objects:= nbr_objects+1; user_def = 1;




8 Communication

8.3.2 Send variable from RAPID

Continued

RMQSendMessage destination_slot, nbr_objects \UserDef:=user_def;

ENDWHILE

PC SDK for the receiver public void ReceiveObjectPosition()

{ const string destination_slot = "RMQ_Task2";

IpcQueue queue = Controller.Ipc.CreateQueue(destination_slot,

16, Ipc.MaxMessageSize);

// Until application is closed while (uiclose)

{

IpcMessage message = new IpcMessage();

IpcReturnType retValue = IpcReturnType.Timeout;

}

} retValue = queue.Receive(1000, message); if (IpcReturnType.OK == retValue)

{ string receivemessage = message.Data.ToString().ToLower();

// if message.UserDef is 0 means Object position data else number of objects if (message.UserDef == 0)

{ if (receivemessage == "true")

{

// Object is in position

} else

{

// Object is not in position

}

} else

{

// number of objects in receivemessage

}




273

8 Communication

8.3.3 ABB software using PC Interface

8.3.3 ABB software using PC Interface

Overview

PC Interface provides a communication interface between the controller and a PC connected to an Ethernet network.

This functionality can be used by different software applications from ABB. Note that the products mentioned below are examples of applications using PC Interface, not a complete list.

RobotStudio

RobotStudio is a software product delivered with the robot. Some of the functionality requires PC Interface when connecting over the LAN port.

The following table shows some examples of RobotStudio functionality that is only available if you have PC Interface:

Functionality

Event recorder

RAPID editor

Description

Error messages and similar events can be shown or logged on the PC.

Allows on-line editing against the controller from the PC.

For more information, see Operating manual - RobotStudio.




8 Communication

8.4.1 Introduction to Socket Messaging

8.4 Socket Messaging [616-1]

8.4.1 Introduction to Socket Messaging

Purpose

The purpose of Socket Messaging is to allow a RAPID programmer to transmit application data between computers, using the TCP/IP network protocol. A socket represents a general communication channel, independent of the network protocol being used.

Socket communication is a standard that has its origin in Berkeley Software

Distribution Unix. Besides Unix, it is supported by, for example, Microsoft Windows.

With Socket Messaging, a RAPID program on a robot controller can, for example, communicate with a C/C++ program on another computer.


The RobotWare option Socket Messaging gives you access to RAPID data types, instructions and functions for socket communication between computers.

Basic approach

This is the general approach for using Socket Messaging. For a more detailed example of how this is done, see


.

1 Create a socket, both on client and server. A robot controller can be either client or server.

2 Use

SocketBind and

SocketListen on the server, to prepare it for a connection request.

3 Order the server to accept incoming socket connection requests.

4 Request socket connection from the client.

5 Send and receive data between client and server.




275

8 Communication

8.4.2 Schematic picture of socket communication

8.4.2 Schematic picture of socket communication

Illustration of socket communication

276 en0600003224

Tip

Do not create and close sockets more than necessary. Keep the socket open until the communication is completed. The socket is not really closed until a certain time after

SocketClose

(due to TCP/IP functionality).




8 Communication

8.4.3 Technical facts about Socket Messaging

8.4.3 Technical facts about Socket Messaging

Overview

When using RAPID functionality Socket Messaging to communicate with a client or server that is not a RAPID task, it can be useful to know how some of the implementation is done.

No string termination

When sending a data message, no string termination sign is sent in the message.

The number of bytes sent is equal to the return value of the function strlen(str) in the programming language C.

Unintended merge of messages

If sending two messages with no delay between the sendings, the result can be that the second message is appended to the first. The result is one big message instead of two messages. To avoid this, use acknowledge messages from the receiver of the data, if the client/server is just receiving messages.

Non printable characters

If a client that is not a RAPID task needs to receive non printable characters (binary data) in a string from a RAPID task, this can be done by RAPID as shown in the example below.

SocketSend socket1 \Str:="\0D\0A";

For more information, see Technical reference manual - RAPID kernel, section

String literals.




277

8 Communication



Data types

This is a brief description of each data type in Socket Messaging. For more information, see the respective data type in Technical reference manual - RAPID


Data type

socketdev socketstatus

Description

A socket device used to communicate with other computers on a network.

Can contain status information from a socketdev variable.

Instructions for client

This is a brief description of each instruction used by the a Socket Messaging client. For more information, see the respective instruction in Technical reference manual - RAPID Instructions, Functions and Data types.

Instruction

SocketCreate

SocketConnect

SocketSend

SocketReceive

SocketClose

Description

Creates a new socket and assigns it to a socketdev variable.

Makes a connection request to a remote computer. Used by the client to connect to the server.

Sends data via a socket connection to a remote computer. The data can be a string or rawbytes variable, or a byte array.

Receives data and stores it in a string or rawbytes variable, or in a byte array.

Closes a socket and release all resources.

Tip

Do not use

SocketClose directly after

SocketSend

. Wait for acknowledgement before closing the socket.

Instructions for server

A Socket Messaging server use the same instructions as the client, except for

SocketConnect

. In addition, the server use the following instructions:

Instruction

SocketBind

SocketListen

SocketAccept

Description

Binds the socket to a specified port number on the server.

Used by the server to define on which port (on the server) to listen for a connection.

The IP address defines a physical computer and the port defines a logical channel to a program on that computer.

Makes the computer act as a server and accept incoming connections. It will listen for a connection on the port specified by

SocketBind

.

Accepts an incoming connection request. Used by the server to accept the client’s request.





Functions

8 Communication


Continued

Note

The server application must be started before the client application, so that the instruction

SocketAccept is executed before any client execute

SocketConnect

.

This is a brief description of each function in Socket Messaging. For more information, see the respective function in Technical reference manual - RAPID


Function

SocketGetStatus

Description

Returns information about the last instruction performed on the socket

(created, connected, bound, listening, closed).

SocketGetStatus does not detect changes from outside RAPID (such as a broken connection).




279

8 Communication

8.4.5 Code examples


Example of client/server communication

This example shows program code for a client and a server, communicating with each other.

The server will write on the FlexPendant:

Client wrote - Hello server

Client wrote - Shutdown connection

The client will write on its FlexPendant:

Server wrote - Message acknowledged

Server wrote - Shutdown acknowledged

In this example, both the client and the server use RAPID programs. In reality, one of the programs would often be running on a PC (or similar computer) and be written in another program language.

Code example for client, contacting server with IP address 192.168.0.2:

! WaitTime to delay start of client.

! Server application should start first.

WaitTime 5;

VAR socketdev socket1;

VAR string received_string;

PROC main()

SocketCreate socket1;

SocketConnect socket1, "192.168.0.2", 1025;

! Communication

SocketSend socket1 \Str:="Hello server";

SocketReceive socket1 \Str:=received_string;

TPWrite "Server wrote - " + received_string; received_string := "";

! Continue sending and receiving

...

! Shutdown the connection

SocketSend socket1 \Str:="Shutdown connection";

SocketReceive socket1 \Str:=received_string;

TPWrite "Server wrote - " + received_string;

SocketClose socket1;

ENDPROC

Code example for server (with IP address 192.168.0.2):

VAR socketdev temp_socket;

VAR socketdev client_socket;

VAR string received_string;

VAR bool keep_listening := TRUE;

PROC main()

SocketCreate temp_socket;

SocketBind temp_socket, "192.168.0.2", 1025;

SocketListen temp_socket;

WHILE keep_listening DO

! Waiting for a connection request

SocketAccept temp_socket, client_socket;





8 Communication

8.4.5 Code examples

Continued

! Communication

SocketReceive client_socket \Str:=received_string;

TPWrite "Client wrote - " + received_string; received_string := "";

SocketSend client_socket \Str:="Message acknowledged";

! Shutdown the connection

SocketReceive client_socket \Str:=received_string;

TPWrite "Client wrote - " + received_string;

SocketSend client_socket \Str:="Shutdown acknowledged";

SocketClose client_socket;

ENDWHILE

SocketClose temp_socket;

ENDPROC

Example of error handler

The following error handlers will take care of power failure or broken connection.

Error handler for client in previous example:

! Error handler to make it possible to handle power fail

ERROR

IF ERRNO=ERR_SOCK_TIMEOUT THEN

RETRY;

ELSEIF ERRNO=ERR_SOCK_CLOSED THEN

SocketClose socket1;

! WaitTime to delay start of client.

! Server application should start first.

WaitTime 10;

SocketCreate socket1;

SocketConnect socket1, "192.168.0.2", 1025;

RETRY;

ELSE

TPWrite "ERRNO = "\Num:=ERRNO;

Stop;

ENDIF

Error handler for server in previous example:

! Error handler for power fail and connection lost

ERROR

IF ERRNO=ERR_SOCK_TIMEOUT THEN

RETRY;

ELSEIF ERRNO=ERR_SOCK_CLOSED THEN

SocketClose temp_socket;

SocketClose client_socket;

SocketCreate temp_socket;

SocketBind temp_socket, "192.168.0.2", 1025;

SocketListen temp_socket;

SocketAccept temp_socket, client_socket;

RETRY;

ELSE

TPWrite "ERRNO = "\Num:=ERRNO;

Stop;

ENDIF




281

8 Communication

8.5.1 Introduction to RAPID Message Queue

8.5 RAPID Message Queue [included in 616-1, 623-1]

8.5.1 Introduction to RAPID Message Queue

Purpose

The purpose of RAPID Message Queue is to communicate with another RAPID task or PC application using PC SDK.


• Sending data between two RAPID tasks.

• Sending data between a RAPID task and a PC application.

RAPID Message Queue can be defined for interrupt or synchronous mode. Default setting is interrupt mode.


The RAPID Message Queue functionality is included in the RobotWare options:

• PC Interface

• Multitasking

RAPID Message Queue gives you access to RAPID instructions, functions, and data types for sending and receiving data.

Basic approach

This is the general approach for using RAPID Message Queue. For a more detailed example of how this is done, see


.

1 For interrupt mode: The receiver sets up a trap routine that reads a message and connects an interrupt so the trap routine is called when a new message appears.

For synchronous mode: The message is handled by a waiting or the next executed

RMQReadWait instruction.

2 The sender looks up the slot identity of the queue in the receiver task.

3 The sender sends the message.




8 Communication

8.5.2 RAPID Message Queue behavior

8.5.2 RAPID Message Queue behavior

Illustration of communication

The picture below shows various possible senders, receivers, and queues in the system. Each arrow is an example of a way to post a message to a queue.

PC

PC SDK

Queue

Robot controller

RAPID task

Queue

RAPID task

Queue en0700000430

Creating a PC SDK client

This manual only describes how to use RAPID Message Queue to make a RAPID task communicate with other RAPID tasks and PC SDK clients. For information about how to set up the communication on a PC SDK client, see http://developercenter.robotstudio.com

.

What can be sent in a message

The data in a message can be any data type in RAPID, except:

• non-value

• semi-value





8 Communication


Continued

• motsetdata

The data in a message can also be an array of a data type.

User defined records are allowed, but both sender and receiver must have identical declarations of the record.

Tip

To keep backward compatibility, do not change a user defined record once it is used in a released product. It is better to create a new record. This way, it is possible to receive messages from both old and new applications.

Queue name

The name of the queue configured for a RAPID task is the same as the name of the task with the prefix RMQ_, for example RMQ_T_ROB1. This name is used by the instruction

RMQFindSlot

.

Queue handling

Messages in queues are handled in the order that they are received. This is known as FIFO, first in first out. If a message is received while a previous message is being handled, the new message is placed in the queue. As soon as the first message handling is completed, the next message in the queue is handled.

Queue modes

The queue mode is defined with the system parameter RMQ Mode. Default behavior is interrupt mode.

Interrupt mode

In interrupt mode the messages are handled depending on data type. Messages are only handled for connected data types.

A cyclic interrupt must be set up for each data type that the receiver should handle.

The same trap routine can be called from more than one interrupt, that is for more than one data type.

Messages of a data type with no connected interrupt will be discarded with only a warning message in the event log.

Receiving an answer to the instruction

RMQSendWait does not result in an interrupt.

No interrupt needs to be set up to receive this answer.

Synchronous mode

In synchronous mode, the task executes an

RMQReadWait instruction to receive a message of any data type. All messages are queued and handled in order they arrive.

If there is a waiting

RMQReadWait instruction, the message is handled immediately.

If there is no waiting

RMQReadWait instruction, the next executed

RMQReadWait instruction will handle the message.





8 Communication


Continued

Message content

RAPID task not executing

It is possible to post messages to a RAPID task queue even though the RAPID task containing the queue is not currently executing. The interrupt will not be executed until the RAPID task is executing again.

Message size limitations

Before a message is sent, the maximum size (for the specific data type and dimension) is calculated. If the size is greater than 5000 bytes, the message will be discarded and an error will be raised. The sender can get same error if the receiver is a PC SDK client with a maximum message size smaller than 400 bytes.

Sending a message of a specific data type with specific dimensions will either always be possible or never possible.

When a message is received (when calling the instruction

RMQGetMsgData

), the maximum size (for the specific data type and dimension) is calculated. If the size is greater than the maximum message size configured for the queue of this task, the message will be discarded and an error will be logged. Receiving a message of a specific data type with specific dimensions will either always be possible or never possible.

Message lost

In interrupt mode, any messages that cannot be received by a RAPID task will be discarded. The message will be lost and a warning will be placed in the event log.

Example of reasons for discarding a message:

• The data type that is sent is not supported by the receiving task.

• The receiving task has not set up an interrupt for the data type that is sent, and no

RMQSendWait instruction is waiting for this data type.

• The interrupt queue of the receiving task is full

Queue lost

A RAPID Message Queue message consists of a header, containing receiver identity, and a RAPID message. The RAPID message is a pretty-printed string with data type name (and array dimensions) followed by the actual data value.

RAPID message examples:

"robtarget;[[930,0,1455],[1,0,0,0],[0,0,0,0],

[9E9,9E9,9E9,9E9,9E9,9E9]]"

"string;"A message string""

"msgrec;[100,200]"

"bool{2,2};[[TRUE,TRUE],[FALSE,FALSE]]"

The queue is cleared at power fail.

When the execution context in a RAPID task is lost, for example when the program pointer is moved to main, the corresponding queue is emptied.





285

8 Communication


Continued


For more information on queues and messages, see Technical reference manual - RAPID kernel.




8 Communication




This is a brief description of each parameter in RAPID Message Queue. For more information, see the respective parameter in Technical reference manual - System parameters.

Type Task

These parameters belong to the type Task in the topic Controller.

Parameter

RMQ Type

RMQ Mode

RMQ Max Message Size

Description

Can have one of the following values:

• None - Disable all communication with RAPID Message

Queue for this RAPID task.

• Internal - Enable the receiving of RAPID Message

Queue messages from other tasks on the controller, but not from external clients (FlexPendant and PC applications). The task is still able to send messages to external clients.

• Remote - Enable communication with RAPID Message

Queue for this task, both with other tasks on the controller and external clients (FlexPendant and PC applications).

The default value is None.

Defines the mode of the queue.

Can have one of the following values:

• Interrupt - A message can only be received by connecting a trap routine to a specified message type.

• Synchronous - A message can only be received by executing an

RMQReadWait instruction.

Default value is Interrupt.

The maximum data size, in bytes, for a message.

The default value is 400.

This value cannot be changed in RobotStudio or on the

FlexPendant. The value can only be changed by editing the sys.cfg file. The maximum value is 3000.

RMQ Max No Of Messages Maximum number of messages in queue.

Default is 5.

This value cannot be changed in RobotStudio or on the

FlexPendant. The value can only be changed by editing the sys.cfg file. The maximum value is 10.




287

8 Communication




This is a brief description of each instruction, function, and data type in RAPID

Message Queue. For more information, see the respective parameter in Technical reference manual - RAPID Instructions, Functions and Data types.

Instructions

Instruction

RMQFindSlot

RMQSendMessage

IRMQMessage

RMQGetMessage

RMQGetMsgHeader

RMQGetMsgData

RMQSendWait

RMQReadWait

RMQEmptyQueue

Description

Find the slot identity number of the queue configured for a

RAPID task or Robot Application Builder client.

Send data to the queue configured for a RAPID task or Robot

Application Builder client.

Order and enable cyclic interrupts for a specific data type.

Get the first message from the queue of this task. Can only be used if RMQ Mode is defined as Interrupt.

Get the header part from a message.

Get the data part from a message.

Send a message and wait for the answer. Can only be used if RMQ Mode is defined as Interrupt.

Wait for a message. Can only be used if RMQ Mode is defined as Synchronous.

Empty the queue.

Functions

Function

RMQGetSlotName

Description

Get the name of the queue configured for a RAPID task or

Robot Application Builder client, given a slot identity number, i.e. given a rmqslot

.

Data types

Data type

rmqslot rmqmessage rmqheader

Description

Slot identity of a RAPID task or Robot Application Builder client.

A message used to store data in when communicating with

RAPID Message Queue. It contains information about what type of data is sent, the slot identity of the sender, and the actual data.

Note:

rmqmessage is a large data type. Declaring too many variables of this data type can lead to memory problems.

Reuse the same rmqmessage variables as much as possible.

The rmqheader describes the message and can be read by the RAPID program.




8 Communication

8.5.5 Code examples


Example with RMQSendMessage and RMQGetMessage

This is an example where the sender creates data (x and y value) and sends it to another task. The receiving task gets the message and extract the data to the variable named data

.

Sender

MODULE SenderMod

RECORD msgrec num x; num y;

ENDRECORD

PROC main()

VAR rmqslot destinationSlot;

VAR msgrec data;

VAR robtarget p_current;

! Connect to queue in other task

RMQFindSlot destinationSlot "RMQ_OtherTask";

! Perform cycle

WHILE TRUE DO

...

p_current := CRobT(\Tool:=tool1 \WObj:=wobj0); data.x := p_current.trans.x; data.y := p_current.trans.y;

! Send message

RMQSendMessage destinationSlot, data;

...

ENDWHILE

ERROR

IF ERRNO = ERR_RMQ_INVALID THEN

WaitTime 1;

! Reconnect to queue in other task


! Avoid execution stop due to retry count exceed

ResetRetryCount;

RETRY;

ELSIF ERRNO = ERR_RMQ_FULL THEN

WaitTime 1;


ResetRetryCount;

RETRY;

ENDIF

ENDPROC

ENDMODULE

PC SDK client public void RMQReceiveRecord()





8 Communication

8.5.5 Code examples

Continued

{ const string destination_slot = "RMQ_OtherTask";



// Till application is closed while (uiclose)

{


IpcReturnType retValue = IpcReturnType.Timeout; retValue = queue.Receive(1000, message); if (IpcReturnType.OK == retValue)

{

// PCSDK App will receive following record

// RECORD msgrec

// num x;

// num y;

// ENDRECORD

// num data type in RAPID is 3 bytes long, hence will receive

6 bytes for x and y

// first byte do left shift by 16,

// second byte do left shift by 8 and OR all three byte to get x

// do similar for y

Int32 x = (message.Data[0] << 16) | (message.Data[1] << 8)

| message.Data[2];

Int32 y = (message.Data[3] << 16) | (message.Data[4] << 8)

| message.Data[5];

}

}

// Display x and y

} if (Controller.Ipc.Exists(destination_slot))

Controller.Ipc.DeleteQueue(Controller.Ipc.GetQueueId(destination_slot));

Example with RMQSendWait

This is an example of a RAPID program that sends a message and wait for an answer before execution continues by getting the answer message.

MODULE SendAndReceiveMod

VAR rmqslot destinationSlot;

VAR rmqmessage recmsg;

VAR string send_data := "How many units should be produced?";

VAR num receive_data;

PROC main()

! Connect to queue in other task






8 Communication

8.5.5 Code examples

Continued

! Send message and wait for the answer

RMQSendWait destinationSlot, send_data, recmsg, receive_data

\Timeout:=30;

! Handle the received data

RMQGetMsgData recmsg, receive_data;

TPWrite "Units to produce: " \Num:=receive_data;

ERROR

IF ERRNO = ERR_RMQ_INVALID THEN

WaitTime 1;

! Reconnect to queue in other task



ResetRetryCount;

RETRY;

ELSIF ERRNO = ERR_RMQ_FULL THEN

WaitTime 1;


ResetRetryCount;

RETRY;

ELSEIF ERRNO = ERR_RMQ_TIMEOUT THEN


ResetRetyCount;

RETRY;

ENDIF

ENDPROC

ENDMODULE

Example with RMQReceiveSend

public void RMQReceiveSend()

{ const string destination_slot = "RMQ_OtherTask";



// Till application is closed while (uiclose)

{


IpcReturnType retValue = IpcReturnType.Timeout; retValue = queue.Receive(1000, message); if (IpcReturnType.OK == retValue)

{

// Received message "How many units should be produced?" if (message.ToString() == "How many units should be produced?")

{

Int32 UnitsToProduce = 100;





8 Communication

8.5.5 Code examples

Continued

// num data type in Rapid is 3 bytes long, hence will send 3 bytes to Rapid Module byte[] @bytes = new byte[3]; bytes[0] = (byte)(UnitsToProduce >> 16); bytes[1] = (byte)(UnitsToProduce >> 8); bytes[2] = (byte)UnitsToProduce;

}

}

}

// Send UnitsToProduce to Rapid Module message.SetData(@bytes); queue.Send(message);

} if (Controller.Ipc.Exists(destination_slot))

Controller.Ipc.DeleteQueue(Controller.Ipc.GetQueueId(destination_slot));




9 Engineering tools

9.1.1 Introduction to Multitasking


9.1 Multitasking [623-1]

9.1.1 Introduction to Multitasking

Purpose

The purpose of the option Multitasking is to be able to execute more than one program at a time.

Examples of applications to run in parallel with the main program:

• Continuous supervision of signals, even if the main program has stopped.

This can in some cases take over the job of a PLC. However, the response time will not match that of a PLC.

• Operator input from the FlexPendant while the robot is working.

• Control and activation/deactivation of external equipment.

Basic description

Up to 20 tasks can be run at the same time.

Each task consists of one program (with several program modules) and several system modules. The modules are local in the respective task.

en0300000517

Variables and constants are local in the respective task, but persistents are not.

Every task has its own trap handling and event routines are triggered only on its own task system states.


The RobotWare option Multitasking gives you access to:

• The possibility to run up to 20 programs in parallel (one per task).

• The system parameters: The type Task and all its parameters.

• The data types: taskid

, syncident

, and tasks

.






9.1.1 Introduction to Multitasking

Continued

• The instruction:

WaitSyncTask

.

• The functions:

TestAndSet

,

TaskRunMec

, and

TaskRunRob

.

Note

TestAndSet

,

TaskRunMec

, and

TaskRunRob can be used without the option

Multitasking, but they are much more useful together with Multitasking.

Basic approach

This is the basic approach for setting up Multitasking. For more information, see

Debug strategies for setting up tasks on page 298 , and

RAPID components on page 297

.

1 Define the tasks you need.

2 Write RAPID code for each task.

3 Specify which modules to load in each task.








This is a brief description of each parameter in Multitasking. For more information, see the respective parameter in Technical reference manual - System parameters.

Task

These parameters belongs to the type Task in the topic Controller.

Parameter

Task

Task in foreground

Type

Main entry

Check unresolved references

TrustLevel

Description

The name of the task.

Note that the name of the task must be unique. This means that it cannot have the same name as the mechanical unit, and no variable in the

RAPID program can have the same name.

Note that editing the task entry in the configuration editor and changing the task name will remove the old task and add a new one. This means that any program or module in the task will disappear after a restart with these kind of changes.

Used to set priorities between tasks.

Task in foreground contains the name of the task that should run in the foreground of this task. This means that the program of the task, for which the parameter is set, will only execute if the foreground task program is idle.

If Task in foreground is set to empty string for a task, it runs at the highest level.

Controls the start/stop and system restart behavior:

• NORMAL - The task program is manually started and stopped (e.g.

from the FlexPendant). The task stops at emergency stop.

• STATIC - At a restart the task program continues from where the it was. The task program is normally not stopped by the FlexPendant or by emergency stop.

• SEMISTATIC - The task program restarts from the beginning at restart. The task program is normally not stopped by the FlexPendant or by emergency stop.

A task that controls a mechanical unit must be of the type NORMAL.

The name of the start routine for the task program.

This parameter should be set to NO if the system is to accept unsolved references in the program while linking a module, otherwise set to YES.

TrustLevel defines the system behavior when a STATIC or SEMISTATIC task program is stopped (e.g. due to error):

• SysFail - If the program of this task stops, the system will be set to SYS_FAIL. This will cause the programs of all NORMAL tasks to stop (STATIC and SEMISTATIC tasks will continue execution if possible). No jogging or program start can be made. A restart is required.

• SysHalt -If the program of this task stops, the programs of all

NORMAL tasks will be stopped. If "motors on" is set, jogging is possible, but not program start. A restart is required.

• SysStop - If the program of this task stops, the programs of all

NORMAL tasks will be stopped but are restartable. Jogging is also possible.

• NoSafety - Only the program of this task will stop.







Continued

Parameter

MotionTask

Description

Indicates whether the task program can control robot movement with

RAPID move instructions.

Only one task can have MotionTask set to YES unless the option MultiMove is used.







Data types

This is a brief description of each data type in Multitasking. For more information, see the respective data type in Technical reference manual - RAPID Instructions,


Data type

taskid syncident tasks

Description

taskid identify available tasks in the system.

This identity is defined by the system parameter Task, and cannot be defined in the RAPID program. However, the data type taskid can be used as a parameter when declaring a routine.

For code example, see

taskid on page 315 .

syncident is used to identify the waiting point in the program, when using the instruction

WaitSyncTask

.

The name of the syncident variable must be the same in all task programs.


WaitSyncTask example on page 309

.

A variable of the data type tasks contains names of the tasks that will be synchronized by the instruction

WaitSyncTask

.



.

Instructions

This is a brief description of each instruction in Multitasking. For more information, see the respective instruction in Technical reference manual - RAPID Instructions,


Instruction

WaitSyncTask

Description

WaitSyncTask is used to synchronize several task programs at a special point in the program.

A

WaitSyncTask instruction will delay program execution and wait for the other task programs. When all task programs have reached the point, the respective program will continue its execution.



.

Functions

This is a brief description of each function in Multitasking. For more information, see the respective function in Technical reference manual - RAPID Instructions,


Function

TestAndSet

TaskRunMec

TaskRunRob

Description

TestAndSet is used, together with a boolean flag, to ensure that only one task program at the time use a specific RAPID code area or system resource.

For code example, see Example with flag and TestAndSet on page 313

.

Check if the task program controls any mechanical unit (robot or other unit).

For code example, see Test if task controls mechanical unit on page 314

.

Check if the task program controls any robot with TCP.

For code example, see Test if task controls mechanical unit on page 314

.




297


9.1.4.1 Debug strategies for setting up tasks

9.1.4 Task configuration

9.1.4.1 Debug strategies for setting up tasks

Tip

The instructions below show the safe way to make updates. By setting the parameter Type to NORMAL and TrustLevel to NoSafety the task program will be easier to test and any error that may occur will be easier to correct.

If you are certain that the code you introduce is correct, you can skip changing values for Type and TrustLevel. If you do not change any system parameters you may not have to do any restart mode.

Setting up tasks

5

6

7

Follow this instruction when adding a new task to your system.

1

2

3

4

8

Action

Define the new task by adding an instance of the system parameter type Task, in the topic Controller.

Set the parameter Type to NORMAL.

This will make it easier to create and test the modules in the task.

Create the modules that should be in the task, either from the FlexPendant or offline, and save them.

In the system parameters for topic Controller and type Automatic loading of Modules, specify all modules that should be preloaded to the new task.

For NORMAL tasks the modules can be loaded later, but STATIC or SEMISTATIC tasks the modules must be preloaded.

Stop the controller.

In Motors on state, test and debug the modules until the functionality is satisfactory.

Change the parameters Type and TrustLevel to desired values (e.g. SEMISTATIC and

SysFail).

Restart the system.

Make changes to task program

Follow this instruction when editing a program in an existing task with Type set to

STATIC or SEMISTATIC.

1

2

3

4

5

Action

Change the system parameter TrustLevel to NoSafety.

This will make it possible to change and test the modules in the task.

If the system parameter needed to be changed, restart the controller.

On the FlexPendant, start the Control Panel from the ABB menu. Then tap FlexPendant and Task Panel Settings. Select All tasks and tap OK.

In the Quickset menu, select which tasks to start and stop manually. See

Select which tasks to start with START button on page 303 .

Press the STOP button to stop the selected STATIC and SEMISTATIC tasks.






9.1.4.1 Debug strategies for setting up tasks

Continued

7

8

6

9

10

Action

Start the Program Editor.

The STATIC and SEMISTATIC tasks are now also editable.

Change, test, and save the modules.

Start the Control Panel again and open the Task Panel Settings. Select Only Normal

tasks and tap OK.

Change the parameter TrustLevel back to desired value (e.g. SysFail).

Restart the system.




299


9.1.4.2 Priorities

9.1.4.2 Priorities

How priorities work

The default behavior is that all task programs run at the same priority, in a Round

Robin way.

It is possible to change the priority of one task by setting it in the background of another task. Then the program of the background task will only execute when the foreground task program is idle, waiting for an event, for example. Another situation when the background task program will execute is when the foreground task program has executed a move instruction, as the foreground task will then have to wait until the robot has moved .

To set a task in the background of another task, use the parameter Task in foreground.

Example of priorities

6 tasks are used, with Task in foreground set as shown in the table below.

Task name

MAIN

BACK1

BACK2

BACK3

SUP1

SUP2

Task in foreground

MAIN

BACK1

BACK1

SUP1

The priority structure will then look like this: en0300000451

The programs of the tasks MAIN and SUP1 will take turns in executing an instruction each (Case 1 in figure below).

If the MAIN task program is idle, the programs of BACK1 and SUP1 will take turns in executing an instruction each (Case 2 in figure below).






9.1.4.2 Priorities

Continued

If both MAIN and BACK1 task programs are idle, the programs of BACK2, BACK3, and SUP1 will take turns in executing an instruction each (Case 3 in figure below).

en0300000479




301


9.1.4.3 Task Panel Settings

9.1.4.3 Task Panel Settings

Purpose of Task Panel Settings

The default behavior is that only NORMAL tasks are started and stopped with the

START and STOP buttons. In the Task Selection Panel you can select which

NORMAL tasks to start and stop, see

Select which tasks to start with START button on page 303 .

In the Task Panel Settings the default behavior can be altered so that STATIC and

SEMISTATIC tasks also can be stepped, started and stopped with the START and

STOP buttons. However, these tasks can only be started and stopped if they have

TrustLevel set to NoSafety and they can only be started and stopped in manual mode.

Allow selection of STATIC and SEMISTATIC tasks in tasks panel

The following procedure details how to make STATIC and SEMISTATIC tasks selectable in the tasks panel.

1

2

Action

On the ABB menu, tap Control Panel, then FlexPendant and then Task Panel Settings.

Select All tasks (Normal/Static/Semistatic) with trustlevel nosafety and tap OK.





9.1.4.4 Select which tasks to start with START button

9.1.4.4 Select which tasks to start with START button

Background

Task Panel Settings

To start the Task Panel Settings, tap the ABB menu, and then Control Panel,

FlexPendant and Task Panel Settings.

Selecting tasks

The default behavior is that the programs of all NORMAL tasks are started simultaneously when pressing the START button. However, not all NORMAL task programs need to run at the same time. It is possible to select which of the NORMAL task programs will start when pressing the START button.

If All Tasks is selected in the Task Panel Settings, the programs of all STATIC and SEMISTATIC tasks with TrustLevel set to NoSafety can be selected to be started with the START button, forward stepped with the FWD button, backward stepped with the BWD button, and stopped with the STOP button.

If Task Panel Settings is set to Only Normal tasks, all STATIC and SEMISTATIC tasks are greyed out and cannot be selected in the task panel, Quickset menu (see

Operating manual - IRC5 with FlexPendant, section Quickset menu). All STATIC and SEMISTATIC tasks will be started if the start button is pressed.

If Task Panel Settings is set to All tasks, STATIC and SEMISTATIC tasks with

TrustLevelNoSafety can be selected in the task panel. All selected STATIC and

SEMISTATIC tasks can be stopped, stepped, and started. .

A STATIC or SEMISTATIC task, not selected in the task panel, can still be executing.

This is not possible for a NORMAL task.

Run Mode is always continuous for STATIC and SEMISTATIC tasks. The Run Mode setting in the Quickset menu is only applicable for NORMAL tasks (see Operating manual - IRC5 with FlexPendant, section Quickset menu).

This will only work in manual mode, no STATIC or SEMISTATIC task can be started, stepped, or stopped in auto mode.

1

2

Use this procedure to select which of the tasks are to be started with the START button.

3

Action

Set the controller to manual mode.

On the FlexPendant, tap the QuickSet button and then the tasks panel button to show all tasks.

If Task Panel Settings is set to Only Normal tasks, all STATIC and SEMISTATIC tasks are greyed out and cannot be selected.

If Task Panel Settings is set to All tasks, STATIC and SEMISTATIC tasks with Trust-

LevelNoSafety can be selected, while STATIC and SEMISTATIC tasks with TrustLevel set to other values are grayed out and cannot be selected.

Select the check boxes for the tasks whose program should be started by the START button.






9.1.4.4 Select which tasks to start with START button

Continued

Resetting debug settings in manual mode

Use this procedure to resume normal execution manual mode.

1

2

Action

Select Only Normal tasks in the Task Panel Settings.

Press START button.

All STATIC and SEMISTATIC will run continuously and not be stopped by the STOP button or emergency stop.

Switching to auto mode

When switching to auto mode, all STATIC and SEMISTATIC tasks will be deselected from the tasks panel. The stopped STATIC and SEMISTATIC tasks will start next time any of the START, FWD or BWD button are pressed. These tasks will then run continuously forward and not be stopped by the STOP button or emergency stop.

What happens with NORMAL tasks that has been deselected in the tasks panel depends on the system parameter Reset in type Auto Condition Reset in topic

Controller. If Reset is set to Yes, all NORMAL tasks will be selected in the tasks panel and be started with the START button. If Reset is set to No, only those

NORMAL tasks selected in tasks panel will be started by the START button.

Note

Note that changing the value of the system parameter Reset will affect all the debug resettings (for example speed override and simulated I/O). For more information, see Technical reference manual - System parameters, section Auto

Condition Reset.

Restarting the controller

If the controller is restarted, all NORMAL tasks will keep their status while all

STATIC and SEMISTATIC tasks will be deselected from the tasks panel. As the controller starts up all STATIC and SEMISTATIC tasks will be started and then run continuously.

Deselect task in synchronized mode

If a task is in a synchronized mode, that is program pointer between

SyncMoveOn and

SyncMoveOff

, the task can be deselected but not reselected. The task cannot be selected until the synchronization is terminated. If the execution continues, the synchronization will eventually be terminated for the other tasks, but not for the deselected task. The synchronization can be terminated for this task by moving the program pointer to main or to a routine.

If the system parameter Reset is set to Yes, any attempt to change to Auto mode will fail while a deselected task is in synchronized mode. Changing to Auto mode should make all NORMAL tasks selected, and when this is not possible it is not possible to change to Auto mode.





9.1.5.1 Persistent variables

9.1.5 Communication between tasks

9.1.5.1 Persistent variables

About persistent variables

To share data between tasks, use persistent variables.

A persistent variable is global in all tasks where it is declared. The persistent variable must be declared as the same type and size (array dimension) in all tasks.

Otherwise a runtime error will occur.

It is sufficient to specify an initial value for the persistent variable in one task. If initial values are specified in several tasks, only the initial value of the first module to load will be used.

Tip

When a program is saved, the current value of a persistent variable will be used as initial value in the future. If this is not desired, reset the persistent variable directly after the communication.

Example with persistent variable

In this example the persistent variables startsync and stringtosend are accessed by both tasks, and can therefore be used for communication between the task programs.

Main task program:

MODULE module1

PERS bool startsync:=FALSE;

PERS string stringtosend:="";

PROC main() stringtosend:="this is a test"; startsync:= TRUE

ENDPROC

ENDMODULE

Background task program:

MODULE module2

PERS bool startsync;

PERS string stringtosend;

PROC main()

WaitUntil startsync;

IF stringtosend = "this is a test" THEN

...

ENDIF

!reset persistent variables startsync:=FALSE; stringtosend:="";

ENDPROC

ENDMODULE






9.1.5.1 Persistent variables

Continued

Module for common data

When using persistent variables in several tasks, there should be declarations in all the tasks. The best way to do this, to avoid type errors or forgetting a declaration somewhere, is to declare all common variables in a system module. The system module can then be loaded into all tasks that require the variables.





9.1.5.2 Waiting for other tasks

9.1.5.2 Waiting for other tasks

Two techniques

Some applications have task programs that execute independently of other tasks, but often task programs need to know what other tasks are doing.

A task program can be made to wait for another task program. This is accomplished either by setting a persistent variable that the other task program can poll, or by setting a signal that the other task program can connect to an interrupt.

Polling

This is the easiest way to make a task program wait for another, but the performance will be the slowest. Persistent variables are used together with the instructions

WaitUntil or

WHILE

.

If the instruction

WaitUntil is used, it will poll internally every 100 ms.

CAUTION

Do not poll more frequently than every 100 ms. A loop that polls without a wait instruction can cause overload, resulting in lost contact with the FlexPendant.

Polling example


MODULE module1


PROC main() startsync:= TRUE;

...

ENDPROC

ENDMODULE


MODULE module2


PROC main()

WaitUntil startsync;

! This is the point where the execution

! continues after startsync is set to TRUE

...

ENDPROC

ENDMODULE

Interrupt

By setting a signal in one task program and using an interrupt in another task program, quick response is obtained without the work load caused by polling.

The drawback is that the code executed after the interrupt must be placed in a trap routine.






9.1.5.2 Waiting for other tasks

Continued

Interrupt example


MODULE module1

PROC main()

SetDO do1,1;

...

ENDPROC

ENDMODULE


MODULE module2

VAR intnum intno1;

PROC main()

CONNECT intno1 WITH wait_trap;

ISignalDO do1, 1, intno1;

WHILE TRUE DO

WaitTime 10;

ENDWHILE

ENDPROC

TRAP wait_trap

! This is the point where the execution

! continues after do1 is set in main task

...

IDelete intno1;

ENDTRAP

ENDMODULE





9.1.5.3 Synchronizing between tasks

9.1.5.3 Synchronizing between tasks

Synchronizing using WaitSyncTask

Synchronization is useful when task programs are depending on each other. No task program will continue beyond a synchronization point in the program code until all task programs have reached that point in the respective program code.

The instruction

WaitSyncTask is used to synchronize task programs. No task program will continue its execution until all task programs have reached the same

WaitSyncTask instruction.

WaitSyncTask example

In this example, the background task program calculates the next object's position while the main task program handles the robots work with the current object.

The background task program may have to wait for operator input or I/O signals, but the main task program will not continue with the next object until the new position is calculated. Likewise, the background task program must not start the next calculation until the main task program is done with one object and ready to receive the new value.


MODULE module1

PERS pos object_position:=[0,0,0];

PERS tasks task_list{2} := [["MAIN"], ["BACK1"]];


PROC main()

VAR pos position;

WHILE TRUE DO

!Wait for calculation of next object_position

WaitSyncTask sync1, task_list; position:=object_position;

!Call routine to handle object handle_object(position);

ENDWHILE

ENDPROC

PROC handle_object(pos position)

...

ENDPROC

ENDMODULE


MODULE module2

PERS pos object_position:=[0,0,0];

PERS tasks task_list{2} := [["MAIN"], ["BACK1"]];







9.1.5.3 Synchronizing between tasks

Continued

PROC main()

WHILE TRUE DO

!Call routine to calculate object_position calculate_position;

!Wait for handling of current object

WaitSyncTask sync1, task_list;

ENDWHILE

ENDPROC

PROC calculate_position()

...

object_position:= ...

ENDPROC

ENDMODULE





9.1.5.4 Using a dispatcher

9.1.5.4 Using a dispatcher

What is a dispatcher?

A digital signal can be used to indicate when another task should do something.

However, it cannot contain information about what to do.

Instead of using one signal for each routine, a dispatcher can be used to determine which routine to call. A dispatcher can be a persistent string variable containing the name of the routine to execute in another task.

Dispatcher example

In this example, the main task program calls routines in the background task by setting routine_string to the routine name and then setting do5 to 1. In this way, the main task program initialize that the background task program should execute the routine clean_gun first and then routine1

.


MODULE module1

PERS string routine_string:="";

PROC main()

!Call clean_gun in background task routine_string:="clean_gun";

SetDO do5,1;

WaitDO do5,0;

!Call routine1 in background task routine_string:="routine1";

SetDO do5,1;

WaitDO do5,0;

...

ENDPROC

ENDMODULE


MODULE module2

PERS string routine_string:="";

PROC main()

WaitDO do5,1;

%routine_string%;

SetDO do5,0;

ENDPROC

PROC clean_gun()

...

ENDPROC

PROC routine1()

...






9.1.5.4 Using a dispatcher

Continued

ENDPROC

ENDMODULE





9.1.6.1 Share resource between tasks

9.1.6 Other programming issues

9.1.6.1 Share resource between tasks

Flag indicating occupied resource

System resources, such as FlexPendant, file system and I/O signals, are available from all tasks. However, if several task programs use the same resource, make sure that they take turns using the resource, rather than using it at the same time.

To avoid having two task programs using the same resource at the same time, use a flag to indicate that the resource is already in use. A boolean variable can be set to true while the task program uses the resource.

To facilitate this handling, the instruction

TestAndSet is used. It will first test the flag. If the flag is false, it will set the flag to true and return true. Otherwise, it will return false.

Example with flag and TestAndSet

In this example, two task programs try to write three lines each to the FlexPendant.

If no flag is used, there is a risk that these lines are mixed with each other. By using a flag, the task program that first execute the

TestAndSet instruction will write all three lines first. The other task program will wait until the flag is set to false and then write all its lines.


PERS bool tproutine_inuse := FALSE;

...

WaitUntil TestAndSet(tproutine_inuse);

TPWrite "First line from MAIN";

TPWrite "Second line from MAIN";

TPWrite "Third line from MAIN"; tproutine_inuse := FALSE;


PERS bool tproutine_inuse := FALSE;

...

WaitUntil TestAndSet(tproutine_inuse);

TPWrite "First line from BACK1";

TPWrite "Second line from BACK1";

TPWrite "Third line from BACK1"; tproutine_inuse := FALSE;




313


9.1.6.2 Test if task controls mechanical unit

9.1.6.2 Test if task controls mechanical unit

Two functions for inquiring

There are functions for checking if the task program has control of any mechanical unit,

TaskRunMec

, or of a robot,

TaskRunRob

.

TaskRunMec will return true if the task program controls a robot or other mechanical unit.

TaskRunRob will only return true if the task program controls a robot with

TCP.

TaskRunMec and

TaskRunRob are useful when using MultiMove. With MultiMove you can have several tasks controlling mechanical units, see Application manual - MultiMove.

Note

For a task to have control of a robot, the parameter Type must be set to NORMAL and MotionTask must be set to YES. See


Example with TaskRunMec and TaskRunRob

In this example, the maximum speed for external equipment is set. If the task program controls a robot, the maximum speed for external equipment is set to the same value as the maximum speed for the robot. If the task program controls external equipment but no robot, the maximum speed is set to 5000 mm/s.

IF TaskRunMec() THEN

IF TaskRunRob() THEN

!If task controls a robot

MaxExtSpeed := MaxRobSpeed();

ELSE

!If task controls other mech unit than robot

MaxExtSpeed := 5000;

ENDIF

ENDIF





9.1.6.3 taskid

9.1.6.3 taskid taskid syntax

A task always has a predefined variable of type taskid that consists of the name of the task and the postfix "Id". For example, the variable name of the MAIN task is MAINId.

Code example

In this example, the module PART_A is saved in the task BACK1, even though the

Save instruction is executed in another task.

BACK1Id is a variable of type taskid that is automatically declared by the system.

Save \TaskRef:=BACK1Id, "PART_A"

\FilePath:="HOME:/DOORDIR/PART_A.MOD";




315


9.1.6.4 Avoid heavy loops

9.1.6.4 Avoid heavy loops

Background tasks loop continuously

A task program is normally executed continuously. This means that a background task program is in effect an eternal loop. If this program does not have any waiting instruction, the background task may use too much computer power and make the controller unable to handle the other tasks.

Example

MODULE background_module

PROC main()

WaitTime 1;

IF di1=1 THEN

...

ENDIF

ENDPROC

ENDMODULE

If there was no wait instruction in this example and di1 was 0, then this background task would use up the computer power with a loop doing nothing.





9.2.1 Introduction to Sensor Interface

9.2 Sensor Interface [628-1]

9.2.1 Introduction to Sensor Interface

Purpose

The option Sensor Interface is used for communication with external sensors via a serial channel.

The serial channel may be accessed using a package of RAPID instructions that provide the ability to read and write sensor data.

An interrupt feature allows subscriptions on changes in sensor data.

Tip

The communication provided by Sensor Interface is integrated in arc welding instructions for seam tracking and adaptive control of process parameters. These instructions handle communication and corrections for you, whereas with Sensor

Interface you handle this yourself. For more information, see Application manual - Arc and Arc Sensor and Application manual - Continuous Application

Platform.


The RobotWare option Sensor Interface gives you access to:

• Instruction used to connect to a sensor device:

SenDevice

.

• Instruction used to set up interrupt, based on input from the serial sensor interface:

IVarValue

.

• Instructions used to read and write to and from a device connected to the serial sensor interface:

ReadBlock

,

WriteBlock and

WriteVar

.

• Function for reading from a device connected to the serial sensor interface:

ReadVar

.

Basic approach

This is the basic approach for using Sensor Interface.

1 Configure the sensor. See

Configuring sensors over serial channels on page 319 .

2 Use interrupts in the RAPID code to make adjustments according to the input from the sensor. For an example, see

Interrupt welding to adjust settings on page 324 .

Limitations

Interrupts with

IVarValue is only possible to use with the instructions

ArcL

,

ArcC

,

CapL

, and

CapC

. The switch

Track must be used. That is, the controller must be equipped with either RobotWare Arc or Continuous Application Platform together with Optical Tracking, or with the option Weldguide.




317


9.2.2.1 About the sensors

9.2.2 Configuring sensors

9.2.2.1 About the sensors

Supported sensors

Sensor Interface supports:

• Sensors connected via serial channels using the RTP1 protocol. For configuration, see

Configuring sensors over serial channels on page 319

.

• Sensors connected to Ethernet using the RoboCom Light protocol from

Servo-Robot Inc or LTAPP protocol from ABB. For configuration, see

Configuring sensors over Ethernet channel on page 320 .





9.2.2.2 Configuring sensors over serial channels

9.2.2.2 Configuring sensors over serial channels

Overview

Sensor Interface communicates with a maximum of two sensors over serial channels using the RTP1 protocol.


This is a brief description of the parameters used when configuring a sensor. For more information about the parameters, see Technical reference manual - System parameters.

These parameters belong to the type Transmission Protocol in the topic

Communication.

Parameter

Name

Type

Serial Port

Description

The name of the transmission protocol.

For a sensor the name must end with ":". For example "laser1:" or

"swg:".

The type of transmission protocol.

For a sensor using serial channel, it has to be "RTP1".

The name of the serial port that will be used for the sensor. This refers to the parameter Name in the type Serial Port.

For information on how to configure a serial port, see Technical reference manual - System parameters.

Configuration example

This is an example of how a transmission protocol can be configured for a sensor.

We assume that there already is a serial port configured with the name "COM1".

Name

laser1:

Type

RTP1

Serial Port

COM1




319


9.2.2.3 Configuring sensors over Ethernet channel

9.2.2.3 Configuring sensors over Ethernet channel

Overview

Sensor Interface communicates with a maximum of six sensors over Ethernet channel using the RoboCom Light protocol version E04 (from Servo-Robot Inc) or the LTAPP protocol (from ABB). RoboCom Light is an XML based protocol using

TCP/IP.

The sensor acts as a server, the robot controller acts as a client. I.e. the robot controller initiates the connection to the sensor.

RoboCom Light expects TCP port 6344 on the external sensor side, and LTAPPTCP expects TCP port 5020.


This is a brief description of the parameters used when configuring a sensor. For more information about the parameters, see Technical reference manual - System parameters.

These parameters belong to the type Transmission Protocol in the topic

Communication.

Parameter

Name

Type

Serial Port

Remote Address

Description


For a sensor the name must end with ":". For example "laser1:" or

"swg:".


For RoboCom Light the protocol type SOCKDEV has to be configured, and for LTAPPTCP it is LTAPPTCP.

The name of the serial port that will be used for the sensor. This refers to the parameter Name in the type Serial Port.

For information on how to configure a serial port, see Technical reference manual - System parameters.

For IP based transmission protocols (i.e. Type has value TCP/IP,

SOCKDEV, LTAPPTCP or UDPUC), Serial Port is not used and has the value N/A.

The IP address of the sensor. This refers to the type Remote Address.

For information on how to configure Remote Address, see Technical reference manual - System parameters.

Configuration examples

These are examples of how a transmission protocol can be configured for a sensor.

Name

laser2: laser3:

Type

SOCKDEV

LTAPPTCP

Serial Port

N/A

N/A

Remote Address

192.168.125.101

192.168.125.102






9.2.3 RAPID


Data types

There are no data types for Sensor Interface.

Instructions

This is a brief description of each instruction in Sensor Interface. For more information, see respective instruction in Technical reference manual - RAPID


Instruction

SenDevice

IVarValue

ReadBlock

WriteBlock

WriteVar

Description

SenDevice is used, to connect to a physical sensor device.

IVarVal

(Interrupt Variable Value) is used to order and enable an interrupt when the value of a variable accessed via the serial sensor interface is changed.

ReadBlock is used to read a block of data from a device connected to the serial sensor interface. The data is stored in a file.

ReadBlock can only be used with a serial channel connected sensor (not

Ethernet connected sensor.)

WriteBlock is used to write a block of data to a device connected to the serial sensor interface. The data is fetched from a file.

WriteBlock can only be used with a serial channel connected sensor (not

Ethernet connected sensor.)

WriteVar is used to write a variable to a device connected to the serial sensor interface.

Functions

This is a brief description of each function in Sensor Interface. For more information, see respective function in Technical reference manual - RAPID Instructions,


Function

ReadVar

Description

ReadVar is used to read a variable from a device connected to the serial sensor interface.

Modules

The option Sensor Interface includes one system module, LTAPP__Variables. This module contains the variable numbers defined in the protocol LTAPP. It is automatically loaded as SHARED and makes the variables (CONST num) available in all RAPID tasks.

Note! A copy of the module is placed in the robot system directory HOME/LTC, but the copy is NOT the loaded module.





321



Continued

Constants

Name

LTAPP__VERSION

LTAPP__RESET

Number

1

3

LTAPP__PING 4

LTAPP__CAMCHECK 5

LTAPP__POWER_UP 6

LTAPP__LASER_OFF 7

LTAPP__X 8

LTAPP__Y

LTAPP__Z

LTAPP__GAP

LTAPP__MISMATCH 12

LTAPP__AREA 13

LTAPP__THICKNESS 14

LTAPP__STEPDIR

LTAPP__JOINT_NO

LTAPP__AGE

LTAPP__ANGLE

15

16

17

18

9

10

11

LTAPP__UNIT

-

LTAPP__APM_P1


322

19

20

31




Name

LTAPP__APM_P2

LTAPP__APM_P3

LTAPP__APM_P4

LTAPP__APM_P5

LTAPP__APM_P6

LTAPP__ROT_Y

LTAPP__ROT_Z



Continued

34

35

36

51

52

Number

32

33

R

R

Read/write Description

R

R

Servo robot only! Adaptive parameter

2


3

R

R

R


4


5


6

Measured angle around sensor Y axis

Measured angle around sensor Z axis

A




323



9.2.4 Examples


Interrupt welding to adjust settings

This is an example of a welding program where a sensor is used. The sensor reads the gap (in mm) and an interrupt occurs every time the value from the sensor changes. The new value from the sensor is then used to determine correct settings for voltage, wire feed and speed.

LOCAL PERS num adptVlt{8}:=

[1,1.2,1.4,1.6,1.8,2,2.2,2.5];

LOCAL PERS num adptWfd{8}:=

[2,2.2,2.4,2.6,2.8,3,3.2,3.5];

LOCAL PERS num adptSpd{8}:=

[10,12,14,16,18,20,22,25];

LOCAL CONST num GAP_VARIABLE_NO:=11;

PERS num gap_value:=0;

PERS trackdata track:=[0,FALSE,150,[0,0,0,0,0,0,0,0,0],

[3,1,5,200,0,0,0]];

VAR intnum IntAdap;

PROC main()

! Setup the interrupt. The trap routine AdapTrap will be called when the gap variable with number GAP_VARIABLE_NO in the sensor interface has been changed. The new value will be available in the gap_value variable.

CONNECT IntAdap WITH AdapTrap;

IVarValue "laser1:", GAP_VARIABLE_NO, gap_value, IntAdap;

! Start welding

ArcLStart p1,v100,adaptSm,adaptWd,fine, tool\j\Track:=track;

ArcLEnd p2,v100,adaptSm,adaptWd,fine, tool\j\Track:=track;

ENDPROC

TRAP AdapTrap

VAR num ArrInd;

! Scale the raw gap value received

ArrInd:=ArrIndx(gap_value);

! Update active weld data variable adaptWd with new data from the predefined parameter arrays.

! The scaled gap value is used as index in the voltage, wirefeed and speed arrays.

adaptWd.weld_voltage:=adptVlt{ArrInd}; adaptWd.weld_wirefeed:=adptWfd{ArrInd}; adaptWd.weld_speed:=adptSpd{ArrInd};

! Request a refresh of welding parameters using the new data in adaptWd

ArcRefresh;







Continued

ENDTRAP

FUNC ArrIndx(num value)

IF value < 0.5 THEN RETURN 1;

ELSEIF value < 1.0 THEN RETURN 2;






ELSE RETURN 8;

ENDIF

ENDFUNC

Reading positions from sensor

In this example, the sensor is turned on and the coordinates are read from the sensor.

! Define variable numbers

CONST num SensorOn := 6;

CONST num YCoord := 9;

CONST num ZCoord := 10;

! Define the transformation matrix

CONST pose SensorMatrix := [[100,0,0],[1,0,0,0]];

VAR pos SensorPos;

VAR pos RobotPos;

! Request start of sensor measurements

WriteVar SensorOn, 1;

! Read a Cartesian position from the sensor

SensorPos.x := 0;

SensorPos.y := ReadVar (YCoord);

SensorPos.z := ReadVar (ZCoord);

! Stop sensor

WriteVar SensorOn, 0;

! Convert to robot coordinates

RobotPos := PoseVect(SensorMatrix, SensorPos);




325


9.3.1.1 Overview

9.3 Externally Guided Motion [689-1]

9.3.1 Introduction to EGM


Purpose

Externally Guided Motion (EGM) offers two different features:

• EGM Position Guidance:

The robot does not follow a programmed path in RAPID but a path generated by an external device.

• EGM Path Correction:

The programmed robot path is modified/corrected using measurements provided by an external device.

EGM Position Guidance

The purpose of EGM Position Guidance is to use an external device to generate position data for one or several robots. The robots will be moved to that given position.

Some examples of applications are:

• Place an object (for example a car door or a window) at a location (for example a car body) that was given by an external sensor.

• Bin picking. Pick objects from a bin using an external sensor to identify the object and its position.

EGM Path Correction

The purpose of EGM Path Correction is to use external robot mounted devices to generate path correction data for one or several robots. The robots will be moved along the corrected path, which is the programmed path with added measured corrections.


• Seam tracking.

• Tracking of objects moving near a known path.


The RobotWare option Externally Guided Motion gives you access to:

• Instructions to set up, activate, and reset EGM Position Guidance.

• Instructions to set up, activate, and reset EGM Path Correction.

• Instructions to initiate EGM Position Guidance movements and to stop them.

• Instructions to perform EGM Path Correction movements.

• A function to retrieve the current EGM state.

• System parameters to configure EGM and set default values.






9.3.1.1 Overview

Continued

Limitations

Limitations for EGM Position Guidance

• It is not possible to perform linear movements using EGM Position Guidance, since EGM Position Guidance does not contain interpolator functionality.

The actual path of the robot will depend on the robot configuration, the start position, and the generated position data.

• EGM Position Guidance does not support MultiMove.

• It is not possible to use EGM Position Guidance to guide a mechanical unit in a moving work object.

•

• If the robot ends up near a singularity, i.e. when two robot axis are nearly parallel, the robot movement will be stopped with an error message. In that situation the only way is to jog the robot out of the singularity.

Limitations for EGM Path Correction

• The external device has to be robot mounted.

• Corrections can only be applied in the path coordinate system.

• Only position correction in y and z can be performed. It is not possible to perform orientation corrections, nor corrections in x (which is the path direction/tangent).

Common limitations for EGM

• EGM can only be used on 6-axis robots.

• EGM can only be used in RAPID tasks with a robot, i.e. it is not possible to use it in a task that contains only additional axis, i.e. in robtargets there are values in the pose portion of the data.

• An EGM movement has to start in a fine point.

• Only one external device can be used for each robot to provide correction data.




327


9.3.1.2 Introduction to EGM Position Guidance

9.3.1.2 Introduction to EGM Position Guidance

What is EGM Position Guidance

EGM Position Guidance is designed for advanced users and provides a low level interface to the robot controller, by by-passing the path planning that can be used when highly responsive robot movements are needed. EGM Position Guidance can be used to read positions from and write positions to the motion system at a high rate. This can be done every 4 ms with a control lag of 10–20 ms depending on the robot type. The references can either be specified using joint values or a pose. The pose can be defined in any work object that is not moved during the

EGM Position Guidance movement.

All necessary filtering, supervision of references, and state handling is handled by

EGM Position Guidance. Examples of state handling are program start/stop, emergency stop, etc.

The main advantage of EGM Position Guidance is the high rate and low delay/latency compared to other means of external motion control. The time between writing a new position until that given position starts to affect the actual robot position, is usually around 20 ms.

EGM handles Absolute Accuracy.

What EGM Position Guidance does not do

EGM goes directly into the motor reference generation, i.e. it does not provide any path planning. This means that you cannot order a movement to a pose target and expect a linear movement. It is not possible either to order a movement with a specified speed or order a movement that is supposed to take a specified time.

For ordering such movements path planning is needed and we refer you to the standard movement instructions in RAPID, i.e.

MoveL

,

MoveJ

, etc.

WARNING

Since the path planning is by-passed by EGM in the robot controller, the robot path is created directly from user input. It is therefore important to make sure that the stream of position references sent to the controller is as smooth as possible. The robot will react quickly to all position references sent to the controller, also faulty ones.





9.3.1.3 Introduction to EGM Path Correction

9.3.1.3 Introduction to EGM Path Correction

What is EGM Path Correction

EGM Path Correction gives the user the possibility to correct a programmed robot path. The device or sensor that is used to measure the actual path has to be mounted on the tool flange of the robot and it must be possible to calibrate the sensor frame.

The corrections are performed in the path coordinate system, which gets its x-axis from the tangent of the path, the y-axis is the cross product of the path tangent, and the z-direction of the active tool frame and the z-axis is the cross product of x-axis and y-axis.

EGM Path correction has to start and end in a fine point. The sensor measurements can be provided at multiples of about 48 ms.




329


9.3.2.1 Basic approach

9.3.2 Using EGM

9.3.2.1 Basic approach

Basic approach for EGM Position Guidance

This is the general approach to move/guide a robot using an external device

(sensor) to give the target for the movement.

1

2

3

4

5

6

7

Action

Move the robot to a fine point.

Register an EGM client and get an EGM identity. This identity is then used to link setup, activation, movement, deactivation etc. to a certain EGM usage. The EGM state is still

EGM_STATE_DISCONNECTED

.

Call an EGM setup instruction to set up the position data source using signals or UdpUc protocol connection. The EGM state changes to

EGM_STATE_CONNECTED

.

Choose if the position is given as joint values or as a pose and give the position convergence criteria, i.e. when the position is considered to be reached.

If pose was chosen, define which frames are used to define the target position and in which frame the movement is to be applied.

Give the stop mode, an optional time-out and perform the movement itself. Now the

EGM state is

EGM_STATE_RUNNING

. This is when the robot is moving.

The EGM movement will stop when the position is considered to be reached, i.e. the convergence criteria is fulfilled. Now the EGM state has changed back to

EGM_STATE_CONNECTED

.

Basic approach for EGM Path Correction

This is the general approach to correct a programmed path with EGM Path

Correction.

4

5

1

2

3

6

Action

Move the robot to a fine point.

Register an EGM client and get an EGM identity. This identity is then used to link setup, activation, movement, deactivation etc. to a certain EGM usage. The EGM state is still


.

Call an EGM setup instruction to set up the position data source using signals or UdpUc protocol connection. The EGM state changes to

EGM_STATE_CONNECTED

.

Define the sensor correction frame, which always is a tool frame.

Perform the movement itself. Now the EGM state is

EGM_STATE_RUNNING

.

At the next fine point EGM will return to the state

EGM_STATE_CONNECTED

.

To free an EGM identity for use with another sensor you have to reset EGM, which returns EGM to the state


.





9.3.2.2 Execution states

9.3.2.2 Execution states

Description

The EGM process has different states:

Value Description


The EGM state of the specific process is undefined.

No setup is active.

EGM_STATE_CONNECTED

EGM_STATE_RUNNING

The specified EGM process is not activated.

Setup has been made, but no EGM movement is active.

The specified EGM process is running.

The EGM movement is active, i.e. the robot is moved.

Transitions between the different states are according to the figure below.

EGMReset


SetupAI, or SetupAO, or

SetupGI, or SetupUC

EGM_STATE_CONNECTED

EGMRunJoint and

EGMRunPose finishes, or EGMStop

EGMRunJoint or

EGMRunPose

EGM_STATE_RUNNING xx1400001082

The RAPID instructions

EGMRunJoint and

EGMRunPose start from

EGM_STATE_CONNECTED and change the state to

EGM_STATE_RUNNING as long as the convergence criteria for the target position have not been met or the timeout time has not expired. When one of these conditions is met, the EGM state is changed to

EGM_STATE_CONNECTED again and the instruction ends, i.e. RAPID execution continues to the next instruction.

If EGM has the state

EGM_STATE_RUNNING and RAPID execution is stopped, EGM enters the state

EGM_STATE_CONNECTED

. At program restart, EGM returns to the state

EGM_STATE_RUNNING

.

If the program pointer is moved using PP to Main or PP to cursor, the EGM state is changed to

EGM_STATE_CONNECTED

, if the state was

EGM_STATE_RUNNING

.




331


9.3.2.3 Input data

9.3.2.3 Input data

Input data for EGM Position Guidance

The source for input data is selected using the EGM setup instructions. The three first instructions select a signal interface and the last instruction a UdpUc interface

(User Datagram Protocol Unicast Communication).

Instructions

EGMSetupAI

EGMSetupAO

EGMSetupGI

EGMSetupUC

Description

Setup analog input signals for EGM

Setup analog output signals for EGM

Setup group input signals for EGM

Setup the UdpUc protocol for EGM

Input data for EGM contain mainly position data either as joints or as a pose, i.e.

Cartesian position plus orientation.

The data flow for the signal interface is illustrated below:

Sensor

AO

GO

• Write position values to signals

(multiple of 4 ms)

AI

GI

I/O

2) Read new position values from the signals

(AI, AO, GI)

EGM

1) Request (multiple of 4 ms)

Motion control

AO

Set from

RAPID

3) Write position xx1400002016

1 Motion control calls EGM.

2 EGM reads the position values from the signals.

3 EGM writes the position data to motion control.

• The sensor writes position data to the signals.

If signals are used as data source, the input is limited to 6 for the robot, i.e. 6 joint values or 3 Cartesian position values (x, y, z) plus 3 Euler angle values (rx, ry, rz), and up to 6 values for additional axes.






9.3.2.3 Input data

Continued

The data flow for the UdpUc interface is illustrated below:

Sensor

4) Check for new position

EGM

• Send position

(UDP ≥ 4 ms)


2) Read feedback

Motion control

5) Write position

3) Send feedback xx1400002017


2 EGM reads feedback data from motion control.

3 EGM sends feedback data to the sensor.

4 EGM checks the UDP queue for messages from the sensor.

5 If there is a message, EGM reads the next message and step 5 writes the position data to motion control. If no position data had been sent, motion control continues to use the latest position data previously written by EGM.

• The sensor sends position data to the controller (EGM). Our recommendation is to couple this to step 3. Then the sensor will be in phase with the controller.

The control loop is based on the following relation between speed and position: speed = k * (pos_ref – pos) + speed_ref k - factor pos_ref - reference position pos - desired position speed_ref - reference speed

For instructions on how to implement the UdpUc protocol for an external device, see

The EGM sensor protocol on page 339 . There you will also find a description

of input data.

Input data for EGM Path Correction

The source for input data is selected using the EGM setup instructions. The three first instructions select a signal interface and the last instruction a UdpUc interface

(User Datagram Protocol Unicast Communication).

Instructions

EGMSetupAI

EGMSetupAO

EGMSetupGI

EGMSetupUC

Description

Setup analog input signals for EGM

Setup analog output signals for EGM

Setup group input signals for EGM

Setup the UdpUc protocol for EGM

Input data for EGM contain mainly position data.






9.3.2.3 Input data

Continued

The data flow for the signal interface is illustrated below:

Sensor

AO

GO

• Write position values to signals

(multiple of 4 ms)

I/O

AI

GI AO

2) Read new position values from the signals

(AI, AO, GI)

EGM


Motion control

3) Write position

Set from

RAPID xx1400002016


2 The measurement data (y- and z-values) are read from the signals or fetched from the sensor at multiples of about 48 ms.

3 EGM calculates the position correction and writes it to motion control. If the

UdpUc protocol is used, feedback is sent to the sensor.





9.3.2.4 Output data

9.3.2.4 Output data

Description

Output data is only available for the UdpUc interface.

For instructions on how to implement the UdpUc protocol for an external device, see

The EGM sensor protocol on page 339 . There you will also find a description

of output data.




335


9.3.2.5 Configuration

9.3.2.5 Configuration

Configuration for EGM Position Guidance

EGM behavior can be influenced using the system parameters of type External

Motion Interface Data topic Motion. For a description of all available EGM parameters, see


.

Here follows a closer description of the two parameters that influence the EGM control loop. The figure shows a simplified view of the EGM control system.

EGM controller

Speed feed-forward

+

Position gain

LP filter

Speed reference

Servo control

Robot

Sensor xx1400001083

Default proportional Position Gain

Default Low Pass Filter Bandwith

Time

The parameter Position gain in the figure influences the responsiveness moving to the target position, given by the sensor, in relation to the current robot position. The higher the value, the faster the response.

The parameter LP Filter in the figure is the default value used to filter the speed contribution from EGM.





9.3.2.6 Frames

9.3.2.6 Frames

Frames for EGM Position Guidance

EGM can be run in two different modes, joint mode and pose mode. The following section applies to the EGM pose mode only.

For the joint mode there is no need for reference frames, because both sensor values and position values are axis angles given in degrees relative to the calibration position of each axis. But for the pose mode reference frames are necessary.

Measurements from the sensor and directions for position change can only be given relative to reference frames.


EGMActPose defines all frames that are available in EGM:

Frame

Tool

Work object

Correction

Sensor

Description

The tool data to be used for the EGM process is defined with the optional

\Tool argument.

The work object data used for the EGM process is defined with the optional

\Wobj argument.

The frame to be used to give the final movement direction is defined by the mandatory

CorrFrame argument.

The frame to be used to interpret the sensor data is defined by the mandatory

SensorFrame argument.

Tools and work objects

The tool and the work object may be defined in two combinations only:

1 If the tool is attached to the robot, the work object has to be fixed.

2 If the tool is fixed, the work object has to be attached to the robot.

Note

It is not possible to use a work object or tool that is attached to any other mechanical unit than the EGM robot.

Predefined frame types

For the frames

CorrFrame and

SensorFrame it is also necessary to know what they are related to. This information is specified using the predefined frame types in the data type egmframetype:

Value

EGM_FRAME_BASE

EGM_FRAME_TOOL

EGM_FRAME_WOBJ

EGM_FRAME_WORLD

EGM_FRAME_JOINT

Description

The frame is defined relative to the base frame (pose mode).

The frame is defined relative to tool0

(pose mode).

The frame is defined relative to the active work object (pose mode).

The frame is defined relative to the world frame (pose mode).

The values are joint values (joint mode).

Frames for EGM Path Correction

EGM can be run in two different modes, joint mode and pose mode. The following section applies to the EGM pose mode only.






9.3.2.6 Frames

Continued

For the joint mode there is no need for reference frames, because both sensor values and position values are axis angles given in degrees relative to the calibration position of each axis. But for the pose mode reference frames are necessary.

Measurements from the sensor and directions for position change can only be given relative to reference frames.


EGMActPose defines all frames that are available in EGM:

Frame

Tool

Work object

Correction

Sensor

Description

The tool data to be used for the EGM process is defined with the optional

\Tool argument.

The work object data used for the EGM process is defined with the optional

\Wobj argument.

The frame to be used to give the final movement direction is defined by the mandatory

CorrFrame argument.

The frame to be used to interpret the sensor data is defined by the mandatory

SensorFrame argument.

Tools and work objects

The tool and the work object may be defined in two combinations only:

1 If the tool is attached to the robot, the work object has to be fixed.

2 If the tool is fixed, the work object has to be attached to the robot.

Note

It is not possible to use a work object or tool that is attached to any other mechanical unit than the EGM robot.

Predefined frame types

For the frames

CorrFrame and

SensorFrame it is also necessary to know what they are related to. This information is specified using the predefined frame types in the data type egmframetype:

Value

EGM_FRAME_BASE

EGM_FRAME_TOOL

EGM_FRAME_WOBJ

EGM_FRAME_WORLD

EGM_FRAME_JOINT

Description

The frame is defined relative to the base frame (pose mode).

The frame is defined relative to tool0

(pose mode).

The frame is defined relative to the active work object (pose mode).

The frame is defined relative to the world frame (pose mode).

The values are joint values (joint mode).





9.3.3 The EGM sensor protocol

9.3.3 The EGM sensor protocol

Description

The EGM sensor protocol is designed for high speed communication between a robot controller and a communication endpoint with minimum overhead.

The communication endpoint is typically a sensor, so sensor will be used from now on instead of communication endpoint. Sometimes the sensor is connected to a PC, and the PC then transfers the sensor data to the robot. The purpose of the sensor protocol is to communicate sensor data frequently between the robot controller and sensors. The EGM sensor protocol is using Google Protocol Buffers for encoding and UDP as a transport protocol. Google Protocol Buffers has been selected due to its speed and its language-neutrality. UDP has been chosen as a transport protocol since the data sent is real-time data sent with high frequency and if packets get lost it is useless to re-send the data.

The EGM sensor protocol data structures are defined by the EGM proto file. Sensor name, IP-address and port number of sensors are configured in the system parameters. A maximum of eight sensors can be configured.

The sensor is acting as a server and it cannot send anything to the robot before it has received a first message from the robot controller. Messages can be sent independently of each other in both directions after that first message. Applications using the protocol may put restrictions on its usage but the protocol itself has no built-in synchronization of request responses or supervision of lost messages.

There are no special connect or disconnect messages, only data which can flow in both directions independently of each other. The first message from the robot is a data message. One has also to keep in mind, that a sender of an UDP message continues to send even though the receiver's queue may be full. The receiver has to make sure, that its queue is emptied.

By default, the robot will send and read data from the sensor every 4 milliseconds, independently of when data is sent from the sensor. This cycle time can be changed to a multiple of 4 ms using the optional argument

\SampleRate of the RAPID instructions

EGMActJoint or

EGMActPose

.

Google Protocol Buffers

Google Protocol Buffers or Protobuf, are a way to serialize/de-serialize data in a very efficient way. Protobuf is in general 10-100 times faster than XML. There is plenty of information on the Internet about Protobuf and the Google overview is a good start.

In short, message structures are described in a .proto file. The .proto file is then compiled. The compiler generates serialized/de-serialized code which is then used by the application. The application reads a message from the network, runs the de-serialization, creates a message, calls serialization method, and then sends the message.

It is possible to use Protobuf in most programming languages since Protobuf is language neutral. There are many different implementations depending on the language.







Continued

The main disadvantage with Protobuf is that Protobuf messages are serialized into a binary format which makes it more difficult to debug packages using a network analyzer.

Third party tools

Except for the Google C++ tool, we have also verified the following third party tools and code:

• Nanopb, generates C-code and it does not require any dynamic memory allocations.

• Protobuf-net, a Google Protobuf .NET library.

• Protobuf-csharp,a Google Protobuf .NET library, the C# API is similar to the

Google C++ API.

Note

Note that the code mentioned above is open source, which means that you have to check the license that the code is allowed to be used in your product.

EGM sensor protocol description

The EGM sensor protocol is not a request/response protocol, the sensor can send data at any frequency after the sensor gets the first message from the robot.

The EGM sensor protocol has two main data structures, EgmRobot and EgmSensor.

EgmRobot is sent from the robot and EgmSensor is sent from the sensor. All message fields in both the data structures are defined as optional which means that a field may or may not be present in a message. Applications using Google

Protocol Buffers must check if optional fields are present or not.

The

EgmHeader is common for both EgmRobot and EgmSensor.

message EgmHeader

{ optional uint32 seqno = 1; // sequence number (to be able to find lost messages) optional uint32 tm = 2; // time stamp in milliseconds enum MessageType {

MSGTYPE_UNDEFINED = 0;

MSGTYPE_COMMAND = 1; // for future use

MSGTYPE_DATA = 2; // sent by robot controller

MSGTYPE_CORRECTION = 3; // sent by sensor

} optional MessageType mtype = 3 [default = MSGTYPE_UNDEFINED];

}

Variable

seqno

Description

Sequence number.

Applications shall increase the sequence number by one for each message they send. It makes it possible to check for lost messages in a series of messages.







Continued

Variable

tm mtype

Description

Timestamp in milliseconds.

(Can be used for monitoring of delays).

Message type.

Shall be set to

MSGTYPE_CORRECTION by the sensor, and is set to

MSGTYPE_DATA by the robot controller.

The Google protobuf data structure can include the repeated element, i.e. a list of elements of the same type. The repeated element count is a maximum of six elements in the EGM sensor protocol.

See the egm.proto file for a description of

EgmRobot and

EgmSensor

,

UdpUc code examples on page 355 .

How to build an EGM sensor communication endpoint using .Net

This guide assumes that you build and compile using Visual Studio and are familiar with its operation.

Here is a short description on how to install and create a simple test application using protobuf-csharp-port.

2

3

4

5

1

Action

Download protobuf-csharp binaries from: https://code.google.com/p/protobuf-csharp-port/ .

Unpack the zip-file.

Copy the egm.proto file to a sub catalogue where protobuf-csharp was un-zipped, e.g.

~\protobuf-csharp\tools\egm.

Start a Windows console in the tools directory, e.g. ~\protobuf-csharp\tools.

Generate an EGM C# file (egm.cs) from the egm.proto file by typing in the Windows console: protogen .\egm\egm.proto --proto_path=.\egm

6

7

8

9

10

11

Create a C# console application in Visual Studio.

Create a C# Windows console application in Visual Studio, e.g. EgmSensorApp.

Install NuGet, in Visual Studio, click Tools and then Extension Manager. Go to Online, find the NuGet Package Manager extension and click Download.

Install protobuf-csharp in the solution for the C# Windows Console application using

NuGet. The solution has to be open in Visual Studio.

In Visual Studio select, Tools, Nuget Package Manager, and Package Manager

Console.

Type PM>Install-Package Google.ProtocolBuffers

Add the generated file egm.cs to the Visual Studio project (add existing item).

Copy the example code into the Visual Studio Windows Console application file

(EgmSensorApp.cpp) and then compile, link and run.

How to build an EGM sensor communication endpoint using C++

When building using C++ there are no other third party libraries needed.

C++ is supported by Google. It can be a bit tricky to build the Google tools in

Windows but here is a guide on how to build protobuf for Windows.







Continued

1

2

3

4

5

6

Use the following procedure when you have built libprotobuf.lib and protoc.exe:

Action

Run Google protoc to generate access classes, protoc --cpp_out=. egm.proto

Create a win32 console application

Add Protobuf source as include directory.

Add the generated egm.pb.cc file to the project, exclude the file from precompile headers.

Copy the code from the egm-sensor.cpp file, see

UdpUc code examples on page 355 .

Compile and run.

Configuring UdpUc devices

UdpUc communicates with a maximum of eight devices over Udp. The devices act as servers, and the robot controller acts as a client. It is the robot controller that initiates the connection to the sensor.

System parameters

This is a brief description of the parameters used when configuring a device. For more information about the parameters, see Technical reference manual - System parameters.

These parameters belong to the type Transmission Protocol in topic Communication.

Parameter

Name

Type

Serial Port

Remote Address

Remote Port Number

Description


For example EGMsensor.


It has to be UDPUC.

The name of the serial port that will be used for the sensor.

This refers to the parameter Name in the type Serial Port.

For IP based transmission protocols (i.e. Type has value

TCP/IP, SOCKDEV, LTAPPTCP or UDPUC), Serial Port is not used and has the value N/A.

The IP address of the remote device.

The IP port number that the remote device has opened.

Configuration example

The device which provides the input data for EGM, has to be configured as an

UdpUc device in the following way:

Name

UCdevice

Type

UDPUC

Serial Port Remote Address Remote Port Number

N/A 192.168.10.20

6510

After this configuration change, the controller has to be restarted. Now the device can be used by EGM to guide a robot. For more information, see

Using EGM

Position Guidance with an UdpUc device on page 346

.








This is a brief description of the system parameters used by Externally Guided

Motion. For more information about the parameters, see Technical reference manual - System parameters.

Type External Motion Interface Data

The system parameters used by Externally Guided Motion belong to the type

External Motion Interface Data in topic Motion.

Parameter

Name

Level

Description

The name of the external motion interface data. This name is referenced by the parameter ExtConfigName in the RAPID instructions

EGMSetupAI

,

EGMSetupAO

,

EGMSetupGI

, and

EGMSetupUC

.

External motion interface level determines the system level at which the corrections are applied.

Level 0 corresponds to raw corrections, added just before the servo controllers.

Level 1 applies extra filtering on the correction, but also introduces some extra delays and latency.

Level 2 has to be used for path correction.

Do Not Restart After Motors

Off

Determines if the external motion interface execution should automatically restart after the controller has been in the motors off state, for instance after emergency stop.

Return to Programmed Position when Stopped

Determines if axes currently running external motion interface should return to the programmed position, when program execution is stopped.

If False, axes will stop in their current position.

If True, axes will move to the programmed finepoint.

Default Ramp Time Defines the default total time for stopping external motion interface movements when external motion interface execution is stopped.

The value will be used to determine how fast the speed contribution from external motion should be ramped to zero when program execution is stopped, and how fast axes return to the programmed position if Return to Programmed Position when Stopped is True.

Default Proportional Position

Gain

Defines the default proportional gain of the external motion interface position feedback control. For more information, see

Configuration on page 336

.

Default Low Pass Filter

Bandwidth

Defines the default bandwidth of the low-pass filter used to filter the speed contribution from the external motion interface execution. For more information, see

Configuration on page 336 .




343





This is an overview of all instructions, functions, and data types in Externally Guided

Motion.



Instructions

Instructions

EGMActJoint

EGMActMove

EGMActPose

EGMGetId

EGMMoveC

EGMMoveL

EGMReset

EGMRunJoint

EGMRunPose

EGMSetupAI

EGMSetupAO

EGMSetupGI

Description

EGMActJoint activates a specific EGM process and defines static data for the sensor guided joint movement, i.e. data that is not changed frequently between different EGM movements.

EGMActMove is used to activate a specific EGM process and defines static data for the movement with path correction, i.e. data that is not changed frequently between different EGM path correction movements.

EGMActPose activates a specific EGM process and defines static data for the sensor guided pose movement, i.e. data that is not changed frequently between different EGM movements.

EGMGetId is used to reserve an EGM identity (

EGMid

). That identity is then used in all other EGM RAPID instructions and functions to identify a certain EGM process connected to the RAPID motion task from which it is used.

An egmident is identified by its name, i.e. a second or third call of

EGMGetId with the same egmident will neither reserve a new EGM process nor change its content.

EGMMoveC is used to move the tool center point (TCP) circularly to a given destination with path correction. During the movement the orientation normally remains unchanged relative to the circle.

EGMMoveL is used to move the tool center point (TCP) linearly to a given destination with path correction. When the TCP is to remain stationary then this instruction can also be used to reorient the tool.

EGMReset resets a specific EGM process (

EGMid

), i.e. the reservation is canceled.

EGMRunJoint performs a sensor guided joint movement from a fine point for a specific EGM process (

EGMid

) and defines which joints will be moved.

EGMRunPose performs a sensor guided pose movement from a fine point for a specific EGM process (

EGMid

) and defines which directions and orientations will be changed.

EGMSetupAI is used to set up analog input signals for a specific

EGM process (

EGMid

) as the source for position destination values to which the robot (plus up to 6 additional axis) is to be guided.

EGMSetupAO is used to set up analog output signals for a specific

EGM process (

EGMid

) as the source for position destination values to which the robot, and up to 6 additional axis, is to be guided.

EGMSetupGI is used to set up group input signals for a specific

EGM process (

EGMid

) as the source for position destination values to which the robot, and up to 6 additional axis, is to be guided.





Functions

Data types



Continued

Instructions

EGMSetupLTAPP

EGMSetupUC

EGMStop

Description

EGMSetupLTAPP is used to set up an LTAPP protocol for a specific

EGM process (

EGMid

) as the source for path corrections.

EGMSetupUC is used to set up a UdpUc device for a specific EGM process (

EGMid

) as the source for position destination values to which the robot, and up to 6 additional axis, are to be guided. The position may be given in joints, for

EGMRunJoint

, or in cartesian format for

EGMRunPose

.

EGMStop stops a specific EGM process (

EGMid

).

Functions

EGMGetState

Description

EGMGetState retrieves the state of an EGM process (

EGMid

).

Data types

egmframetype egmident egm_minmax egmstate egmstopmode

Description

egmframetype is used to define the frame types for corrections and sensor measurements in EGM.

egmident identifies a specific EGM process.

egm_minmax is used to define the convergence criteria for EGM to finish.

egmstate is used to define the state for corrections and sensor measurements in EGM.

egmstopmode is used to define the stop modes for corrections and sensor measurements in EGM.




345


9.3.6.1 Using EGM Position Guidance with an UdpUc device

9.3.6 RAPID code examples

9.3.6.1 Using EGM Position Guidance with an UdpUc device

Description

The device which provides the input data for EGM, first has to be configured as an UdpUc device. See

Configuring UdpUc devices on page 342

.

Now the device can be used by EGM to guide a robot. A simple example is the following:

Example

MODULE EGM_test

VAR egmident egmID1;

VAR egmstate egmSt1;

! limits for cartesian convergence: +-1 mm

CONST egm_minmax egm_minmax_lin1:=[-1,1];

! limits for orientation convergence: +-2 degrees

CONST egm_minmax egm_minmax_rot1:=[-2,2];

! Start position

CONST jointtarget jpos10:=[[0,0,0,0,40,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

! Used tool

TASK PERS tooldata tFroniusCMT:=[TRUE,[[12.3313,-0.108707,416.142],

[0.903899,-0.00320735,0.427666,0.00765917]],

[2.6,[-111.1,24.6,386.6],[1,0,0,0],0,0,0.072]];

! corr-frame: wobj, sens-frame: wobj

TASK PERS wobjdata wobj_EGM1:=[FALSE,TRUE,"",

[[150,1320,1140],[1,0,0,0]], [[0,0,0],[1,0,0,0]]];

! Correction frame offset: none

VAR pose corr_frame_offs:=[[0,0,0],[1,0,0,0]];

PROC main()

! Move to start position. Fine point is demanded.

MoveAbsJ jpos10\NoEOffs, v1000, fine, tFroniusCMT; testuc;

ENDPROC

PROC testuc()

EGMReset egmID1;

EGMGetId egmID1; egmSt1:=EGMGetState(egmID1);

TPWrite "EGM state: "\Num:=egmSt1;

IF egmSt1 <= EGM_STATE_CONNECTED THEN

! Set up the EGM data source: UdpUc server using device "EGMsensor:" and






9.3.6.1 Using EGM Position Guidance with an UdpUc device

Continued

! configuration "default"

EGMSetupUC ROB_1, egmID1, "default", "EGMsensor:"\pose;

ENDIF

! Correction frame is the World coordinate system and the sensor measurements are relative

! to the tool frame of the used tool (tFroniusCMT)

EGMActPose egmID1\Tool:=tFroniusCMT, corr_frame_offs,

EGM_FRAME_WORLD, tFroniusCMT.tframe, EGM_FRAME_TOOL

\x:=egm_minmax_lin1 \y:=egm_minmax_lin1 \z:=egm_minmax_lin1

\rx:=egm_minmax_rot1 \ry:=egm_minmax_rot1 \rz:=egm_minmax_rot1

\LpFilter:=20;

! Run: the convergence condition has to be fulfilled during 2 seconds before RAPID

! executeion continues to the next instruction

EGMRunPose egmID1, EGM_STOP_HOLD \x \y \z \CondTime:=2

\RampInTime:=0.05; egmSt1:=EGMGetState(egmID1);

IF egmSt1 = EGM_STATE_CONNECTED THEN

TPWrite "Reset EGM instance egmID1";

EGMReset egmID1;

ENDIF

ENDPROC

ENDMODULE




347


9.3.6.2 Using EGM Position Guidance with signals as input

9.3.6.2 Using EGM Position Guidance with signals as input

Description

All signals that are used together with EGM has to be defined in the I/O configuration of the system. I.e. the signals that are set up with

EGMSetupAI

,

EGMSetupAO

, or

EGMSetupGI

. After that, the signals can be used by EGM to guide a robot.

The following RAPID program example uses analog output signals as input. The main reason for analog output signals is, that they are easier to simulate than analog input signals. In a real application group input signals and analog input signals might be more common.

In the example we also set the analog output signals to a constant value before the

EGMRun instruction just for simplicity. Normally an external device will update the signal values to give the desired robot positions.

Example


348

MODULE EGM_test



CONST egm_minmax egm_minmax_lin1:=[-1,1];

CONST egm_minmax egm_minmax_rot1:=[-2,2];

CONST egm_minmax egm_minmax_joint1:=[-0.1,0.1];

CONST robtarget p20:=[[150,1320,1140],

[0.000494947,0.662278,-0.749217,-0.00783173], [0,0,-1,0],

[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

CONST robtarget p30:=[[114.50,1005.42,1410.38],

[0.322151,-0.601023,0.672381,0.287914], [0,0,-1,0],

[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

CONST jointtarget jpos10:=[[0,0,0,0,35,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

CONST pose posecor:=[[1200,400,900],[1,0,0,0]];

CONST pose posesens:=[[12.3313,-0.108707,416.142],

[0.903899,-0.00320735,0.427666,0.00765917]];

! corr-frame: world, sens-frame: world

VAR pose posecor0:=[[0,0,0],[1,0,0,0]];

VAR pose posesen0:=[[0,0,0],[1,0,0,0]];

TASK PERS tooldata tFroniusCMT:=[TRUE,[[12.3313,-0.108707,416.142],

[0.903899,-0.00320735,0.427666,0.00765917]],

[2.6,[-111.1,24.6,386.6],[1,0,0,0],0,0,0.072]];

TASK PERS loaddata load1:=[5,[0,1,0],[1,0,0,0],0,0,0];

! corr-frame: wobj, sens-frame: wobj

TASK PERS wobjdata wobj_EGM1:=[FALSE,TRUE,"",[[150,1320,1140],[1,0,0,0]],

[[0,0,0],[1,0,0,0]]];

VAR pose posecor1:=[[0,0,0],[1,0,0,0]];

VAR pose posesen1:=[[0,0,0],[1,0,0,0]];






Continued

TASK PERS wobjdata wobj_EGM2:=[FALSE,TRUE,"",[[0,1000,1000],[1,0,0,0]],

[[0,0,0],[1,0,0,0]]];

VAR pose posecor2:=[[150,320,0],[1,0,0,0]];

VAR pose posesen2:=[[150,320,0],[1,0,0,0]];

PROC main()

MoveAbsJ jpos10\NoEOffs, v1000, fine, tFroniusCMT; testAO;

ENDPROC

PROC testAO()

! Get two different EGM identities. They will be used for two different eGM setups.

EGMGetId egmID1;

EGMGetId egmID2;

! Set up the EGM data source: Analog output signals and configuration "default"

! One guidance using Pose mode and one using Joint mode

EGMSetupAO ROB_1,egmID1,"default" \Pose \aoR1x:=ao_MoveX

\aoR2y:=ao_MoveY \aoR3z:=ao_MoveZ \aoR5ry:=ao_RotY

\aoR6rz:=ao_RotZ;

EGMSetupAO ROB_1,egmID2,"default" \Joint \aoR1x:=ao_MoveX

\aoR2y:=ao_MoveY \aoR3z:=ao_MoveZ \aoR4rx:=ao_RotX

\aoR5ry:=ao_RotY \aoR6rz:=ao_RotZ;

! Move to the starting point - fine point is needed.


! Set the signals

SetAO ao_MoveX, 150;

SetAO ao_MoveY, 1320;

SetAO ao_MoveZ, 900;

! Correction frame is the World coordinate system and the sensor measurements are also relative to the world frame

! No offset is defined (posecor0 and posesen0)

EGMActPose egmID1 \Tool:=tFroniusCMT \WObj:=wobj0 \TLoad:=load1, posecor0, EGM_FRAME_WORLD, posesen0, EGM_FRAME_WORLD



\LpFilter:=20 \SampleRate:=16 \MaxPosDeviation:=1000;

! Run: keep the end position without returning to the start position

EGMRunPose egmID1,

EGM_STOP_HOLD\x\y\z\RampInTime:=0.05\PosCorrGain:=1;


MoveJ p20, v1000, fine, tFroniusCMT;

! Set the signals










Continued

! Run with the same frame definitions: ramp down to the start position after having reached

! the EGM end position

EGMRunPose egmID1,

EGM_STOP_RAMP_DOWN\x\y\z\RampInTime:=0.05\PosCorrGain:=1;



! Set the signals

SetAO ao_MoveX, 50;

SetAO ao_MoveY, -20;

SetAO ao_MoveZ, -20;

! Correction frame is the Work object wobj_EGM1 and the sensor measurements are also

! relative to the same work object. No offset is defined (posecor1 and posesen1)

EGMActPose egmID1 \Tool:=tFroniusCMT \WObj:=wobj_EGM1 \TLoad:=load1, posecor1, EGM_FRAME_WOBJ, posesen1, EGM_FRAME_WOBJ



\LpFilter:=20;


EGMRunPose egmID1,




! Set the signals

SetAO ao_MoveX, 0;

SetAO ao_MoveY, 0;

SetAO ao_MoveZ, 0;

! Correction frame is the Work object wobj_EGM2 and the sensor measurements are also

! relative to the same work object. This time an offset is defined for the correction frame

! (posecor2), and for the sensor frame (posesen2)

EGMActPose egmID1 \Tool:=tFroniusCMT \WObj:=wobj_EGM2 \TLoad:=load1, posecor2, EGM_FRAME_WOBJ, posesen2, EGM_FRAME_WOBJ



\LpFilter:=20;


EGMRunPose egmID1,




! Set the signals

SetAO ao_MoveX, 0;

SetAO ao_MoveY, 0;

SetAO ao_MoveZ, 0;







Continued

! Correction frame is of tool type and the sensor measurements are relative to the work

! object wobj_EGM2. This time an offset is defined for the correction frame (posecor2), and

! for the sensor frame (posesen2)

EGMActPose egmID1 \Tool:=tFroniusCMT \WObj:=wobj_EGM2, posecor2,

EGM_FRAME_TOOL, posesen2, EGM_FRAME_WOBJ \x:=egm_minmax_lin1

\y:=egm_minmax_lin1 \z:=egm_minmax_lin1 \rx:=egm_minmax_rot1

\ry:=egm_minmax_rot1 \rz:=egm_minmax_rot1 \LpFilter:=20;

EGMRunPose egmID1,



MoveJ p20, v1000, fine, tFroniusCMT\TLoad:=load1;

! Set the signals




! Same as last, but with tool0 and wobj0

EGMActPose egmID1, posecor2, EGM_FRAME_TOOL, posesen2,

EGM_FRAME_WOBJ \x:=egm_minmax_lin1 \y:=egm_minmax_lin1

\z:=egm_minmax_lin1 \rx:=egm_minmax_rot1 \ry:=egm_minmax_rot1

\rz:=egm_minmax_rot1 \LpFilter:=20;


EGMRunPose egmID1,



MoveJ p20, v1000, fine, tFroniusCMT\TLoad:=load1;

! Set the signals

SetAO ao_MoveX, 70;

SetAO ao_MoveY, -5;

SetAO ao_MoveZ, 0;

SetAO ao_RotX, 0;

SetAO ao_RotY, 0;

SetAO ao_RotZ, 0;

! Joint guidance for joints 2-6

EGMActJoint egmID2 \J2:=egm_minmax_joint1 \J3:=egm_minmax_joint1

\J4:=egm_minmax_joint1 \J5:=egm_minmax_joint1

\J6:=egm_minmax_joint1 \LpFilter:=20;


EGMRunJoint egmID2, EGM_STOP_HOLD \J2 \J3 \J4 \J5 \J6 \CondTime:=0.1

\RampInTime:=0.05 \PosCorrGain:=1;

EGMReset egmID1;

EGMReset egmID2;

ENDPROC

ENDMODULE




351


9.3.6.3 Using EGM Path Correction with different protocol types

9.3.6.3 Using EGM Path Correction with different protocol types

Description

This example contains examples for different sensor and protocol types. The basic

RAPID program structure is the same for all of them and they use the same external motion data configuration.

Example

MODULE EGM_PATHCORR

! Used tool

PERS tooldata tEGM:=[TRUE,[[148.62,0.25,326.31],

[0.833900724,0,0.551914471,0]], [1,[0,0,100],

[1,0,0,0],0,0,0]];

! Sensor tool, has to be calibrated

PERS tooldata tLaser:=[TRUE,[[148.619609537,50.250017146,326.310337954],

[0.390261856,-0.58965743,-0.58965629,0.390263064]],

[1,[-0.920483747,-0.000000536,-0.390780849],

[1,0,0,0],0,0,0]];

! Displacement used

VAR pose PP:=[[0,-3,2],[1,0,0,0]];

VAR egmident egmId1;

! Protocol: LTAPP

! Example for a look ahead sensor, e.g. Laser Tracker

PROC Part_2_EGM_OT_Pth_1()

EGMGetId egmId1;

! Set up the EGM data source: LTAPP server using device "Optsim",

! configuration "pathCorr", joint type 1 and look ahead sensor.

EGMSetupLTAPP ROB_1, egmId1, "pathCorr", "OptSim", 1\LATR;

! Activate EGM and define the sensor frame.

! Correction frame is always the path frame.

EGMActMove egmId1, tLaser.tframe\SampleRate:=50;

! Move to a suitable approach position.

MoveJ p100,v1000,z10,tEGM\WObj:=wobj0;

MoveL p110,v1000,z100,tEGM\WObj:=wobj0;


! Activate displacement (not necessary but possible)

PDispSet PP;

! Move to the start point. Fine point is demanded.

MoveL p130, v10, fine, tEGM\WObj:=wobj0;

! movements with path corrections.

EGMMoveL egmId1, p140, v10, z5, tEGM\WObj:=wobj0;


EGMMoveC egmId1, p160, p165, v10, z5, tEGM\WObj:=wobj0;

! Last path correction movement has to end with a fine point.

EGMMoveL egmId1, p170, v10, fine, tEGM\WObj:=wobj0;

! Move to a safe position after path correction.


! Release the EGM identity for reuse.







Continued

EGMReset egmId1;

ENDPROC

! Protocol: LTAPP

! Example for an at point sensor, e.g. Weldguide

PROC Part_2_EGM_WG_Pth_1()

EGMGetId egmId1;

! Set up the EGM data source: LTAPP server using device "wg1sim",

! configuration "pathCorr", joint type 1 and at point sensor.

EGMSetupLTAPP ROB_1, egmId1, "pathCorr", "wg1sim", 1\APTR;

! Activate EGM and define the sensor frame,

! which is the tool frame for at point trackers.

! Correction frame is always the path frame.

EGMActMove egmId1, tEGM.tframe\SampleRate:=50;




MoveL p120,v1000,fine,tEGM\WObj:=wobj0;


PDispSet PP;












EGMReset egmId1;

ENDPROC

! Protocol: UdpUc

! Example for an at point sensor, e.g. Weldguide

PROC Part_2_EGM_UDPUC_Pth_1()

EGMGetId egmId1;

EGMSetupUC ROB_1, egmId1, "pathCorr", "UCdevice"\PathCorr\APTR;

EGMActMove egmId1, tEGM.tframe\SampleRate:=50;




MoveL p120,v1000,fine,tEGM\WObj:=wobj0;


PDispSet PP;












Continued







EGMReset egmId1;

ENDPROC

ENDMODULE





9.3.7 UdpUc code examples

9.3.7 UdpUc code examples

File locations

The following code examples are available in the RobotWare distribution.

File

egm-sensor.cs

egm-sensor.cpp

egm.proto

Description

Example using protobuf-csharp-port

Example using Google protocol buffers C++

The egm.proto file defines the data contract between the robot and the sensor.

The files can be obtained from the PC or the IRC5 controller.

• In the RobotWare installation folder in RobotStudio: ...\RobotPackages\

RobotWare_RPK_<version>\utility\Template\EGM\

• On the IRC5 Controller:

<SystemName>\PRODUCTS\<RobotWare_xx.xx.xxxx>\utility\Template\EGM\

Note

Navigate to the RobotWare installation folder from the RobotStudio Add-Ins tab, by right-clicking on the installed RobotWare version in the Add-Ins browser and selecting Open Package Folder.




355


9.4.1 Introduction to Robot Reference Interface

9.4 Robot Reference Interface [included in 689-1]

9.4.1 Introduction to Robot Reference Interface

Introduction

Robot Reference Interface is included in the RobotWare option Externally Guided

Motion.

Robot Reference Interface supports data exchange on the cyclic channel. It provides the possibility to periodically send planned and actual robot position data from the robot controller, as well as the exchange of other RAPID variables from and to the robot controller. The message contents are represented in XML format and are configured using appropriate sensor configuration files.

Robot Reference Interface

The cyclic communication channel (TCP or UDP) can be executed in the high-priority network environment of the IRC5 Controller which ensures a stable data exchange up to 250Hz.

Robot

Rapid data

RRI

Cyclic channel (TCP or UDP) read/write

Sensor

Cabinet status

read only

Receive commands, parameters and robot data

Return parameters and sensor data read only

Motion data

xx0800000128





9.4.2.1 Connecting the communication cable

9.4.2 Installation

9.4.2.1 Connecting the communication cable

Overview

This section describes where to connect the communication cable on the controller.

For further instructions, see the corresponding product manual for your robot system.

Location

A

B xx1300000609

A

B

1

Service port on the computer unit (connected to the service port on the controller)

WAN port on the computer unit

Action

Use one of these two connections (A or B).

Note

Note

The service connection can only be used if it is free.




357


9.4.2.2 Prerequisites

9.4.2.2 Prerequisites

Overview

This section describes the prerequisites for using Robot Reference Interface.

UDP/IP or TCP IP

Robot Reference Interface supports the communication over the standard IP protocols UDP or TCP.

Recommendations

The delay in the overall communication mostly depends on the topology of the employed network. In a switched network the transmission will be delayed due to buffering of the messages in the switches. In a parallel network collisions with multiple communication partners will lead to messages being resent.

Therefore we recommended using a dedicated Ethernet link between the external system and the robot controller to provide the required performance for real-time applications. Robot Reference Interface can be used to communicate with any processor-based devices, that support IP via Ethernet and can serialize data into

XML format.





9.4.2.3 Data orchestration

9.4.2.3 Data orchestration

Overview

The outgoing message can be combined from any data from the RAPID level and internal data from the cabinet and motion topic. The orchestration of the data is defined in the device configuration by setting the Link attribute of internally linked data to Intern.

Illustration

xx0800000178

Data from the Controller topic

Name Type

OperationMode OpMode

Description Comment

Operation mode of the robot.

The mapping of the members for the Op-

Mode type can be defined in the configuration file.

Data from the Motion topic

Name

FeedbackTime

Type

Time

FeedbackPose Frame

FeedbackJoints Joints

PredictedTime Time

PlannedPose Frame

PlannedJoints Joints

Description Comment

Time stamp for the robot position from drive feedback.

There is a delay of approximately 8ms.

Robot TCP calculated from drive feedback.

Current tool and workobject are used for calculation.

Robot joint values gathered from drive feedback.

Timestamp for planned robot

TCP position and joint values.

Prediction time from approximately 24ms to 60ms depending on robot type.

Planned robot TCP.

Current tool and workobject are used for calculation.

Planned robot joint values.




359


9.4.2.4 Supported data types

9.4.2.4 Supported data types

Overview

This section contains a short description of the Robot Reference Interface supported data types, for more detailed information about the supported data types see

References on page 13 .

Data types

Robot Reference Interface supports the following simple data types:

Data type

bool real time string frame joint

Description

Boolean value.

RAPID type mapping

bool

Single precision, floating point value.

String with max length of 80 characters.

num

Time in seconds expressed as floating point value.

num string

Cartesian position and orientation in Euler Angles

(Roll-Pitch-Jaw).

pose

Robot joint values.

robjoint

In addition, user-defined records can also be transferred from the external system to the robot controller, which are composed from the supported simple data types.

User defined record types must be specified in the configuration file of the external device. See

Device configuration on page 366

for a description on how to create user-defined record types.





9.4.3.1 Interface configuration


9.4.3.1 Interface configuration

Configuration files

The configuration and settings files for the interface must be located in the folder

HOME/GSI. This ensures that the configuration files are included in system backups.

xx0800000177


For more detailed information of the Settings.xml file see

Interface settings on page 362

.

For more detailed information of the Description.xml file see

Device description on page 363 .

For more detailed information of the Configuration.xml file see

Device configuration on page 366 .




361


9.4.3.2 Interface settings

9.4.3.2 Interface settings

Overview

This section describes the use of the xml file Settings.xml.

Settings.xml

The settings file Settings.xml contains the general settings for the GSI interface.

It is located in the folder HOME/GSI. For the option Robot Reference Interface this file refers to a list of all communication clients for external systems installed in the controller. The Settings.xml file can be defined according to the XML schema

Settings.xsd.

Example

For each communication client installed on the controller, the file Settings.xml must contain a Client entry in the Clients section. The Convention attribute identifies the protocol convention used by the client, for the Robot Reference Interface option only CDP is supported. The Name attribute identifies the name of the client and also specifies the folder with the device related configuration files.

<?xml version="1.0" encoding="UTF-8"?>

<Settings>

<Clients>

<Client Convention="CDP" Name="MySensor" />

</Clients>

</Settings>

CDP stands for cyclic data protocol and is the internal name of the protocol, on which Robot Reference Interface messages are transferred.

An internal client node of the interface module will be created, which is able to connect to the external system MySensor that runs a data server application and can communicate via Robot Reference Interface with the robot.

For each sensor system, a subdirectory named with the sensor system identifier, for example MySensor, contains further settings.





9.4.3.3 Device description

9.4.3.3 Device description

Overview

This section describes the use of the xml file Description.xml.

Description.xml

The device description file Description.xml is located in the corresponding subdirectory of the device. It specifies the general device parameters, network connection and CDP specific communication settings for an installed device. A device description can be defined according to the XML schema Description.xsd.

Example

This is an example of a device description:

<?xml version="1.0" encoding="utf-8"?>

<Description>

<Name>AnyDevice</Name>

<Convention>CDP</Convention>

<Type>IntelligentCamera</Type>

<Class>MachineVision</Class>

<Network Address="10.49.65.74" Port="Service">

<Channel Type="Cyclic" Protocol="Udp" Port="3002" />

</Network>

<Settings>

<TimeOut>2000</TimeOut>

<MaxLost>30</MaxLost>

<DryRun>false</DryRun>

</Settings>

</Description>

Name

The first section defines the general device parameters. The Name element identifies the name of the device and should correspond to the device name specified in the settings file. It must correspond to the identifier specified for the device descriptor on the RAPID level, because the descriptor name will be used initially to refer to the device in the RAPID instructions.

Element

Name

Attribute Description

Device identifier

Value

Any string

Comment

Maximum 16 characters

Convention

The Convention element identifies the protocol that should be used by the device, for the Robot Reference Interface option only the Cyclic Data Protocol (CDP) is supported.

Element

Convention

Attribute Description

Protocol type

Value

CDP

Comment





363



Continued

Type and Class

Network

Channel

The Type and Class elements identifies the device type and class and are currently not validated, therefore they can also contain undefined device types or classes.

Attribute Element

Type

Class

Description

Sensor type

Sensor class

Value

Any string

Any string

Comment

Not validated

Not validated

The Network section defines the network connection settings for the device. The

Address attribute specifies the IP address or host name of the device on the network. The optional Port attribute is used to specify the physical Ethernet port on the controller side that the cable is plugged into. Valid values are WAN and

Service. The attribute can be omitted if the WAN port is used for communication.

Element

Network

Attribute

Address

Port

Description

Network settings

Value Comment

IP address or host name of the device

Any valid IP address or host name

10.49.65.249

DE-L-0328122

Physical Ethernet port on the controller

WAN

Service

Optional. Can be omitted if WAN port is used.

The Channel element defines the settings for the communication channel between the robot controller and the external device. The Type attribute identifies the channel type, only Cyclic is supported by Robot Reference Interface.

The Protocol attribute identifies the IP protocol used on the channel, for Robot

Reference Interface you can specify to use Tcp or Udp. The Port attribute specifies the logical port number for the channel on the device side.

Element

Channel

Attribute Comment

Type

Protocol

Port

Description

Channel settings

Channel type

The IP protocol type

Value

Cyclic

Tcp

Udp

The logical port number of the channel uShort Any available port number on the device, maximum 65535.





Settings



Continued

The Settings section contains communication parameters specific to the CDP protocol. The TimeOut element defines the timeout for not received messages.

This element identifies the time until the connection is considered broken and is only needed for bidirectional communication. The MaxLost attribute defines the maximum number of not acknowledged or lost messages allowed. The DryRun element identifies, if the acknowledgement of messages is supervised and can be used to setup an unidirectional communication.

Element

TimeOut

MaxLost

Description

Time out for communication

Maximum loss of packages allowed

Interface run mode

Value

Integer

Bool

Comment

Time in milliseconds, a multiple of 4 ms.

DryRun If TRUE, TimeOut and MaxLost will not be checked.

If the element DryRun in the Description.xml is set to FALSE, communication supervision is established on the protocol level of the Robot Reference Interface, using the settings for TimeOut and MaxLost. This supervision requires that each message that is sent out from the robot controller is answered by the connected device. The supervision generates a communication error, if the maximum response time or the maximum number of lost packages is exceeded. Each sent out message has an ID, which needs to be used for the ID in the reply too, to identify the reply message and to detect which packages have been lost. See also the example in section

Transmitted XML messages on page 373

.




365


9.4.3.4 Device configuration

9.4.3.4 Device configuration

Overview

The device configuration file Configuration.xml is located in the corresponding subdirectory of the device. It defines the enumerated and complex types used by the device and identifies the available parameters, which can be subscribed for cyclic transmission. The configuration file can be defined according to the XML schema Configuration.xsd. The following document shows a simplified device configuration.

Example


<Configuration>

<Enums>

<Enum Name="opmode" Link="Intern">

<Member Name="ReducedSpeed" Alias="Alias"/>

</Enum>

</Enums>

<Records>

<Record Name="senddata">

<Field Name="PlannedPose" Type="Pose" Link="Intern" />

</Record>

</Records>

<Properties>

<Property Name="DataToSend" Type="senddata" Flag="WriteOnly"

/>

</Properties>

</Configuration>

Enums

In the Enums section each Enum element defines an enumerated type. The Name attribute of the Enum element specifies the name of the enumerated type, the optional Link attribute identifies if the members of the enumerated type have internal linkage.

Element

Enum

Attribute

Name

Link

Descriptions Value

Name of enumerated type

A valid RAPID symbol name

Linkage of members of enumerated type

Intern

Comment

Maximum 16 characters.

Optional. Can be omitted if members only have RAPID linkage.







Continued

Member

Record

Field

Each Member element defines a member element of the enumerated type. The

Name attribute specifies the name of the member on the controller side (on RAPID level). The Alias attribute identifies the name of the member on the device side

(and in the transmitted message).

Element

Member

Attribute

Name

Alias


Name of enumerated type member


Alias name of enumerated type member

String

Comment

Maximum 16 characters.Valid

internal RAPID symbol names. See

Data orchestration on page 359

.

Optional. The alias name is used on the device side and in message

In the Records section each Record element defines a declaration of a complex type. In RAPID this complex type will be represented as a RECORD declaration.

The Name attribute identifies the name of the complex type on the controller side.

The Alias attribute defines the alias name of the type on the device side and in the message.

Element

Record

Attribute

Name

Alias


Name of the complex type.


Alias name of complex type.

String

Comment


Optional. The alias name is used on the device side and in message.

Each Field element defines a field element of a complex type. The Name attribute identifies the name of the field. The Type attribute identifies the enumerated, complex or simple type associated with the field. The Size attribute defines the size of a multi-dimensional field. The Link attribute identifies if the field has internal linkage.

Element

Field

Attribute

Name

Type

Size

Link

Alias


Name of the complex type field


Data type of the field

Dimensions of the field (size of array)

Linkage of complex type field

Alias name of complex type field

All supported data types

Integer

Intern

String

Comment

Maximum 16 characters.Valid

internal RAPID symbol names. See

Data orchestration on page 359

.

Described in section

Supported data types on page 360 .

Optional. Only basic types can be defined as array.

Optional. Can be omitted if field has RAPID linkage.

Optional. The alias name is used on device side and in message.







Continued

Properties

In the Properties section each Property element defines a RAPID variable that can be used in the

SiGetCyclic and

SiSetCyclic instructions.

Element

Property

Attribute

Name

Type

Size

Flag

Link

Alias

Descriptions

Name of the property

Data type of the property

Dimension (Size of array)

Access Flag

Value Comment

An valid RAPID symbol name


All supported data types

Described in section

Supported data types on page 360 .

Integer

None

ReadOnly

WriteOnly

ReadWrite

Linkage of property

Intern

Alias name of the property

String

Optional. Only basic types can be defined as array.

Optional. Can be omitted if property is read and write enabled.

Mandatory if field has RAPID linkage.

Optional. The alias name is used on device side and in message.





9.4.4.1 RAPID programming

9.4.4 Configuration examples

9.4.4.1 RAPID programming

RAPID module

A RAPID module containing the corresponding RAPID record declarations and variable declarations must be created and loaded.

The FlexPendant user interface is not included in RobotWare.




369


9.4.4.2 Example configuration

9.4.4.2 Example configuration

Overview

The files Settings.xml, Description.xml, and Configuration.xml are located in the folder HOME\GSI\ xx0800000177

Note

The name of the folder must correspond to the name of the device. See

Device description on page 363 . In this example we have used the name AnyDevice.

The network address used in Description.xml is to the PC running the server, not the robot controller. See

Device description on page 363

.

Settings.xml


<Settings>

<Servers>

<Servers/>

<Clients>

<Client Convention="CDP" Name="AnyDevice" />

</Clients>

</Settings

Description.xml


370


<Description>

<Name>AnyDevice</Name>

<Convention>CDP</Convention>

<Type>IntelligentCamera</Type>

<Class>MachineVision</Class>

<Network Address="10.49.65.74" Port="Service">

<Channel Type="Cyclic" Protocol="Udp" Port="3002" />

</Network>

<Settings>

<TimeOut>2000</TimeOut>




Configuration.xml



Continued

<MaxLost>30</MaxLost>

<DryRun>false</DryRun>

</Settings>

</Description>

<?xml version="1.0" encoding="utf-8" ?>

<Configuration>

<Enums>

<Enum Name="OperationMode" Link="Intern">

<Member Name="Automatic" Alias="Auto" />

<Member Name="ReducedSpeed" Alias="ManRS" />

<Member Name="FullSpeed" Alias="ManFS" />

</Enum>

</Enums>

<Records>

<Record Name="RobotData">

<Field Name="OperationMode" Type="OperationMode" Link="Intern"

Alias="RobMode" />

<Field Name="FeedbackTime" Type="Time" Link="Intern"

Alias="Ts_act" />

<Field Name="FeedbackPose" Type="Frame" Link="Intern"

Alias="P_act" />

<Field Name="FeedbackJoints" Type="Joints" Link="Intern"

Alias="J_act" />

<Field Name="PredictedTime" Type="Time" Link="Intern"

Alias="Ts_des" />

<Field Name="PlannedPose" Type="Frame" Link="Intern"

Alias="P_des" />

<Field Name="PlannedJoints" Type="Joints" Link="Intern"

Alias="J_des" />

<Field Name="ApplicationData" Type="Num" Size="18"

Alias="AppData" />

</Record>

<Record Name="SensorData">

<Field Name="ErrorString" Type="String" Alias="EStr" />

<Field Name="ApplicationData" Type="Num" Size="18"

Alias="AppData" />

</Record>

</Records>

<Properties>

<Property Name="RobData" Type="RobotData" Flag="WriteOnly"/>

<Property Name="SensData" Type="SensorData" Flag="ReadOnly"/>

</Properties>

</Configuration>





371



Continued

RAPID configuration

This is an example for an RRI implementation. The out data uses an array of 18 num (robdata). The in data receives a string and an array of 18 num (sensdata).

This needs to defined according the file configuration.xml.

RECORD applicationdata num Item1; num Item2; num Item3; num Item4; num Item5; num Item6; num Item7; num Item8; num Item9; num Item10; num Item11; num Item12; num Item13; num Item14; num Item15; num Item16; num Item17; num Item18;

ENDRECORD

RECORD robdata applicationdata AppData;

ENDRECORD

RECORD sensdata string ErrString;applicationdata AppData;

ENDRECORD

! Sensor Declarations

PERS sensor AnyDevice := [1,4,0];

PERS robdata DataOut := [[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]];

PERS sensdata DataIn :=

["No",[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]];

! Setup Interface Procedure

PROC RRI_Open()

SiConnect AnyDevice;

! Send and receive data cyclic with 64 ms rate

SiGetCyclic AnyDevice, DataIn, 64;

SiSetCyclic AnyDevice, DataOut, 64;

ENDPROC

! Close Interface Procedure

PROC RRI_Close()

! Close the connection

SiClose RsMaster;

ENDPROC

ENDMODULE







Continued

Transmitted XML messages

Each XML message has the data variable name as root element with the attributes

Id

(the message ID) and

Ts

(the time stamp of the message). The subelements are then the record fields. The values of a multiple value field (array or record) are expressed as attributes.

Message sent out from robot controller

The time unit is second (float) with a resolution of 1 ms. The position (length) unit is millimeter (float). The position (angle) unit is radians.

Name

Id

Ts

RobMode

TS_act

P_act

J_act

TS_des

P_des

J_des

AppData

Data type

Integer

Float

Operationmode

Float

Pose

Joint

Float

Pose

Joint

Array of 18 Floats

Description

Last received robot data message ID

Time stamp (message)

Operation mode

Time stamp (actual position)

Actual cartesian position

Actual joint position

Time stamp (desired position)

Desired cartesian position

Desired joint position

Free defined application data

<RobData Id="111" Ts="1.202" >

<RobMode>Auto</RobMode>

<Ts_act>1.200</Ts_act>

<P_act X="1620.0" Y="1620.0" Z="1620.0" Rx="100.0" Ry="100.0"

Rz="100.0" />

<J_act J1="1.0" J2="1.0" J3="1.0" J4="1.0" J5="1.0" J6="1.0" />

<Ts_des>1.200</Ts_des>

<P_des X="1620.0" Y="1620.0" Z="1620.0" Rx="100.0" Ry="100.0"

Rz="100.0" />

<J_des J1="1.0" J2="1.0" J3="1.0" J4="1.0" J5="1.0" J6="1.0" />

<AppData X1="1" X2="1620.000" X3="1620.000" X4="1620.000"

X5="1620.000" X6="1620.000" X7="1620.000" X8="1620.000"

X9="1620.000" X10="1620.000" X11="1620.000" X12="1620.000"

X13="1620.000" X14="1620.000" X15="1620.000" X16="1620.000"

X17="1620.000" X18="1620.000" />

</RobData>

Message received from robot controller

The time unit is seconds (float).

Name

Id

Data type

Integer

Ts

EStr

Float

String

Description

Last received data message ID. This ID must correspond to the ID sent from the robot controller.

Time stamp

Error message







Continued

Name

AppData

Data type

Array of 18 floats

Description

Free defined application data

The corresponding XML message on the network would look like this:

<SensData Id="111" Ts="1.234">

<EStr>xxxx</Estr>

<AppData X1="232.661" X2="1620.293" X3="463.932"

X4="1231.053" X5="735.874" X6="948.263" X7="2103.584"

X8="574.228" X9="65.406" X10="2372.633" X11="20.475"

X12="96.729" X13="884.382" X14="927.954" X15="748.294"

X16="3285.574" X17="583.293" X18="684.338" />

</SensData>








This is an overview of all instructions, functions, and data types in Robot Reference

Interface.



Instructions

Instructions

SiConnect

SiClose

SiGetCyclic

SiSetCyclic

Description

Sensor Interface Connect

Sensor Interface Close

Sensor Interface Get Cyclic

Sensor Interface Set Cyclic

Functions

Robot Reference Interface includes no functions.

Data types

Data types

sensor sensorstate

Description

External device descriptor

Communication state of the device




375


10 Tool control options

10.1.1 Overview


10.1 Servo Tool Change [630-1]

10.1.1 Overview

Purpose

The purpose of Servo Tool Change is to be able to change tools on-line.

With the option Servo Tool Change it is possible to disconnect the cables to the motor of an additional axis and connect them to the motor of another additional axis. This can be done on the run, in production.

This option is designed with servo tools in mind, but can be used for any type of additional axes.

Examples of advantages are:

• One robot can handle several tools.

• Less equipment is needed since one drive-measurement system is shared by several tools.


The RobotWare option Servo Tool Change enables you to:

• change tool on-line

• have up to 8 different servo tools to change between.

Note that the option Servo Tool Change only provides the software functionality.

Hardware, such as a tool changer is not included.

Basic approach

This is the general approach for using Servo Tool Change. For a more detailed description of how this is done, see

Tool change procedure on page 383

.

1 Deactivate the first tool.

2 Disconnect the first tool from the cables.

3 Connect the second tool to the cables.

4 Activate the second tool.




377


10.1.2 Requirements and limitations

10.1.2 Requirements and limitations

Additional Axes

To use Servo Motor Control, you must have the option Additional Axes. All additional axes used by servo motor control must be configured according to the instructions in

Requirements and limitations on page 378 .

Tool changer

To be able to change tools in production with a plug-in mechanism, a mechanical tool changer interface is required.

en0300000549

All cables are connected to the tool changer. The tool changer interface includes connections for signals, power, air, water or whatever needs to be transmitted to and from the tool.

Up to 8 tools

Up to 8 additional axes (servo tools or other axes) can be installed simultaneously in one robot controller. Some of them (or all) may be servo tools sharing a tool changer.

Moving deactivated tool

The controller remembers the position of a deactivated tool. When the tool is reconnected and activated this position is used.

If the servo tool axis is moved during deactivation, the position of the axis might be wrong after activation, and this will not be detected by the controller.






10.1.2 Requirements and limitations

Continued

The position after activation will be correct if the axis has not been moved, or if the movement is less than 0.5 motor revolutions.

Tip

If you have the Spot Servo option you can use tool change calibration.

After a tool is activated, call the instruction

STCalib to calibrate the tool. This will adjust any positional error caused by tool movements during deactivation.

Activating wrong tool

It is important not to activate a mechanical unit that is not connected.

An activation of the wrong mechanical unit may cause unexpected movements or errors. The same errors occur if a tool is activated when no tool at all is connected.

Tip

A connection relay can be configured so that activation of a mechanical unit is only allowed when it is connected. See

Connection relay on page 381 .




379


10.1.3 Configuration


Configuration overview

The option Servo Tool Change allows configuration of several tools for the same additional axis.

One individual set of parameters is installed for each gun tool.

How to configure each tool

Each tool is configured the same way as if it was the only tool. For information on how to do this, see

Configuration on page 380 .

The parameter Deactivate PTC superv. at disconnect, in the type Mechanical Unit, must be set to Yes.

The parameter Disconnect deactivate, in the type Measurement Channel, must be set to Yes.

The parameter Logical Axis, in the type Joint, can be set to the same number for several tools. Since the tools are never used at the same time, the tools are allowed to use the same logical axis.

The parameter allow_activation_from_any_motion_task, in the type Mechanical

Unit, must be set for the specific servo gun. The servo gun .cfg files are created by the servo gun manufacture.

For a detailed description of the respective parameter, see


.





10.1.4 Connection relay

10.1.4 Connection relay

Overview

To make sure a disconnected mechanical unit is not activated, a connection relay can be used. A connection relay can prevent a mechanical unit from being activated unless a specified digital signal is set.

Some tool changers support I/O signals that specify which gun is currently connected. Then a digital input signal from the tool changer is used by the connection relay.

If the tool changer does not support I/O signals, a similar behavior can be created with RAPID instructions. Set a digital output signal to 1 with the instruction

SetDO each time the tool is connected, and set the signal to 0 when the tool is disconnected.


This is a brief description of each parameter used to configure a connection relay.

For more information, see the respective parameter in

Connection relay on page 381

The following parameters have to be set for the type Mechanical Unit in the topic

Motion:


Use Connection

Relay

The name of the relay to use.

Corresponds to the name specified in the parameter Name in the type

Relay.

The following parameters must be set for the type Relay in the topic Motion:

Parameter

Name

Input Signal

Description

Name of the relay.

Used by the parameter Use Connection Relay in the type Mechanical Unit.

The name of the digital signal used to indicate if it should be possible to activate the mechanical unit.

Example of connection relay configuration

This is an example of how to configure connection relays for two gun tools. gun1 can only be activated when signal di1 is 1, and gun2 can only be activated when di2 is 1.

If the tool changer sets di1 to 1 only when gun1 is connected, and di2 to 1 only when gun2 is connected, there is no risk of activating the wrong gun.

The following parameter values are set for gun1 and gun2 in the typeMechanical

Unit:

Name

gun1 gun2

Use Connection Relay

gun1_relay gun2_relay






10.1.4 Connection relay

Continued

The following parameter values are set for gun1 and gun2 in the typeRelay:

Name

gun1_relay gun2_relay

Input Signal

di1 di2





10.1.5 Tool change procedure

10.1.5 Tool change procedure

How to change tool

2

3

4

5

Step

1

This is a description of how to change from gun1 to gun2.

Action

Deactivate gun1 with the instruction:

DeactUnit gun1;

Disconnect gun1 from the tool changer.

Connect gun2 to the tool changer.

Activate gun2 with the instruction:

ActUnit gun2;

Optional but recommended:

Calibrate gun2 with the instruction:

STCalib gun1 \ToolChg;

Note that this calibration requires option Servo Tool Control or Spot Servo .




383


10.1.6 Jogging servo tools with activation disabled

10.1.6 Jogging servo tools with activation disabled

Overview

Only one of the servo tools used by the tool changer may be activated at a time, the others are set to activation disabled. This is to make sure that the user is jogging the servo tool presently connected with right configuration.

What to do when Activation disabled appears

Follow these steps when you need to jog a servo tool but cannot activate the unit because activation is disabled.

2.

3.

Step

1.

Action

Make sure that the right servo tool is mounted on the tool changer. If the wrong tool is mounted, see

Tool change procedure on page 383

.

If no tool is activated, open the RAPID execution and activate the right tool.

If the right tool is mounted on the tool changer, deactivate the wrong tool and activate the right tool from RAPID execution.





10.2.1 Overview

10.2 Tool Control [1180-1]

10.2.1 Overview

Purpose


Tool Control gives you access to:

• RAPID instructions to open, close and calibrate servo tools

• RAPID instructions for tuning system parameter values

• RAPID functions for checking status of servo tools

• system parameters to configure servo tools

Basic approach

Tool Control can be used to control a servo tool, for example in a spot weld application. Tool Control makes it possible to close the tool to a specific plate thickness and force, and maintain the force during the process until the tool is requested to be opened.

This is the general approach for using Tool Control.

1 Configure and calibrate the servo tool.

2 Perform a force calibration.

3 Create the RAPID program.

Prerequisites

A servo tool is an additional axis. The option Additional Axes must be present on the robot system using a servo tool. Required hardware, such as drive module and measurement board, is specified in Application manual - Additional axes and stand alone controller.




385


10.2.2 Servo tool movements

10.2.2 Servo tool movements

Closing and opening of a servo tool

The servo tool can be closed to a predefined thickness and tool force. When the tool reaches the programmed contact position, the movement is stopped and there is an immediate switch from position control mode to force control mode. In the force control mode a motor torque will be applied to achieve the desired tool force.

The force remains constant until an opening is ordered. Opening of the tool will reduce the tool force to zero and move the tool arm back to the pre-close position.

Synchronous and asynchronous movements

Normally a servo tool axis is moved synchronous with the robot movements in such a way that both movements will be completed exactly at the same time.

However the servo tool may be closed asynchronously (independent of current robot movement). The closing will immediately start to run the tool arm to the expected contact position (thickness). The closing movement will interrupt an on-going synchronous movement of the tool arm.

The tool opening may also take place while the robot is moving. But it is not possible if the robot movement includes a synchronized movement of the servo tool axis.

A motion error, "tool opening could not synchronize with robot movement", will occur.





10.2.3 Tip management

10.2.3 Tip management

About tip management

The tip management functionality will find and calibrate the contact position of the tool tips automatically. It will also update and monitor the total tip wear of the tool tips.

The tips can be calibrated by using the RAPID instruction

STCalib

(see

Instructions on page 390 ). Typically, two tool closings will be performed during a calibration.

Three different types of calibrations are supported: tip wear, tip change and tool change. All three will calibrate the contact position of the tips. The total tip wear will, however, be updated differently by these methods.

Tip wear calibration

As the tips are worn down, for example when spot welding, they need to be dressed.

After the tip dressing, a tip wear calibration is required. The tool contact position is calibrated and the total tip wear of the tool is updated. The calibration movements are fast and the switch to force control mode will take place at the zero position.

This method must only be used to make small position adjustments (< 3 mm) caused by tip wear / tip dressing.

Tip

A variable in your RAPID program can keep track of the tip wear and inform you when the tips needs to be replaced.

Tip change calibration

The tip change calibration is to be used after mounting a new pair of tips, for example when spot welding. The tool contact position is calibrated and the total tip wear of the tool is reset. The first calibration movement is slow in order to find the unknown contact position and switch to force control. The second calibration movement is fast. This calibration method will handle big position adjustments of the servo tool.

This calibration may be followed by a tool closing in order to squeeze the tips in place. A new tip change calibration is then done to update possible position differences after the tip squeeze.

Tool change calibration

The tool change calibration is to be used after reconnecting and activating a servo tool. The tool contact position is calibrated and the total tip wear of the tool remains unchanged. The first calibration movement is slow in order to find the unknown tip collision position and switch to force control. The second calibration movement is fast. This calibration method will handle big position adjustments of the tool.

The method should always be used after reconnecting a tool since the activation will restore the latest known position of the tool, and that position may be different from the actual tool position; the tool arm may have been moved when






10.2.3 Tip management

Continued disconnected. This calibration method will handle big position adjustments of the tool.

Tip

Tool change calibration is most commonly used together with the RobotWare option Servo Tool Change.





10.2.4 Supervision

10.2.4 Supervision

Max and min stroke

An out of range supervision will stop the movement if the tool is reaching max stroke or if it is closed to contact with the tips (reaching min stroke). See Upper

Joint Bound and Lower Joint Bound in

Arm on page 393 .

Motion supervision

During the position control phase of the closing/opening, motion supervision is active for the servo tool to detect if the arm collides or gets stuck. A collision will cause a motion error and the motion will be stopped.

During the force control phase, the motion supervision will supervise the tool arm position not to exceed a certain distance from the expected contact position. See parameter Max Force Control Position Error in

Supervision Type on page 394

.

Maximum torque

There is a maximum motor torque for the servo tool that never will be exceeded in order to protect the tool from damage. If the force is programmed out of range according to the tools force-torque table, the output force will be limited to this maximum allowed motor torque and a motion warning will be logged. See parameter

Max Force Control Motor Torque in

SG Process on page 391

.

Speed limit

During the force control phase there is a speed limitation. The speed limitation will give a controlled behavior of the tool even if the force control starts before the tool is completely closed. See Speed limit 1- 6 in

Force Master Control on page 392

.




389





This is an overview of all instructions, functions, and data types in Tool Control.



Instructions

Instruction

STClose

STOpen

STCalib

STTune

STTuneReset

Description

Close the servo tool with a predefined force and thickness.

Open the servo tool.

Calibrate the servo tool.

An argument determines which type of calibration will be performed:

•

\ToolChg for tool change calibration

•

\TipChg for tip change calibration

•

\TipWear for tip wear calibration

Tune motion parameters for the servo tool. A temporary value can be set for a parameter specified in the instruction.

Reset tuned motion parameters for the servo tool. Cancel the effect of all

STTune instructions.

Functions

Function

STIsClosed

STIsOpen

STIsCalib

STCalcTorque

STCalcForce

Description

Test if the servo tool is closed.

Test if the servo tool is open.

Tests if a servo tool is calibrated.

Calculate the motor torque for a servo tool.

Calculate the force for a servo tool.

STIsServoTool

STIsIndGun

Tests if a mechanical unit is a servo tool.

Tests if servo tool is in independent mode.

Data types

Tool Control includes no RAPID data types.








When using a servo tool, a motion parameter file for the tool is normally installed on the controller. A servo tool is a specific variant of an additional axis and the description of how to configure the servo tool is found in Application manual - Additional axes and stand alone controller.

In this section, the parameters used in combination with Tool Control is briefly described. For more information, see the respective parameter in Technical reference manual - System parameters.

SG Process

These parameters belong to the type SG Process in the topic Motion.

SG Process is used to configure the behavior of a servo gun (or other servo tool).

Parameter

Close Time Adjust

Description

Adjustment of the ordered minimum close time of the gun.

Close Position Adjust Adjustment of the ordered position (plate thickness) where force control should start, when closing the gun.

Force Ready Delay Delays the close ready event after achieving the ordered force.

Max Force Control

Motor Torque

Max allowed motor torque for force control. Commanded force will be reduced, if the required motor torque is higher than this value.

Post-synchronization

Time

Anticipation of the open ready event. This can be used to synchronize the gun opening with the next robot movement.

Calibration Mode Defines the number of times the servo gun closes during a tip wear calibration.

Calibration Force Low The minimum tip force used during a tip wear calibration.

Calibration Force High The maximum tip force used during a tip wear calibration.

Calibration Time The time that the servo gun waits in closed position during calibration.

Number of Stored

Forces

Tip Force 1 - 10

Motor Torque 1- 10

Squeeze Position 1 -

10

Soft Stop Timeout

Defines the number of points in the force-torque relation specified in Tip Force 1 - 10 and Motor Torque 1 - 10.

Tip Force 1 defines the tip force that corresponds to the motor torque in Motor Torque 1.

Tip Force 2 corresponds to Motor Torque 2, etc.

Motor Torque 1 defines the motor torque that corresponds to the tip force in Tip Force 1.

Motor Torque 2 corresponds to Tip Force 2, etc.

Defines the joint position at each force level in the force calibration table.

Defines how long the force will be maintained if a soft stop occurs during constant force.





391



Continued

Force Master

These parameters belong to the type Force Master in the topic Motion.

Force Master is used to define how a servo tool, typically a servo gun, behaves during force control. The parameters only affect the servo tool when it is in force control mode.


References Bandwidth The frequency limit for the low pass filter for reference values.

Use ramp time

Ramp when Increase

Force

Determines if the ramping of the tip force should use a constant time or a constant gradient.

Determines how fast force is built up while closing the tool when

Use ramp time is set to No.

Ramp time Determines how fast force is built up while closing the tool when

Use ramp time is set to Yes.

Collision LP Bandwidth Frequency limit for the low pass filter used for tip wear calibration.

Collision Alarm Torque Determines how hard the tool tips will be pressed together during the first gun closing of new tips calibrations and tool change calibrations.

Collision Speed Determines the servo gun speed during the first gun closing of new tips calibrations and tool change calibrations.

Collision Delta Position Defines the distance the servo tool has gone beyond the contact position when the motor torque has reached the value specified in Collision Alarm Torque.

Max pos err. closing

Delay ramp

Ramp to real contact

Determines how close to the ordered plate thickness the tool tips must be before the force control starts.

Delays the starting of torque ramp when force control is started.

Determines if the feedback position should be used instead of reference position when deciding the contact position.

Force Master Control

These parameters belong to the type Force Master Control in the topic Motion.

Force Master Control is used to set the speed limit and speed loop gain as functions of the torque.


No. of speed limits The number of points used to define speed limit and speed loop gain as functions of the torque. Up to 6 points can be defined.

torque 1 - torque 6 The torque levels, corresponding to the ordered tip force, for which the speed limit and speed loop gain values are defined.

Speed Limit 1 - 6

Kv 1 - 6

Speed Limit 1 to Speed Limit 6 are used to define the maximum speed depending on the ordered tip force.

Kv 1 to Kv 6 are used to define the speed loop gain for reducing the speed when the speed limit is exceeded.







Continued

Arm

Acceleration Data

These parameters belong to the type Acceleration Data in the topic Motion.

Acceleration Data is used to specify some acceleration characteristics for axes without any dynamic model.

Parameter

Nominal Acceleration

Description

Worst case motor acceleration.

Nominal Deceleration Worst case motor deceleration.

Acceleration Derivate Ratio Indicates how fast the acceleration can be increased.

Deceleration Derivate Ratio Indicates how fast the deceleration can be increased.

Motor Type

These parameters belong to the type Arm in the topic Motion.

The type Arm defines the characteristics of an arm.


Upper Joint Bound Defines the upper limit of the working area for the joint.

Lower Joint Bound Defines the lower limit of the working area for the joint.

These parameters belong to the type Motor Type in the topic Motion.

Motor Type is used to describe characteristics for a motor.

Parameter

Pole Pairs

Inertia

Stall Torque ke Phase to Phase

Max Current

Phase Resistance

Phase Inductance

Description

Defines the number of pole pairs for the motor.

The inertia of the motor, including the resolver but excluding the brake.

The continuous stall torque, i.e. the torque the motor can produce at no speed and during an infinite time.

Nominal voltage constant. The induced voltage (phase to phase) that corresponds to the speed 1 rad/s.

Max current without irreversible magnetization.

Nominal winding resistance per phase at 20 degrees Celsius.

Nominal winding inductance per phase at zero current.

Motor Calibration

These parameters belong to the type Motor Calibration in the topic Motion.

Motor Calibration is used to calibrate a motor.

Parameter

Commutator Offset

Calibration Offset

Description

Defines the position of the motor (resolver) when the rotor is in the electrical zero position relative to the stator.

Defines the position of the motor (resolver) when it is in the calibration position.







Continued

Stress Duty Cycle

These parameters belong to the type Stress Duty Cycle in the topic Motion.

Stress Duty Cycle is used for protecting axes, gearboxes, etc.

Parameter

Speed Absolute Max

Description

The absolute highest motor speed to be used.

Torque Absolute Max The absolute highest motor torque to be used.

Supervision Type

These parameters belong to the type Supervision Type in the topic Motion.

Supervision Type is used for continuos supervision of position, speed and torque.


Max Force Control

Position Error

When a servo gun is in force control mode it is not allowed to move more than the distance specified in Max Force Control Position Error.

This supervision will protect the tool if, for instance, one tip is lost.

Max Force Control

Speed Limit

Speed error factor during force control.

If the speed limits, defined in the type Force Master Control, multiplied with Max Force Control Speed Limit is exceeded, all movement is stopped.

Transmission

These parameters belong to the type Transmission in the topic Motion.

Transmission is used to define the transmission gear ratio between a motor and its axis.

Parameter

Rotating Move

Transmission Gear Ratio

Description

Defines if the axis is rotating or linear.

Defines the transmission gear ratio between motor and joint.

Lag Control Master 0

These parameters belong to the type Lag Control Master 0 in the topic Motion.

Lag Control Master 0 is used for regulation of axes without any dynamic model.

Parameter

FFW Mode

Kp, Gain Position Loop

Kv, Gain Speed Loop

Ti Integration Time

Speed Loop

Description

Defines if the position regulation should use feed forward of speed and torque values.

Proportional gain in the position regulation loop.

Proportional gain in the speed regulation loop.

Integration time in the speed regulation loop.







Continued

Uncalibrated Control Master 0

These parameters belong to the type Uncalibrated Control Master 0 in the topic

Motion.

Uncalibrated Control Master 0 is used to regulate uncalibrated axes.

Parameter

Kp, Gain Position Loop

Description

Proportional gain in the position regulation loop.

Kv, Gain Speed Loop Proportional gain in the speed regulation loop.

Ti Integration Time Speed Loop Integration time in the speed regulation loop.

Speed Max Uncalibrated The maximum allowed speed for an uncalibrated axis.

Acceleration Max Uncalibrated The maximum allowed acceleration for an uncalibrated axis.

Deceleration Max Uncalibrated The maximum allowed deceleration for an uncalibrated axis.




395


10.2.7 Commissioning and service

10.2.7 Commissioning and service

Commissioning the servo tool

For a new servo tool, follow these steps for installing and commissioning:

4

5

Step

1

2

3

Action

Install the servo tool according to the description in Application manual - Additional axes and stand alone controller.

Load a .cfg file with the servo tool configuration. For detailed description on how to do this, see Operating manual - RobotStudio.

If you do not have any .cfg file for the servo tool, you can load a template file and configure the system parameters with the values of your servo tool. Template files are found in the RobotWare distribution, see

Template file locations on page 396 .

Use the RAPID instruction

STTune and iterate to find the optimal parameter values.

Once found, these optimal values should be written to the system parameters to be permanent.

Fine calibrate the servo tool, see

Fine calibration on page 398 .

Unless force calibration was included in a loaded .cfg file, perform a force calibration.

Template file locations

The template files can be obtained from the PC or the IRC5 controller.

• In the RobotWare installation folder in RobotStudio: ...\RobotPackages\

RobotWare_RPK_<version>\utility\AdditionalAxis\

• On the IRC5 Controller:

<SystemName>\PRODUCTS\<RobotWare_xx.xx.xxxx>\utility\AdditionalAxis\

Note

Navigate to the RobotWare installation folder from the RobotStudio Add-Ins tab, by right-clicking on the installed RobotWare version in the Add-Ins browser and selecting Open Package Folder.

Disconnect/reconnect a servo tool

If the servo tool is deactivated, using the

DeactUnit instruction, it may be disconnected and removed. The tool position at deactivation will be restored when the tool is connected and reactivated. Make a tool change calibration to make sure the tip position is OK.

The whole process of changing a tool can be performed by a RAPID program if you use the RobotWare option Servo Tool Change and the instruction

STCalib

.

Recover from accidental disconnection

If the motor cables are disconnected by accident when the servo tool is active, the system will go into system failure state. After restart of the system the servo tool must be deactivated in order to jog the robot to a service position.

Deactivation may be performed from the Jogging window. Tap on Activate..., select the servo tool and tap on Deactivate.






10.2.7 Commissioning and service

Continued

After service / repair the revolution counter must be updated since the position has been lost, see

Update revolution counter on page 398

.




397


10.2.8 Mechanical unit calibrations

10.2.8 Mechanical unit calibrations

Fine calibration

Fine calibration must be performed when installing a new servo tool or if the servo tool axis is in state ‘Not Calibrated’.

For this, it is recommended to create a service routine using the following instructions:

STCalib "ToolName" \TipChg;

STCalib "ToolName" \TipWear;

Update revolution counter

An update of the revolution counter must be performed if the position of the axis is lost. If this happens, this is indicated by the calibration state ‘Rev. Counter not updated’.

For this, it is recommended to use the same service routine as for the fine calibration.





10.2.9 RAPID code example

10.2.9 RAPID code example

How to use the code package

The normal programming technique for Tool Control is to customize shell routines based on the example code below. These shell routines are then called from your program.

Using shell routines

This example shows a main routine in combination with a customized routine

( rMoveSpot

) that uses the standard servo tool instructions. The external process

(for example a weld timer) is indicated with the routine rWeld

.

PROC main()

MoveJ p1, v500, z50, weldtool;

MoveL p2, v1000, z50, weldtool;

! Perform weld process rMoveSpot weldpos1, v2000, curr_gun_name, 1000, 2, 1, weldtool\WObj:=weldwobj; rMoveSpot weldpos2, v2000, curr_gun_name, 1000, 2, 1, weldtool\WObj:=weldwobj; rMoveSpot weldpos3, v2000, curr_gun_name, 1500, 3, 1, weldtool\WObj:=weldwobj;

MoveL p3, v1000, z50, weldtool;

ENDPROC

PROC rMoveSpot (robtarget ToPoint, speeddata Speed, gunname Gun, num Force, num Thickness,

PERS tooldata Tool

\PERS wobjdata WObj)

! Move the gun to weld position.

! Always use FINE point to prevent too early closing.

MoveL ToPoint, Speed, FINE, weldtool \WOIbj=WObj;

STCloseGun Gun, Thickness; rWeld;

STOpenGun Gun;

ENDPROC

PROC rWeld()

! Request weld start from weld timer

SetDO doWeldstart,1;

! Wait until weld is performed

WaitDI diWeldready,1;

SetDO doWeldstart,0;

ENDPROC




399


10.3.1 Overview

10.3 I/O Controlled Axes [included in 1180-1]

10.3.1 Overview

Purpose

The purpose of I/O Controlled Axes is to control an axis from the robot controller by using an I/O interface instead of having the axis integrated into the IRC5 drive system.

For operation and programming, an I/O controlled axis acts just like an integrated process axis. The difference is that the drive unit of the I/O controlled axis is not directly connected to the drive system of the robot controller. The motion configuration provides an I/O interface, which connects the robot controller to an external servo regulator.

The robot controller can take and release control of the additional axis during program execution. The additional axis can be moved synchronously to the robot

(while controlled by the robot controller) or independently of the robot (while controlled by an external PLC).


• Servo guns

• Grippers


The RobotWare option I/O Controlled Axes gives you access to system parameters for configuring I/O controlled axes.

Basic approach

This is the general approach for setting up I/O Controlled Axes.

1 Configure the system parameters for the axis to be controlled via I/O. See


.

2 Operate the axis (jog, program etc.) just like any additional axis. See

RAPID programming on page 409 .

For additional axis in general, also see Operating manual - IRC5 with

FlexPendant and Application manual - Additional axes and stand alone controller.





10.3.2 Contouring error

10.3.2 Contouring error

What is a contouring error

A contouring error is generated if an I/O controlled axis on the programmed robot path of the robtarget is not reached based on the bus delay and acceleration. If this event occurs, the robot’s movement stops on the path. An error entry is made in the error log.

Possible causes for the occurrence of a contouring error:

• Robot collisions

• An external axis that is difficult to move or faulty

• Incorrect value of system parameter Bus delay time in ms

Error handling

1 Error – acknowledgement at the external process unit.

For that, each application needs to provide a “Reset” button. The process unit needs to be ready before the program can be started.

2 Motors On / Program start

If automatic movement back to path is allowed, the robot will move back automatically to path before the program continues with the instruction that was canceled. In case automatic movement is not allowed, a error message occurs. A selection menu provides possibilities to accept the movement or to cancel the start event.

In case the start event is canceled, the operator needs to change the operation mode to Operation Mode: “Man”

Now the operator can specify a further procedure before the robot program can be restarted. For example:

• move the robot manual out of collision area

• move to a previous move instruction

For more information, see topic Controller, type Path Return Region in Technical reference manual - System parameters.




401


10.3.3 Correcting the position

10.3.3 Correcting the position

Correcting the position

Correcting (teaching) a robot position ( robtarget

) is done using the button Modify

Position in the program editor (as for the robot axes).

For the following states, the modified position of the I/O controlled axis will not be the current position, but the last valid feedback position:

• Axis is not referenced

• Servo regulator is not operative

• Actual position of the I/O interface invalid

• Position is outside the operating range

The position correction is adopted for activated axes only. If an available axis is not activated, this axis is ignored. This means the robtarget substitute symbol for the axis in question remains unchanged. This state does not lead to an error.





10.3.4 Tool changing

10.3.4 Tool changing

Tool changing

If a tool is deactivated with the instruction

DeactUnit

, it is necessary to set the signal unit disable. When the tool is disabled (can be verified with signal unit_disabled), it is possible to disconnect the power supply to the tool, for example undock a spotwelding gun.

It is possible to configure the same logical axis number for different tools, but this requires the RobotWare option Servo Tool Change.




403


10.3.5 Installation

10.3.5 Installation

Installation

After installation of the robot system, the I/O controlled axes needs to be loaded in the system parameters.

Each required axis needs to be loaded separately. The specific motion file includes default motion parameters. Parameterization and adjustments of the loaded axis

is described in more detail in Configuration.







Default settings

A robot system with the option I/O Controlled Axes will, as default, have one mechanical unit called EXTCTL1. This will be logical axis number 7.

For EXTCTL1, there will be default signal names defined in the type External Control

Process Data, topic Motion.

Mandatory settings for the I/O controlled axis

The following configuration must be done with data for the mechanical unit that should be used as an I/O contreolled axis.

1 In type Transmission, set Transmission Gear Ratio. See

Type Transmission on page 408

.

2 In type Acceleration Data, set Nominal Acceleration, Nominal Deceleration,

Acceleration Derivate Ratio and Deceleration Derivate Ratio. See

Type

Acceleration Data on page 407

.

3 In type Arm, set Upper Joint Bound and Lower Joint Bound. See

Type Arm on page 408

.

4 In type Stress Duty Cycle, set Speed Absolute Max. See

Type Stress Duty

Cycle on page 408

.

5 In type Supervision Type, set static_position_limit and dynamic_position_limit.

See

Type Supervision Type on page 408 .

6 In type External Control Process Data, set Bus delay time in ms. See

Type

External Control Process Data on page 407

.

Optional customization settings

If other values than the default values are preferred, any of the following settings can be changed.

• To use another logical axis than 7, change the value for Logical Axis. See

Type Joint on page 408 .

• To change the names of the signals used to communicate with the I/O controlled axis, change the settings in the type External Control Process

Data, see

Type External Control Process Data on page 407 .

• To use an activation relay, set the parameter Use Activation Relay. See

Type

Mechanical Unit on page 408

.

Adding another axis

For a second I/O controlled axis, a configuration file must be loaded.

1 Load one of the .cfg files, in RobotStudio or the FlexPendant, from the IRC5 controller <system name>\PRODUCTS\RobotWare_6.XX.XXXX\options\ioctrlaxis\.

2 Make the same configurations as for the first I/O controlled axis.







Continued

Note

Several mechanical units may use the same logical axis number, but this requires the RobotWare option Servo Tool Change.

Settings for PROFINET

If a PROFINET bus is used, the parameter Reduction ratio should be set to 4 ms or 2 ms for the I/O controlled unit. See Application manual - PROFINET

Controller/Device.








This is a brief description of each parameter in I/O Controlled Axes. For more information, see the respective parameter in Technical reference manual - System parameters.

Type External Control Process Data

These parameters belongs to the type External Control Process Data in the topic

Motion.

Parameter

Bus delay time in ms

Regulator activation signal

Ext Controller output signal

Pos_ref output signal

Pos_ref sign signal

Pos_ref valid signal

Regulator is activated signal

Req pos is out of range input signal

Pos_fdb input signal

Pos_fdb sign signal

Pos_fdb_valid signal

Unit_ready input signal

Ext Controller input signal

Description

Parameter for bus delay time.

Output signal for activation of the I/O controlled unit.

Output signal for allowing external control of the unit.

Output signal with positioning reference for the I/O controlled axis.

Output signal with sign (+ or -) of the positioning reference for the I/O controlled axis.

Output signal that signals that the positioning reference is a valid signal and the axis needs to follow the reference signal.

Input signal that indicates if the I/O controlled unit is enabled and ready.

Input signal that signals if the required positioning reference is out of range.

Input signal with position feedback from the I/O controlled axis.

Input signal with with sign (+ or -) of the position feedback from the I/O controlled axis.

Input signal that indicates that the position feedback signal is valid.

Input signal from I/O controlled unit indicating that it is ready.

Input signal indicating that the external unit is in control of the movement. The robot controller is not allowed to move the external unit.

Type Acceleration Data

These parameters belongs to the type Acceleration Data in the topic Motion.

Parameter

Nominal Acceleration

Nominal Deceleration

Acceleration Derivate Ratio

Deceleration Derivate Ratio

Description

Worst case motor acceleration.

Worst case motor deceleration.

Defines how fast the acceleration can build up, i.e. an indication of the derivative of the acceleration.

Defines how fast the deceleration can build up, i.e. an indication of the derivative of the deceleration.







Continued

Type Arm

These parameters belongs to the type Arm in the topic Motion.

Parameter

Upper Joint Bound

Lower Joint Bound

Description

Defines the upper limit of the working area for this joint.

Defines the lower limit of the working area for this joint.

Type Joint

These parameters belongs to the type Joint in the topic Motion.

Parameter

Logical Axis

Description

Defines the axis number as seen by a RAPID program.

Two mechanical units can have the same value set for

Logical Axis, but then they cannot be activated at the same.

Type Mechanical Unit

These parameters belongs to the type Mechanical Unit in the topic Motion.

Parameter

Use Activation Relay

Description

Points out a relay that will be activated or deactivated when the mechanical unit is activated or deactivated.

Type Stress Duty Cycle

These parameters belongs to the type Stress Duty Cycle in the topic Motion.

Parameter

Speed Absolute Max

Description

The absolute highest motor speed to be used.

Type Supervision Type

These parameters belongs to the type Supervision Type in the topic Motion.

Parameter

static_position_limit dynamic_position_limit

Description

Position error limit at zero speed, in radians on motor side.

Position error limit (max lag) at max speed, in radians on motor side.

Type Transmission

These parameters belongs to the type Transmission in the topic Motion.

Parameter

Transmission Gear Ratio

Description

Defines the transmission gear ratio between motor and joint.





10.3.8 RAPID programming

10.3.8 RAPID programming

Data types

This is a brief description of specific considerations regarding RAPID data types when using I/O Controlled Axes.

General descriptions of the data types are found in Technical reference manual - RAPID Instructions, Functions and Data types.

Data type

robtarget

Description

The position of the I/O controlled axis is set as an additional axis in a robtarget

.

Example, where the I/O controlled axis is logical axis 7 and should be moved to position 100: p1 := [[20,50,-80], [1,0,0,0], [1,1,0,0],

[100,9E+09,9E+09,9E+09,9E+09,9E+09]];

Instructions

This is a brief description of specific considerations regarding RAPID instructions when using I/O Controlled Axes.

General descriptions of the instructions are found in Technical reference manual - RAPID Instructions, Functions and Data types.

Instruction

MoveL

MoveC

MoveJ

Description

Regular move instructions are used to move an I/O controlled axis.

The position value of the I/O controlled value is included in the robtarget

, see

Data types on page 409

.

The I/O controlled axis can be moved simultaneously with the robot.

RAPID example

PROC Sequence123()

...

MoveJ pHome, v1500, fine, tGun1;

ActUnit EXTCTL1;

MoveJ p100, v1000, z10, tGun1 \Wobj:=wobj1;

MoveL p101, v1000, fine, tGun1 \Wobj:=wobj1;

...

! Application-specific commands

...

MoveL p102, v1000, z10, tGun1 \Wobj:=wobj1;

MoveJ p100, v1000, fine, tGun1 \Wobj:=wobj1;

DeactUnit EXTCTL1;

MoveJ pHome, v1500, fine, tGun1;

ENDPROC




409


Index

Index

A

Absolute Accuracy, 113

Absolute Accuracy calibration, 125

Absolute Accuracy compensation, 123

Absolute Accuracy verification, 126

Acceleration Data, 393, 405, 407

Acceleration Derivate Ratio, 393, 407

Acceleration Max Uncalibrated, 395

accidental disconnection, 396

acknowledge messages, 277

activate Absolute Accuracy, 117

Activate at start up, 213

activate supervision, 260

activation disabled, 384

actor signals, 96–97

additional axes, 385

additional axis, 57

Add or replace parameters, 176

Adjustment Speed, 211

Advanced RAPID, 17

Advanced Shape Tuning, 137

AliasIO, 24–25

alignment, 131

analog signal, 47

Analog Signal Interrupt, 47

Analog Synchronization, 161

AND, 97

Application protocol, 265, 269

ArgName, 45 argument name, 45

Arm, 393, 405, 408

arm replacement, 119

asynchronous movements, 386

Auto acknowledge input, 13, 50

automatic friction tuning, 138

Auto mode, 304

axis, 223 axis reset, 223

B

binary communication, 80

binary data, 277

birth certificate, Absolute Accuracy, 127

BitAnd, 19

BitCheck, 19

BitClear, 19

bit functionality, 18

BitLSh, 19

BitNeg, 19

BitOr, 19

BitRSh, 19

BitSet, 19

BitXOr, 19

BookErrNo, 41

bool, 360

Bus delay time in ms, 407

byte, 19

ByteToStr, 19

C

C# API, 340

calibrate follower axis, 63

calibrate tool, 135

calibration data, 118




Calibration Force High, 391

Calibration Force Low, 391

Calibration Mode, 391

Calibration Offset, 393

Calibration Pendulum, 116

calibration process, 125

Calibration Time, 391

calibration tools, 116

CalibWare, 116

cell alignment, 131

certificate, Absolute Accuary, 127

change calibration data, 118

change of tool, Machine Synchronization, 188

channel, 364

character based communication, 80

Check unresolved references, Task type, 295

CirPathMode, 157

class, 364

ClearIOBuff, 81

ClearRawBytes, 85

Close, 81

CloseDir, 89

Close position adjust, 391

Close time adjust, 391

code example, 399

collision, 251

Collision Alarm Torque, 392

Collision Delta Position, 392

Collision Detection Memory, 254

Collision Error Handler, 255

Collision LP Bandwidth, 392

Collision Speed, 392

commissioning, 396

common data, 306

communication channel, 356

communication client, 362

Commutator Offset, 393

compensation, 123

compensation parameters, 113, 128

compliance errors, 122

comunication cable

connecting, 357

configuration

Absolute Accuracy, 117

configuration.xml, 366

configuration example, 370

configuration files, 361

configuration functionality, 27

configure Collision Detection, 258

configuring

sensors, 318

tasks, 298

Connected signal, 212

connection relay, 381

constants

Sensor Interface, 322

convention, 363

coordinate systems, 131

CopyFile, 89

CopyRawBytes, 85

Corr argument, 246

CorrClear, 245

CorrCon, 245 corrdescr, 245

CorrDiscon, 245

correction generator, 244

411

Index

CorrRead, 245

CorrWrite, 245

Counts Per Meter, 211

CPU_load_equalization, 212

creating tasks, 298

cross connections, 96

cut plane, 155

cut shape, 160

Cyclic bool, 51

D

data, 283

data exchange, 356

datapos, 22

Data ready signal, 212

data search functionality, 21

data types

Multitasking, 297

supported, 360

data variable example

Electronically Linked Motors, 71

data variables


Deactivate PTC superv. at disconnect, 380

deactivate supervision, 260

deactivate tasks, 303

debugging

strategies, 298

Deceleration Derivate Ratio, 393, 407

Deceleration Max Uncalibrated, 395

declarations, 306

deflection, 123

Delay ramp, 392

description.xml, 363

digital I/O signals, 96

dir, 89

directory management, 88

discarded message, 285

Disconnect deactivate, 380

disconnection, 396

dispatcher, 311

displacement, 70

Do not allow deact, 213

dynamic_position_limit , 408

E

EGM, 326

EGM .proto file, 355

EGM execution states, 331

EGM Path Correction, 326

EGM Position Guidance, 326

EGM RAPID components, 344

EGM sensor protocol, 339

EGM system parameters, 343


elements

channel, 364 class, 364

convention, 363

enum, 366

field, 367 member, 367

network, 364

property, 368

record, 367

settings, 365

type, 364

412

enums element, 366

errdomain, 38

error interrupts, 37

error sources in accuracy, 122

ErrRaise, 38 errtype, 38

Ethernet, 263, 267

Ethernet link, 358

event messages, 40 event number, 40

Event Preset Time, 76

Event recorder, 274

Ext Controller input signal, 407

Ext Controller output signal, 407

external axes, 250

external axis, 223

External Control Process Data, 405, 407

Externally Guided Motion, 326

External Motion Interface Data, 343

F

fake target, 123

false triggering, 261

FeedbackJoints, 359

FeedbackPose, 359

FeedbackTime, 359

FFW Mode, 394

Fieldbus Command Interface, 92

field element, 367

FIFO, 284

file communication, 79

Fileldbus Command, 211

file management, 88

FileSize, 89

file structures, 88

fine calibration, 398

finepoints, Machine Synchronization, 187

fixed position events, 73

fixture alignment, 132

FlexPendant, 313

follower, 57

Follower to Joint, 59

Force Master, 392

Force Master Control, 392

Force Ready Delay, 391

frame, 360

frame relationships, 134

frames, 131

FricIdEvaluate, 144

FricIdInit, 144

FricIdSetFricLevels, 144

friction compensation, 137

Friction FFW Level, 142

Friction FFW On, 142

Friction FFW Ramp, 142

friction level tuning, 138

FSSize, 89

functions

Advanced RAPID, 45

Multitasking, 297


G

General RAPID, 255

GetDataVal, 22

GetMaxNumberOfCyclicBool, 53

GetNextCyclicBool, 53




Index

GetNextSym, 22

GetNumberOfCyclicBool, 53

GetTrapData, 38

Google C++, 340

Google C++ API, 340

Google overview, 339

Google Protocol Buffers, 339

group I/O signals, 96

Group ID, 269

H

hydraulic press, 202

I

I/O Controlled Axes, 400

IError, 38

IIRFFP, 211

IndAMove, 226

IndCMove, 226

IndDMove, 226

Independent Axes, 223

independent joint, 250

Independent Joint, 225

Independent Lower Joint Bound, 225

independent movement, 223

Independent Upper Joint Bound, 225

IndInpos, 226

IndReset, 226

IndRMove, 226

IndSpeed, 226

Inertia, 393

Input Signal, 381

installation, 396

instructions

Advanced RAPID, 45

Multitasking, 297


interrupt, 47, 284, 307, 321, 324

interrupt functionality, 37

iodev, 81

IPers, 38

IP protocols, 358

IRMQMessage, 288

IsFile, 89

ISignalAI, 48

ISignalAO, 48

IsStopStateEvent, 45

IVarValue, 321

J

Jog Collision Detection, 254, 258

Jog Collision Detection Level, 254

Jog Collision Detection Level, 258

joint, 360

Joint, 59, 405, 408

joint zones, 217

K

ke Phase to Phase, 393

kinematic errors, 122

Kp, Gain Position Loop, 394–395

Kv 1 - 6, 392

Kv, Gain Speed Loop, 394

Kv, Gain Speed Loop, 395

L

l_f_axis_name, 69 l_f_axis_no, 69 l_f_mecunt_n, 69 l_m_axis_no, 69 l_m_mecunt_n, 69

Lag Control Master 0, 394

Linked M Process, 59

load calibration data, 118

Load Identification, 116

Local path, 265, 269

Lock Joint in Ipol, 59

logical AND, 98

Logical Axis, 380, 408–409

Logical Cross Connections, 96 logical operations, 96

logical OR, 98

loss of accuracy, 121

lost message, 285 lost queue, 285

Lower Joint Bound, 393, 408

LTAPP, 320

M

Main entry, Task type, 295

maintenance, 119

MakeDir, 89

manipulator replacement, 120

Manipulator Supervision, 254

Manipulator Supervision Level, 254

manual friction tuning, 140

manual mode, Machine Synchronization, 187, 189

master, 57

Master Follower kp, 60

Max Advance Distence, 212–213

Max Current, 393

Max Delay Distance, 213

Max Follower Offset, 59

Max Force Control Motor Torque, 391

Max Force Control Position Error, 394

Max Force Control Speed Limit, 394

Max Offset Speed, 59

Max pos err. closing, 392

Max Synchronization Speed, 213

measurement system, 226

mechanical unit, 314

Mechanical Unit, 405, 408

Mechanics, 213

member element, 367

merge of messages, 277

messages

outgoing, 359

received, 373 sent, 373

Min Synchronization Speed, 213

modes of operation, Machine Synchronization, 189

modules


molding machine, 206

motion commands, Machine Synchronization, 187

Motion Planner, 254

Motion Process Mode, 145

MotionSup, 256, 260

Motion Supervision, 254

Motion Supervision Max Level, 254

MotionTask, Task type, 296

Motor Calibration, 393

motor replacement, 119

Motor Torque 1- 10, 391




413

Index

Motor Type, 393

MotSupOn, 257

MotSupTrigg, 257

MoveC, 409

MoveCSync, 75

MoveJ, 409

MoveJSync, 75

MoveL, 409

MoveLSync, 75

Multitasking, 293

N

Name, 213, 265, 269

Name, Transmission Protocol type, 319–320

Nanopb, 340

network, 364

NFS Client, 267

No. of speed limits, 392

Nominal Acceleration, 393, 407

Nominal Deceleration, 393, 407

Nominal Speed, 211

non printable characters, 277

NORMAL, 295

NoSafety, 295

NOT, 98

Not Calibrated, 398

Null speed signal, 212

num, 360

Number of Stored Forces, 391

O

object queue, 166

offset_ratio, 69

Offset Adjust Delay Time, 59

Offset Speed Ratio, 59

Open, 81

OpenDir, 89

OperationMode, 359

OR, 97

outgoing message, 359

P

PackDNHeader, 93

PackRawBytes, 85

parameters

accuracy compensation, 128

Password, 265

path, 31

Path Collision Detection, 254, 258

Path Collision Detection Level, 254, 258

path correction, 244 path offset, 244

pathrecid, 230

PathRecMoveBwd, 230

PathRecMoveFwd, 230

path recorder, 237

Path Recovery, 229

PathRecStart, 230

PathRecStop, 230

PathRecValidBwd, 230

PathRecValidFwd, 230

Path resolution, 212

PC Interface, 271

PC SDK client, 283

performance limits, Machine Synchronization, 187

persistent variables, 305

PFRestart, 31

414

Phase Inductance, 393

Phase Resistance, 393

pitch, 122

PlannedJoints, 359

PlannedPose, 359

Pole Pairs, 393

polling, 307

Pos_fdb_valid signal, 407

Pos_fdb input signal, 407

Pos_fdb sign signal, 407

Pos_ref output signal, 407

Pos_ref sign signal, 407

Pos_ref valid signal, 407

pose, 360

position accuracy reduction, 66

position event, 73

Position signal, 212

position warnings, Machine Synchronization, 187

Post-synchronization Time, 391

power failure functionality, 31

PredictedTime, 359

prerequisites, 358

priorities, 300

Process, 59

process support functionality, 33

Process update time, 212

programmed speed, Machine Synchronization, 187

program pointer, 45

programs

editing, 298

property element, 368

proportional signal, 34

Protobuf, 339

Protobuf-csharp, 340

Protobuf-net, 340

protocols

Ethernet, 320

serial channels, 319

Q

queue handling, 284 queue name, 284

R

r1_calib, 117

Ramp time, 392

Ramp Time, 60

Ramp to real contact, 392

Ramp when Increase Force, 392

RAPID components

Advanced RAPID, 45

Multitasking, 297


RAPID editor, 274

RAPID limitations, Machine Synchronization, 188

RAPID Message Queue, 282

RAPID support functionality, 44

RAPID variables, 356

rawbytes, 85

RawBytesLen, 85

raw data, 84

ReadAnyBin, 81

ReadBin, 81

ReadBlock, 321

ReadCfgData, 28

ReadDir, 89

ReadErrData, 38




Index

ReadNum, 81

ReadRawBytes, 85

ReadStr, 81

ReadStrBin, 81

ReadVar, 321

real, 360

received message, 373

reconnect a servo tool, 396

record, 283

recorded path, 237

recorded profile, 202, 206

record element, 367

recover path, 229

References Bandwidth, 392

Regulator activation signal, 407

Regulator is activated signal, 407

relay, 381

Remote Address, 320

RemoveAllCyclicBool, 53

RemoveCyclicBool, 53

RemoveDir, 89

RemoveFile, 89

RenameFile, 89

replacements, 119

Req pos is out of range input signal, 407

reset, 226

reset axis, 223

reset follower axis, 65

resolver offset calibration, 125

restartdata, 34

RestoPath, 230

resultant signal, 96–97

resume signals, 35

Rev. Counter not updated, 398

reversed movement, 251

Rewind, 81

RMQEmptyQueue, 288

RMQFindSlot, 288

RMQGetMessage, 288

RMQGetMsgData, 288

RMQGetMsgHeader, 288

RMQGetSlotName, 288 rmqheader, 288

RMQ Max Message Size, 287

RMQ Max No Of Messages, 287

rmqmessage, 288

RMQ Mode, 287

RMQReadWait, 288

RMQSendMessage, 288

RMQSendWait, 288 rmqslot, 288

RMQ Type, 287

robjoint, 360

RoboCom Light, 320

robot alignment, 133

RobotStudio, 274

robtarget, 409

roll, 122

Rotating move, 213

Rotating Move, 394

routine call, 311

RTP1 protocol, 319

S

SCWrite, 272

select tasks, 303

SEMISTATIC, 295




SenDevice, 321

send message, 373

sensor, 244, 317

sensor_speed, 187


sensor object, 166

sensors

configuring, 318

Sensor Synchronization, 161

Sensor systems, 211

serial channel communication, 79

Serial Port, Transmission Protocol type, 319–320

Server address, 265, 269

Server path, 265, 269

service, 396

service connection, 357

service program, 62

Servo Tool Change, 377

SetAllDataVal, 22

SetDataSearch, 22

SetDataVal, 22

SetSysData, 45

settings.xml, 362

settings element, 365

setting up tasks, 298

set up Collision Detection, 258

SetupCyclicBool, 53

SG Process, 391

shapedata, 219

shared resources, 313

signal, 307, 311

SiTool, 369

SiWobj, 369

SocketAccept, 278

SocketBind, 278

SocketClose, 278

SocketConnect, 278

SocketCreate, 278 socketdev, 278

SocketGetStatus, 279

SocketListen, 278

Socket Messaging, 275

SocketReceive, 278

SocketSend, 278 socketstatus, 278

soft servo, 250

Soft Stop Timeout, 391

speed, 252

speed_ratio, 69

Speed Absolute Max, 394, 408

Speed Limit 1 - 6, 392

Speed Max Uncalibrated, 395

speed reduction % button, Machine

Synchronization, 187 speed warnings, Machine Synchronization, 187

Squeeze Position 1 -10, 391

Stall Torque, 393

STATIC, 295

static_position_limit , 408

stationary world zone, 219

STCalcForce, 390

STCalcTorque, 390

STCalib, 390

STClose, 390

StepBwdPath, 34

STIsCalib, 390

415

Index

STIsClosed, 390

STIsIndGun, 390

STIsOpen, 390

STIsServoTool, 390

STOpen, 390

StorePath, 230

Stress Duty Cycle, 394, 405, 408

string, 360

string termination, 277

StrToByte, 19

STTune, 390

STTuneReset, 390

supervision level, 254, 256, 260

Supervision Type, 394, 405, 408

synchronizing tasks, 309

synchronous movements, 386

syncident, 309

syncident, data type, 297

SyncMoveResume, 230

SyncMoveSuspend, 230

SysFail, 295

SysHalt, 295

SysStop, 295

system parameters

configuration functionality, 27

Controller topic, 359

Motion topic, 359

Multitasking, 295

Sensor Interface, 319–320

system resources, 313

T

Task, Task type, 295

Task, type, 295

taskid, 315

taskid, data type, 297

Task in foreground, 300

Task in foreground, Task type, 295

Task Panel Settings, 302

task priorities, 300

TaskRunMec, 314

TaskRunMec, function, 297

TaskRunRob, 314

TaskRunRob, function, 297

tasks, 293, 303, 309

adding, 298

data type, 297

editing programs, 298 setting up, 298

tasks, data type, 297

temporary world zone, 219

TestAndSet, 313

TestAndSet, function, 297

TextGet, 41

TextTabFreeToUse, 41

TextTabGet, 41

TextTabInstall, 41

text table file, 40

Ti Integration Time Speed Loop, 394–395

time, 360

tip change calibration, 387

Tip Force 1 - 10, 391

tip wear calibration, 387

tool, 378

tool calibration, 135

tool change calibration, 387

tool changer, 378

416

tools, 116

torque, 252

torque 1 - torque 6, 392

Torque Absolute Max, 394

torque distribution, 66 torque follower, 66

track motion, 250

Transmission, 394, 405, 408

Transmission Gear High, 225

Transmission Gear Low, 225

Transmission Gear Ratio, 394, 408

Transmission protocol, 265, 269

Transmission protocol, 265, 269

Transmission Protocol, type, 319–320

trapdata, 38

trap routine, 284

TriggC, 75

TriggCheckIO, 75

triggdata, 74

TriggEquip, 74

triggering, 261

TriggInt, 74

TriggIO, 74 triggios, 74 triggiosdnum, 74

TriggJ, 75

TriggL, 75

TriggLIOs, 75

TriggRampAO, 75

TriggSpeed, 34

TriggStopProc, 34

triggstrgo, 74

Trusted, 265, 269

TrustLevel, Task type, 295

TUNE_FRIC_LEV, 140

TUNE_FRIC_RAMP, 140

TuneServo, 140

tuning, 260

tuning, automatic, 138

tuning, manual, 140

type, 364

Type, 265, 269

Type, Task type, 295

Type, Transmission Protocol type, 319–320

U

UDP, 339

UdpUc, 332–333

Udp Unicast Communication, 332–333

uncalib, 117

Uncalibrated Control Master 0, 395

Unit_ready input signal, 407

UnpackRawBytes, 85

unsynchronize, 63

Update revolution counter, 398

Upper Joint Bound, 393, 408

Use Activation Relay, 408

Use Connection Relay, 381

Use Linked Motor Process, 59

Use Process, 59

Use ramp time, 392

User ID, 269

user message functionality, 40

Username, 265

Use Robot Calibration, 117




V

Velocity signal, 212

verification, 126

W

waiting for tasks, 309

WaitSyncTask, 309

WaitSyncTask, instruction, 297

WaitUntil, 307

WAN port, 357

WarmStart, 28

world zones, 217

Wrist Move, 153

wrist replacement, 119

Write, 81

WriteAnyBin, 81

WriteBin, 81

WriteBlock, 321

WriteCfgData, 28

WriteRawBytes, 85

WriteStrBin, 81

WriteVar, 321

WZBoxDef, 219

WZCylDef, 219

WZDisable, 220

WZDOSet, 220

WZEnable, 220

WZFree, 220

WZHomeJointDef, 220

WZLimJointDef, 220

WZLimSup, 220

WZSphDef, 219 wzstationary, 219 wztemporary, 219

Y

yaw, 122

Z

zones, 217

Index




417

Contact us

ABB AB

Discrete Automation and Motion

Robotics

S-721 68 VÄSTERÅS, Sweden

Telephone +46 (0) 21 344 400

ABB AS, Robotics

Discrete Automation and Motion

Nordlysvegen 7, N-4340 BRYNE, Norway

Box 265, N-4349 BRYNE, Norway

Telephone: +47 51489000

ABB Engineering (Shanghai) Ltd.

No. 4528 Kangxin Hingway

PuDong District

SHANGHAI 201319, China

Telephone: +86 21 6105 6666 www.abb.com/robotics

User manual | ABB IRC5 Controller software Application manual

Application manual

Controller software IRC5

Application manual

Controller software IRC5

Table of contents

Overview of this manual

1 Introduction to RobotWare

2 RobotWare-OS

3 Motion performance

wSlot pSlot

4 Motion coordination

5 Motion Events

6 Motion functions

7 Motion Supervision

8 Communication

9 Engineering tools

Robot

Rapid data

RRI

Sensor

Cabinet status

Motion data

10 Tool control options

Index

Contact us

Key Features

Related manuals

Frequently Answers and Questions

What are some of the key features of the ABB IRC5 controller?

What are some of the applications of the ABB IRC5 controller?

What are some of the benefits of using the ABB IRC5 controller?

Table of contents

User manual | ABB IRC5 Controller software Application manual

Application manual

Controller software IRC5

Application manual

Controller software IRC5

Table of contents

Overview of this manual

1 Introduction to RobotWare

2 RobotWare-OS

3 Motion performance

wSlot pSlot

4 Motion coordination

5 Motion Events

6 Motion functions

7 Motion Supervision

8 Communication

9 Engineering tools

Robot

Rapid data

RRI

Sensor

Cabinet status

Motion data

10 Tool control options

Index

Contact us

Key Features

Related manuals

ABB

IRB 1400, 2400, 4400, 6600, 7600

ABB

FlexPendant SDK

ABB Robotics

RobotWare 6

ABB

RobotWare 5.0

ABB

IRB 14000

ABB

IRC5 FlexPendant

ABB

Robotics

ABB

IRC5 with FlexPendant

ABB

IRC5 Compact

ABB

IRC5 Compact

ABB

SafeMove2

ABB

IRC5 Compact

Frequently Answers and Questions

What are some of the key features of the ABB IRC5 controller?

What are some of the applications of the ABB IRC5 controller?

What are some of the benefits of using the ABB IRC5 controller?

Table of contents