3HAC066554 AM Controller Software OmniCore-En
3HAC066554 AM Controller Software OmniCore-En
Application manual
Controller software OmniCore
Trace back information:
Workspace 22A version a10
Checked in 2022-03-02
Skribenta version 5.4.005
Application manual
Controller software OmniCore
RobotWare 7.6
Table of contents
Overview of this manual ................................................................................................................... 11
Open source and 3rd party components in RobotWare ................................................................. 13
1 Introduction to RobotWare 15
2 RobotWare-OS 17
2.1 Advanced RAPID .............................................................................................. 17
2.1.1 Introduction to Advanced RAPID ................................................................ 17
2.1.2 Bit functionality ....................................................................................... 18
2.1.2.1 Overview ................................................................................... 18
2.1.2.2 RAPID components ...................................................................... 19
2.1.2.3 Bit functionality example ............................................................... 20
2.1.3 Data search functionality .......................................................................... 21
2.1.3.1 Overview ................................................................................... 21
2.1.3.2 RAPID components ...................................................................... 22
2.1.3.3 Data search functionality examples ................................................. 23
2.1.4 Alias I/O signals ...................................................................................... 24
2.1.4.1 Overview ................................................................................... 24
2.1.4.2 RAPID components ...................................................................... 25
2.1.4.3 Alias I/O functionality example ....................................................... 26
2.1.5 Configuration functionality ........................................................................ 27
2.1.5.1 Overview ................................................................................... 27
2.1.5.2 RAPID components ...................................................................... 28
2.1.5.3 Configuration functionality example ................................................ 29
2.1.6 Power failure functionality ......................................................................... 30
2.1.6.1 Overview ................................................................................... 30
2.1.6.2 RAPID components and system parameters ..................................... 31
2.1.6.3 Power failure functionality example ................................................. 32
2.1.7 Process support functionality .................................................................... 33
2.1.7.1 Overview ................................................................................... 33
2.1.7.2 RAPID components ...................................................................... 34
2.1.7.3 Process support functionality examples ........................................... 35
2.1.8 Interrupt functionality ............................................................................... 37
2.1.8.1 Overview ................................................................................... 37
2.1.8.2 RAPID components ...................................................................... 38
2.1.8.3 Interrupt functionality examples ..................................................... 39
2.1.9 User message functionality ....................................................................... 40
2.1.9.1 Overview ................................................................................... 40
2.1.9.2 RAPID components ...................................................................... 41
2.1.9.3 User message functionality examples .............................................. 42
2.1.9.4 Text table files ............................................................................ 44
2.1.10 RAPID support functionality ...................................................................... 45
2.1.10.1 Overview ................................................................................... 45
2.1.10.2 RAPID components ...................................................................... 46
2.1.10.3 RAPID support functionality examples ............................................. 47
2.2 Analog Signal Interrupt ....................................................................................... 48
2.2.1 Introduction to Analog Signal Interrupt ........................................................ 48
2.2.2 RAPID components ................................................................................. 49
2.2.3 Code example ........................................................................................ 50
2.3 Connected Services .......................................................................................... 51
2.3.1 Overview ............................................................................................... 51
2.3.2 Connected Services connectivity ................................................................ 53
2.3.3 Connected Services registration ................................................................ 54
2.3.4 Summary of Connected Services paths in FlexPendant .................................. 56
2.3.5 Summary of Connected Services paths in RobotStudio .................................. 57
2.3.6 Configuration - system parameters ............................................................. 58
7 Communication 261
7.1 FTP&SFTP client [3116-1] ................................................................................... 261
7.1.1 Introduction to FTP&SFTP client ................................................................ 261
7.2 NFS Client [3117-1] ........................................................................................... 264
7.2.1 Introduction to NFS Client ......................................................................... 264
Index 279
Usage
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.
Prerequisites
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 Document ID
Product specification - OmniCore C line 3HAC065034-001
Product specification - OmniCore E line 3HAC079823-001
Operating manual - RobotStudio 3HAC032104-001
Operating manual - OmniCore 3HAC065036-001
Operating manual - Integrator's guide OmniCore 3HAC065037-001
Technical reference manual - RAPID Instructions, Functions and 3HAC065038-001
Data types
Technical reference manual - RAPID Overview 3HAC065040-001
Technical reference manual - System parameters 3HAC065041-001
Revisions
Revision Description
A Released with RobotWare 7.0.
B Released with RobotWare 7.01.
The following updates are made in this revision:
• "Cyber security" replaced by "Cybersecurity" in entire manual.
• Updated the section Connected Services on page 51.
Revision Description
C Released with RobotWare 7.0.2.
The following updates are made in this revision:
• FlexPendant terminology updated in entire manual.
• Updated the section Summary of Connected Services paths in Flex-
Pendant on page 56.
D Released with RobotWare 7.1.
The following updates are made in this revision:
• Updated the section Connected Services on page 51.
• Added information about YuMi robots and Collision Detection, see
Collision detection for YuMi robots on page 212.
• Updated limitations for SFTP client, see Limitations on page 262.
E Released with RobotWare 7.2.
The following updates are made in this revision:
• Updated the section Connected Services on page 51.
• Information about the digital output MotSupOn updated in section
Signals on page 220.
• Section System parameters on page 145 updated with information about
how to adjust the values of the attributes RMQ Max Message Size and
RMQ Max No Of Messages.
• Updated sections due to remote mounted disk/virtual root changes:
Limitations on page 262 (FTP&SFTP client) and Limitations on page 264
(NFS Client).
F Released with RobotWare 7.3.
The following updates are made in this revision:
• Updated the section Connected Services on page 51.
G Released with RobotWare 7.4.
The following updates are made in this revision:
• Added the section Connected Services Embedded troubleshooting
logs on page 92.
• Updated the section Connected Services on page 51.
• Updated information regarding UTF-8, in Raw data communication on
page 121.
H Released with RobotWare 7.5.
• Updated limitation for Collision Avoidance 3150-1 on page 225.
J Released with RobotWare 7.6.
• Added the section Auto Acknowledge Input on page 277.
• Updated limitation regarding lead-through, see Overview of World
Zones on page 205.
• Added the section SafeMove Assistant on page 227.
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 Description
RobotWare-OS 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 the product specification
for the robot controller.
RobotWare options 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 op-
tions are more comprehensive and are therefore described in sep-
arate manuals.
Process application These are extensive packages for specific process application like
options spot welding, arc welding, and dispensing. They are primarily de-
signed to improve the process result and to simplify installation and
programming of the application.
The process application options are all described in separate
manuals.
RobotWare Add-ins 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 Add-
ins. For example track motion IRBT, positioner IRBP, and stand
alone controller. For more information see the product specification
for the robot controller.
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 informa-
tion on creating RobotWare Add-ins, contact your local ABB Robotics
representative at www.abb.com/contacts.
Option groups
For OmniCore, 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 Description
Motion performance Options that optimize the performance of your robot.
Motion coordination Options that make your robot coordinated with external equipment
or other robots.
Motion Events Options that supervises the position of the robot.
Motion functions Options that controls the path of the robot.
Motion Supervision Options that supervises the movement of the robot.
Communication Options that make the robot communicate with other equipment.
(External PCs etc.)
Engineering tools Options for the advanced robot integrator.
Servo motor control Options that make the robot controller operate external motors, in-
dependent 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.
2 RobotWare-OS
2.1 Advanced RAPID
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 a
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.
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 Description
byte 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
Instructions, Functions and Data types.
Instruction Description
BitSet BitSet is used to set a specified bit to 1 in a defined byte data.
BitClear 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
Instructions, Functions and Data types.
Function Description
BitAnd BitAnd is used to execute a logical bitwise AND operation on data types
byte.
BitOr BitOr is used to execute a logical bitwise OR operation on data types byte.
BitXOr BitXOr (Bit eXclusive Or) is used to execute a logical bitwise XOR operation
on data types byte.
BitNeg BitNeg is used to execute a logical bitwise negation operation (one’s
complement) on data types byte.
BitLSh BitLSh (Bit Left Shift) is used to execute a logical bitwise left shift operation
on data types byte.
BitRSh BitRSh (Bit Right Shift) is used to execute a logical bitwise right shift oper-
ation on data types byte.
BitCheck 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.
Program code
CONST num parity_bit := 8;
2.1.3.1 Overview
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.
What is included
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.
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 Description
datapos 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 ob-
jects 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 Description
GetNextSym GetNextSym (Get Next Symbol) is used together with SetDataSearch to
retrieve data objects from the system.
!Search for all num variables starting with "my" in the module
"mymod"
SetDataSearch "num"\Object:="my.*"\InMod:="mymod";
2.1.4.1 Overview
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.
What is included
Alias I/O functionality consists of the instruction AliasIO.
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.
For more information, see the respective instruction in Technical reference
manual - RAPID Instructions, Functions and Data types.
Instruction Description
AliasIO 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.
2.1.5.1 Overview
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.
What is included
Configuration functionality includes the instructions: ReadCfgData, WriteCfgData,
and WarmStart.
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.
For more information, see the respective instruction in Technical reference
manual - RAPID Instructions, Functions and Data types.
Instruction Description
ReadCfgData 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 para-
meter (configuration data).
WarmStart 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.1.6.1 Overview
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.
What is included
The power failure functionality includes a function that checks for interrupted path:
PFRestart
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
Instructions, Functions and Data types.
Function Description
PFRestart PFRestart (Power Failure Restart) is used to check if the path was inter-
rupted 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 in-
terrupt 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.
2.1.7.1 Overview
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.
What is included
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.
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 Description
restartdata restartdata can contain the pre- and post-values of specified I/O sig-
nals (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 Description
TriggSpeed 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-de-
veloped 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.
!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;
Tip
ENDPROC
PROC resume_signals()
IF myproc_data.preshadowval = 1 THEN
SetDO do_close_gun,1;
ELSE
SetDO do_close_gun,0;
ENDIF
ENDPROC
2.1.8.1 Overview
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.
What is included
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.
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
Instructions, Functions and Data types.
Data type Description
trapdata trapdata represents internal information related to the interrupt that caused
the current trap routine to be executed.
errdomain errdomain is used to specify an error domain. Depending on the nature
of the error, it is logged in different domains.
errtype 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
Instructions, Functions and Data types.
Instruction Description
IPers 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.
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
2.1.9.1 Overview
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.
What is included
The user message functionality includes:
• Text table operating instruction TextTabInstall.
• Text table operating functions: TextTabFreeToUse, TextTabGet, and
TextGet.
• Instruction for error number handling: BookErrNo.
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 Description
BookErrNo 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.
For more information, see the respective function in Technical reference
manual - RAPID Instructions, Functions and Data types.
Function Description
TextTabFreeToUse TextTabFreeToUse is used to test whether the text table name is free
to use (not already installed in the system).
TextTabGet TextTabGet is used to get the text table number of a user defined text
table.
TextGet TextGet is used to get a text string from the system text tables.
PROC main()
!Book the new RAPID system error number
BookErrNo ERR_GLUEFLOW;
!Error handling
ERROR
IF ERRNO = ERR_GLUEFLOW THEN
ErrWrite "Glue error", "There is a problem with the glue flow";
ENDIF
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
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 with encoding UTF-8 or
ISO-8859-1.
2.1.10.1 Overview
Purpose
The RAPID support functionality consists of miscellaneous routines that might be
helpful for an advanced robot programmer.
Here are some examples of applications:
• 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.
What is included
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.
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.
For more information, see the respective instruction in Technical reference
manual - RAPID Instructions, Functions and Data types.
Instruction Description
SetSysData 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.
For more information, see the respective function in Technical reference
manual - RAPID Instructions, Functions and Data types.
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.
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;
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.
Here are some examples of applications:
• 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.
What is included
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 50.
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).
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
Instructions, Functions and Data types.
Instruction Description
ISignalAI 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 spe-
cified if the interrupt shall occur once or repeatedly.
ISignalAO 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 spe-
cified if the interrupt shall occur once or repeatedly.
Functions
Analog Signal Interrupt includes no RAPID functions.
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
2.3.1 Overview
Description
Connected Services is a functionality for ABB robot controllers to connect to ABB
Ability TM Connected Services Cloud by using 3G, WiFi, or wired connectivity.
Connected Services collects the service information from the controller.
Purpose
The primary purpose of Connected Services is to collect service information from
the controller.
These service information will be available through MyRobot for Connected Services
1.0, Connected Services portal for Connected Services 2.0, or pushed locally.
What is included
The RobotWare base functionality Connected Services gives you access to:
• a Connected Services agent software to manage the connectivity and the
service data collection.
• system parameters used to enable and configure the connectivity.
• status and information pages.
• dedicated event logs for key events of Connected Services.
• connectivity through Connected Services Gateway.
• connectivity through the public port.
Prerequisites
The Connected Services function requires that the controller is included in a service
agreement with ABB. Contact your local ABB office to create a service agreement
with Connected Services 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 service agreement.
Basic workflow
Connected Services is available natively as a plug and connect solution in
RobotWare. The setup concept is to:
1 Provides internet connectivity to the robot controller.
2 Configure connected services and startup the connection.
3 Register the controller through MyRobot registration page.
Once Connected Services is connected and registered, the data collection will run
transparently in the background.
Limitations
The controller identification is done using the controller serial number and must
match the serial number defined in the service agreement.
Power On Connect
Using a Connected Services Gateway 3G will provide automatic connectivity after
Power On of the controller without any configuration.
Production Registration
ABB will securely pre register Connected Services during production process to
avoid the manual registration.
The manual registration is still available when needed.
Note
The connectivity of the controller through the public network requires a Firewall
provided by the customer.
The communication is secured and encrypted using HTTPS (secure HTTP). The
communication is possible only from the controller to ABB Ability TM Cloud to keep
the customer network isolated from any external Internet access. The following
figures describe these concepts.
For Connected Services 1.0:
HTTPS:443
HTTPS:443
Service
ABB Connected
Public/WAN information
Service Cloud
3G
Connected Ability/LAN4 Connected
Wi-Fi Services Services
MyRobot ABB & gateway agent
Wired
Website Customer Internall
firewall
xx1900000977
HTTPS:443
Service
ABB Connected
Public/WAN information
Service Cloud
3G
Connected Ability/LAN4 Connected
Wi-Fi Services Services
Ability TM
Connected Services ABB & gateway agent
Wired
portal Customer Internall
firewall
xx2100000309
2d 2a
2b
2c
3d
Internet
4
ABB Connected
Services Center
Internet
3a 1a 0
3b 3c
Step Description
0 Check controller S/N and internet connectivity
1a Enable CSE and set up connectivity configuration
2a CS connectivity in place
2b Low poll for registration
2c Registration not trusted (get reg code)
2d Display registration code
3a Get registration code
3b Give controller S/N and registration code
3c Select controller S/N in SA and register with registration code
3d Registration trusted (client certificate)
4 Connected and registered secure CS session
Note
Note
Configuration
In Flexpendant the Connected Services configuration are available in:
• CS Gateway 3G: Settings > ABB Ability TM > 3G Connection
• CS Gateway WiFi: Settings > ABB Ability TM > WiFi Connection
• CS Gateway Wired: Settings > ABB Ability TM > Wired Connection
Status
In FlexPendant the Connected Services status are available in:
• Ability Network: Settings > ABB Ability TM > Network Status
• CS Gateway: Settings > ABB Ability TM > Connectivity Status
• Connected Services summary: QuickSet > ABB Ability TM
• Connected Services details: Settings > ABB Ability TM > Connected Services
Status
• Reset Connected Services: Operate > Service Routine
Logs
In Flexpendant the Connected Services logs are available in:
• Connection Logs (3G/WiFi): Settings > Backup and Recovery > Connection
Logs
• Details Logs: Settings > Backup and Recovery > System Diagnostic
Configuration
In RobotStudio the Connected Services configuration are available in:
• CS Gateway 3G: Controller > Configuration > Communication > CS Gateway
3G
• CS Gateway WiFi: Controller > Configuration > Communication > CS
Gateway WiFi
• CS Gateway Wired: Controller > Configuration > Communication > CS
Gateway Wired
Status
In RobotStudio the Connected Services status are available in:
• Connected Services Summary/Details: Controller > Properties > Device
Browser > Software Resources > Connected Services
• Reset Connected Services: Not implemented
Logs
In RobotStudio the Connected Services logs are available in:
• Connection Logs (3G/WiFi): Not implemented
• Details Logs: Controller > Properties > Save Diagnostic
Introduction
This section provides a brief description of system parameters used for the
Connected Services. For more information see Technical reference manual - System
parameters.
Note
Internet Gateway IP Defines the internet gateway IP of the connected network when the
connection type is private. This is valid for the Connection Type
Custom.
Forces the Internet Gateway to use for connectivity.
Internet DNS IP Defines the internet DNS IP of the connected network. This is valid
for the Connection Type Custom.
Forces the DNS to use for connectivity.
Proxy Used Defines if a proxy is used to access the internet and its name/ad-
dress, port, and authentication.
Proxy Auth Defines the proxy authentication type. Basic will use HTTP basic
authentication including user and password. None will not use any.
Server Polling Defines the frequency of polling for specific synchronization with
the sever. The available values are slow and fast.
For details about the behavior of events for server polling, see De-
scription of behavior of events for server polling on page 86.
Debug Mode Enables extensive logging for debugging the issues.
Trace Level Defines the level of logging if Debug Mode is enabled.
Parameter Description
Connected Services Defines the compatibility for different robot controller's data format,
Mode cloud solution, and specific features. Following are the available
modes:
• 1.0 IRC5 Compatibility
• 2.0 Omnicore [Preview]
Note
Note
Customer Storage Defines whether the data needs to be pushed to external network
disk or not (None, Disk) and MQTT. The disk path can be defined
separately.
This parameter is valid only for CSE 2.0.
Disk Path Defines the path to the external disk if Disk is selected.
This parameter is valid only for CSE 2.0.
Scheme Defines the type of scheme or protocol used for MQTT communica-
tion.
This parameter is valid only for CSE 2.0.
Web Socket Defines whether the scheme uses web socket connection or not.
This parameter is valid only for CSE 2.0.
Host Defines the MQTT host IP.
This parameter is valid only for CSE 2.0.
Port Defines the MQTT port number.
This parameter is valid only for CSE 2.0.
URL Defines the MQTT topic to publish data.
This parameter is valid only for CSE 2.0.
Auth Type Defines the authentication used for the MQTT connection. The au-
thentication type is basic authentication with user/password or Client
Certificate.
This parameter is valid only for CSE 2.0.
Certificate Path Defines the location to client certificate path.
This parameter is valid only for CSE 2.0.
Key Path Defines the location to client private key file path.
This parameter is valid only for CSE 2.0.
Server Check Defines whether the server certificate needs to be validated against
CA.
This parameter is valid only for CSE 2.0.
CA Path Defines the path to certificate authority or root certificate.
This parameter is valid only for CSE 2.0.
Force Zip Defines whether the data need to be compressed for publishing.
This parameter is valid only for CSE 2.0. (Not yet implemented.)
Parameter Description
Time Out Defines the MQTT connection timeout.
This parameter is valid only for CSE 2.0. (Not yet implemented.)
Keep Alive Defines the MQTT keep alive time.
This parameter is valid only for CSE 2.0. (Not yet implemented.)
Reconnect Period Defines the MQTT reconnect interval.
This parameter is valid only for CSE 2.0. (Not yet implemented.)
Retry Defines the retry count for MQTT connection.
This parameter is valid only for CSE 2.0. (Not yet implemented.)
Note
Note
For quick testing, use DNS defined as 8.8.8.8 (Google DNS), then switch to
customer recommended DNS server IP.
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.
Note
If the Internet Gateway is not the main Gateway, the traffic to rseprod.abb.com
and the DNS must be defined as additional routes.
For example, if Internet Gateway has IP address 100.100.100.22, rseprod.abb.com
has IP address 138.227.175.43 (verify by nslookup) and DNS has IP address
8.8.8.8, then you must define the following two routes:
• Route 138.227.175.43/31 to 100.100.100.22
• Route 8.8.8.8/31 to 100.100.100.22
2.3.7.1 Introduction
Overview
This section explains how Connected Services is configured using the controller
FlexPendant based on the available internet connectivity. Internet connectivity can
be provided in multiple ways.
• Connected Services Gateway module (3G, Wi-Fi, or wired)
• Direct internet connection on customer Public (WAN) network
• Direct internet connection on custom network
Note
Overview
Connected Services can be configured in the following ways depending on the
available connection type:
• Ability
• Public
• Custom
Note
Note
4 Tap Apply.
The Restart confirmation message is displayed.
5 Tap Yes.
The controller is restarted.
Connected Services starts communicating to the server based on the
configuration.
Check the connectivity status or event logs. For more details, see Connected
Services information on page 76.
Note
The Public network and DNS can be configured statically or automatically (via
DHCP). For more details, see Configuration of public network using FlexPendant
on page 67.
Note
Note
Procedure
The following procedure provides information about configuring the Connected
Services from the FlexPendant when there is Internet connection with proxy.
1 On the start screen, tap Settings, and then select ABB Ability from the menu.
2 Tap Connected Services.
The configuration parameters for Connected Services are displayed.
3 In the Proxy Used field, change the value to Yes.
The proxy parameters are displayed.
4 In the Proxy Name field, type a name for the proxy.
5 In the Proxy Port field, type the proxy port number.
6 In the Proxy Auth field, select Basic for basic authentication or select None
for no authentication from the drop-down list.
Note
Define the proxy user name and password for the basic authentication.
Even if a proxy is used, it is mandatory to define a DNS for name resolution.
7 Tap Apply and restart the controller to take effect of the changes.
2.3.8.1 Introduction
Overview
This section explains how the Connected Services is configured using RobotStudio
with the controller based on the available internet connectivity. Internet connectivity
can be provided in multiple ways.
• Connected Services Gateway Module (3G, WiFi, or wired)
• Direct internet connection on Customer Public (WAN) network
• Direct internet connection on custom network
Note
Overview
Connected services can be configured in the following three ways depending on
the available connection type:
• Ability
• Public
• Custom
Note
Note
6 Click OK.
7 Restart the controller.
The connected services start communicating to the server based on the
configuration.
Check the connectivity status in the device browser. For more details, see
Connected Services information on page 76.
Also refer to the event logs generated. For more details, see Technical
reference manual - Event logs for RobotWare 7.
Note
Note
Note
Use the following procedure to configure the connection type Custom using
RobotStudio:
1 In the Controller tab, click Configuration.
2 Right-click on Communication and select Configuration Editor.
The Configuration Editor is displayed.
3 Click Connected Services.
The configuration parameters for connected services is displayed.
4 Right-click on any field and select Edit Connected Services(s).
The Instance Editor is displayed.
5 In the Connection Type field, select the value Private Network.
6 In the Internet Gateway IP field, type the IP address of internet gateway.
7 In the Internet DNS IP field, type the IP address of Internet DNS.
8 Click OK.
9 Restart the controller.
The connected services start communicating to the server based on the
configuration.
Check the connectivity status in the device browser. For more details, see
Connected Services information on page 76.
Also refer to the event logs generated. For more details, see Technical
reference manual - Event logs for RobotWare 7.
Configuring IP Statically
Use the following procedure to configure statically IP using RobotStudio:
1 Right-click on the controller and select Properties > Network Settings.
The Network settings window is displayed.
2 Select the option Use following IP address.
3 Enter the values in IP address, Subnet mask, Default gateway fields.
4 Click OK and restart the controller
The IP is configured.
Note
It is still possible to define manual DNS with automatic IP. If there is conflict
between manual and automatic DNS, manual DNS has priority.
Procedure
The following procedure provides information about configuring the Connected
Services from the RobotStudio when there is internet connection with proxy.
1 In the Controller tab, click Configuration.
2 Right-click on Communication and select Configuration Editor.
The Configuration Editor is displayed.
3 Select Connected Services.
The configuration parameters for connected services is displayed.
4 Right-click on any field and select Edit Connected Services(s).
The Instance Editor is displayed.
5 In the Proxy Used field, select the value Yes.
The proxy parameters are displayed.
6 In the Proxy Name field, type a name for the proxy.
7 In the Proxy Port field, type the proxy port number.
8 In the Proxy Auth field, from the drop-down list, select Basic for basic
authentication or select None for no authentication.
Note
Define the Proxy User and Proxy Password fields for the basic
authentication. Even if a proxy is used, it is mandatory to define a DNS for
name resolution.
9 Click OK.
The controller is restarted and the changes are applied.
Note
Note
Overview page
The Overview page provides a summary of the Connected Services status and
information. If the status is not active then the other pages provide more detailed
information.
Field Description Possible values Example
Property
Enabled Displays the value of the master Yes/No Yes
configuration switch for turning the
Connected Services on/off.
Status Displays the current status to see For a description Active
whether there is a need to navigate of values, see
to the Server connection page or CSE Status on
Registration page. page 83.
Serial number Displays the identifier that is used Controller Serial 12-45678
to identify the controller in Connec- number
ted Services.
Robot OS Ver- Displays the Robot OS Version that Robot OS Ver- RobotOS_1.00.0-
sion is sent to the server. sion number 379
Robot Control Displays the Robot Control version Robot Control RobotCon-
version that is sent to the server. version name trol_7.0.0-405.In-
ternal+405
Connectivity page
The Connectivity page provides a summary of the Connected Services connectivity
to the server.
Field Description Possible Example
values
Status Displays the current status to see For a de- Active
whether there is a need to navigate scription of
to the Connectivity page or Regis- values, see
tration page. CSE Status
on page 83.
Connection Displays the status of communica- For a de- Connected
Status tion with the server and the type of scription of
error. values, see
CSE Connec-
tion Status
on page 84 .
Last updated Displays the relative time since the "HH:MM:SS ago"
information on the Connectivity
page has been generated.
Hardware gate- Displays the type of hardware gate- DSQC 1039 3G
way way and connection IP. Connected on IP:
192.168.126.1
Server name Displays the name of the server that "" CS 1.0 -
software agent is configured with. Server name rseprod.abb.com
CS 2.0 - cse.robot-
ics.abb.com
Server IP Displays the IP address of the serv- "" 138.227.175.43 for
er and the port number used for Server IP rseprod.abb.com
connection. The IP address is the 13.79.129.11 for
result of DNS name resolution done cse.robotics.abb.com
by software agent.
Server certific- Displays the server certificate name "" CS 1.0
ate name information. Server name rseprod.abb.com
Untrusted CS 2.0 cse.robot-
(Server) ics.abb.com
Note
Registration page
The Registration page provides a summary of the Connected Services registration.
Field Description Possible values Example
Status Displays the current status to see For a description Active
whether there is a need to navigate of values, see
to the Server connection page or CSE Status on
Registration page. page 83.
Registration Displays the registration status. For a description Register with
Status of values, see code in MyRobot
CSE Registration
Status on
page 85.
Registration Displays the registration code. This "-" 456735
code code can be used to register using Code value
MyRobot.
Advanced page
The Advanced page provides advanced information about the dialog between
software agent and server.
Field Description Possible values Example
Last HTTP mes- Displays the last message sent. Register GetMessage
sage CheckRegistered
LogMessage
GetMessage
GetConfig
SendGetSpecific-
Code
DownLoadFile
AcknowledgeMes-
sage
BoxUpload
GetRSEAgree-
mentInformation
SendDeviceIn-
formation
RequestClientCer-
tificate
RenewClientCerti-
ficate
periodicDeviceUp-
dateInformation
Last HTTP mes- Displays the date and time when the Sent 00:01:28
sage time last message was sent. ago
Last HTTP error Displays the HTTP error when the Not Available - if Not Available
last message was sent and the no error
message ID if 4XX. Error HTTP XXX
+ Message
Ability page
The Ability page provides advanced information about Ability connection, certificate
information, and also the data transaction details.
Field Description Possible values Example
Ability connec- Displays the status of Ability cloud For a list of pos- Connected to IoT
tion state connection. sible values and Hub
it description, see
Ability status on
page 85.
Ability connec- Displays the number of connection 0-N 2
tion error count error with Ability cloud connection.
Ability Device ID Displays the device id for the Ability 1ca930c7-e77f-
cloud connection. 4265-8005-
0ee493b84eeb
Ability Client Displays the common name of client 1ca930c7-e77f-
certificate certificate used for Ability cloud 4265-8005-
device connection. 0ee493b84eeb
Ability Client Displays the name of the Ability cli- ABB Ability(tm)
certificate issuer ent certificate issuer. Issuing CA
Ability Client Displays the date and time from -1 -if there is no Jul 2 00:00:00
certificate valid which the Ability client certificate is data 2020 GMT
from valid. Date and time (if
data is updated)
Ability Client Displays the date and time until -1 - if there is no Jul 3 23:59:59
certificate valid which the Ability client certificate is data 2020 GMT
until valid. Date and time - if
data is updated
Ability Client Displays the Ability client certificate 063433724FA2863
certificate serial serial number. 6BCB72916FF472
number CF6
DPS Server Displays the DPS server name. global azure-
Name devices-provision-
ing.net
DPS Server IP Displays the resolved IP address of 52.163212.39
the DPS server.
DPS Scope ID Displays the DPS Scope Id of the 0neOOOA3934
cloud configuration.
Note
IRC5 Compatibility is for CSE 1.0 while Motion Data Collector and Robot System
Data Collector is for CSE 2.0.
CSE Mode
The following table gives the information of CSE mode:
Code Value Description
CS_MODE_BOOT Boot Mode Connected Services during initialization.
CS_MODE_REGISTRATION Registration Mode Connected Services in registration mode.
CS_MODE_ACTIVE Active Mode Connected Services after registration is
successful.
CS_MODE_RESET Reset Mode Connected Services during reset of connec-
ted services.
CS_MODE_SLEEP Sleep Mode When there is a delay to perform operation.
CS_MODE_SHUTDOWN Shutdown Mode When suspend connected services until
revoke.
Ability status
The following table gives the information of Ability statuses:
Code Value Description
STATUS_CONFIG_PEND Config pending Ability configuration is
pending.
STATUS_CONFIG_DONE Config updated Ability configuration is up-
dated.
STATUS_CLIENT_CERT_PEND Client certificate pending Waiting to receive a new
Ability certificate.
STATUS_CLIENT_CERT_UPDATED Client certificate updated Ability Client certificate is
updated.
STATUS_DPS_INITIATED DPS Initiated DPS connectivity is initiated.
STATUS_IOT_HUB_ASSIGNED IoT Hub assigned IoT Hub is assigned.
STATUS_DPS_FAILED DPS failed DPS connectivity is failed.
STATUS_IOT_HUB_CONNECTED Connected to IoT Hub Connected to IoT Hub.
2.3.10 Troubleshooting
Overview
You can verify the connectivity from the controller to the Connected Services public
connector 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 (CSE 1.0) or
https://cse.abbrobotics.abb.com (CSE 2.0)) in a browser. The connectivity is
validated if the DNS name has been resolved, the browser presents a page
indicating the CS server, and secured with an ABB certificate as shown in the
following figures.
xx1500003225
xx2000001953
Note
In case of CSE 2.0, for connectivity to ABB Ability, the following servers on
Microsoft Azure need to be reachable on port 443 (HTTPS/MQTT):
• DPS: global.azure-devices-provisioning.net
• IoTHub: *.azure-devices.net
• BlobStorage: *.blob.core.windows.net
Cybersecurity
For more details, see the section OmniCore Cybersecurity in Operating
manual - Integrator's guide OmniCore.
Time accuracy
It is important to set up the time correctly in the controllers including Time Zone,
either manually or with NTP. For more details, see the section Changing date and
time in Operating manual - OmniCore.
Overview
This option is used to check the current connection state of the connectivity module
for troubleshooting.
Note
Connection log is available only for Connected Services Gateway 3G and Wi-Fi
(not for Wired).
Procedure
Use the following procedure to check the current connection state of the connectivity
module:
1 Open Settings.
2 Tap Backup & Recovery.
3 On the left sidebar tap Connection log.
The Connection log page is displayed and the logs are displayed on a
window.
Note
xx1900000976
4 Tap Export.
5 If required, in the File Name field edit the name of the file.
6 If required, to change the storage path, in the Folder Name field tap Browse
and select the required path.
7 Tap Create.
The current connection state of the connectivity module is saved in the
selected path.
2.3.10.3 How to get Connected Services Embedded logs from the controller
Procedure
Use the following procedure to retrieve the CSE logs from the controller:
1 Open RobotStudio, click the Controller tab, and add the controller.
Note
TM
ABB Ability
Controller 1 Controller 2
Network Switch
xx1900001182
TM
ABB Ability
Internet Gateway
Wi-Fi AP
Controller 1 Controller 2
Network Switch
xx1900001183
TM
ABB Ability
Controller 1 Controller 2
Internet Gateway
Public Network
Network Switch
xx1900001184
xx1900001185
xx1900001188
Controller 2 Controller 3
xx1800002942
For more information about how to do setting for the gateway box for multiple
controllers, see Product manual - Connected Services.
Note
CAUTION
Note
Using the ABB Service Box will allow Remote Access features. A standard 4G
router can also be used with same principles.
xx1600001337
Action Illustration
1 In the ABB menu, select Control Panel.
Continues on next page
102 Application manual - Controller software OmniCore
3HAC066554-001 Revision: J
© Copyright 2019-2022 ABB. All rights reserved.
2 RobotWare-OS
2.3.11 Network topology scenarios
Continued
Action Illustration
2 Select Configuration.
3 From Topics, select Communication.
4 Select IP Route and tap Add.
5 Enter the details for Destination, Gate-
way, and Label.
• Enter the Gateway IP as box IP.
In this example, it is 172.16.16.25.
xx1600001339
Note
Manually define the DNS, if it is not provided automatically. Also, define a route
to go through the gateway box for the DNS IP.
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.
What is included
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 107.
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;
Configuration
The following behavior of the Cyclic bool functionality can be configured:
Parameter Description
RemoveAtPpToMain It is possible to configure if the cyclically evaluated logical conditions
shall be removed or not when setting the program pointer to main.
• On - remove.
• Off - do not remove (default behavior).
ErrorMode It is possible to configure which error mode to use when the evalu-
ation of a Cyclic bool fails.
• SysStopError i - stop RAPID execution and produce an error
log (default behavior).
• Warning - produce a warning log.
• None - do nothing.
RecoveryMode It is possible to configure if a failing Cyclic bool shall be recovered
or not.
• On - try to recover the evaluation of a failing Cyclic bool (de-
fault behavior).
• Off - do not try to recover the evaluation of a Cyclic bool.
i Error mode SysStopError can only be combined with RecoveryMode - "On".
For more information, see System parameters on page 110.
Syntax
SetupCyclicBool Flag Cond [\Signal]
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
• Operands: 'NOT', 'AND', 'OR', 'XOR', '=', '(', ')'
\Signal shall be of:
• Object type: signaldo
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.
• Any PERS num or dnum, CONST num or dnum or literal num or dnum used in a
condition must be of integer type. If using any decimal value this will cause
a fatal error.
PROC main()
SetupCyclicBool cyclicbool1, di1=1 AND do2=1;
WaitUntil cyclicbool1=TRUE;
! All is ok
...
! Remove connection when no longer in use
RemoveCyclicBool cyclicbool1;
ENDPROC
PROC main()
SetupCyclicBool cyclicbool1, flag1=TRUE AND flag2=TRUE;
WaitUntil cyclicbool1=TRUE;
! All is ok
...
! Remove connection when no longer in use
RemoveCyclicBool cyclicbool1;
ENDPROC
PROC main()
SetupCyclicBool cyclicbool1, num1=7 OR dnum1=10000000;
SetupCyclicBool cyclicbool2, num1=8 OR dnum1=11000000;
WaitUntil cyclicbool1=TRUE;
...
WaitUntil cyclicbool2=TRUE;
...
! Remove all connections when no longer in use
RemoveAllCyclicBool;
ENDPROC
PROC main()
SetupCyclicBool cyclicbool1, flag1=TRUE AND (num1=7 OR
dnum1=10000000);
WaitUntil cyclicbool1=TRUE;
! All is ok
...
! Remove connection when no longer in use
RemoveCyclicBool cyclicbool1;
ENDPROC
PROC main()
SetupCyclicBool cyclicbool1, flag1=MYTRUE AND num1=NUMLIMIT AND
dnum1=DNUMLIMIT;
WaitUntil cyclicbool1=TRUE;
! All is ok
...
! Remove connection when no longer in use
RemoveCyclicBool cyclicbool1;
ENDPROC
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
Instructions
Instruction Description
SetupCyclicBool SetupCyclicBool connects a logical condition to a boolean
variable.
RemoveCyclicBool RemoveCyclicBool removes a specific connected logical con-
dition.
RemoveAllCyclicBool RemoveAllCyclicBool removes all connected logical condi-
tions.
Functions
Function Description
GetMaxNumberOfCyclicBool GetMaxNumberOfCyclicBool retrieves the maximum
number of cyclically evaluated logical condition that can
be connected at the same time.
GetNextCyclicBool GetNextCyclicBool retrieves the name of a connected
cyclically evaluated logical condition.
GetNumberOfCyclicBool GetNumberOfCyclicBool retrieves the number of a
connected cyclically evaluated logical condition.
IsCyclicBool IsCyclicBool is used to test if a persistent boolean is
a Cyclic bool or not, i.e. if a logical condition has been
connected to the persistent boolean variable with the
instruction SetupCyclicBool.
Data types
Cyclic bool includes no data types.
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 121.
What is included
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 114.
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 require the option for the industrial network in
question.
Device Command Interface is supported by the following type of industrial networks:
• DeviceNet
• EtherNet/IP
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 Description
PackDNHeader 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.
System parameters
There are no specific system parameters in Device Command Interface. For
information on system parameters in general, see Technical reference
manual - System parameters.
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
2.6.2.1 Overview
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
What is included
To handle binary and character based communication, RobotWare gives you access
to:
• instructions for manipulations of a file or I/O device
• instructions for writing to file or I/O device
• instruction for reading from file or I/O device
• functions for reading from file or I/O device.
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 Code examples on page 119.
1 Open a file or I/O device.
2 Read or write to the file or I/O device.
3 Close the file or I/O device.
Limitations
Access to files and I/O devices 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.
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 Description
iodev iodev contains a reference to a file or I/O device. 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 Description
Open Open is used to open a file or I/O device for reading or writing.
Close Close is used to close a file or I/O device.
Rewind Rewind sets the file position to the beginning of the file.
Write Write is used to write to a character based file or I/O device.
WriteBin WriteBin is used to write a number of bytes to a binary I/O device or
file.
WriteStrBin WriteStrBin is used to write a string to a binary I/O device or file.
WriteAnyBin WriteAnyBin is used to write any type of data to a binary I/O device or
file.
ReadAnyBin ReadAnyBin is used to read any type of data from a binary I/O device
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 Description
ReadNum ReadNum is used to read a number from a character based file or I/O device.
ReadStr ReadStr is used to read a string from a character based file or I/O device.
ReadBin ReadBin is used to read a byte (8 bits) from a file or I/O device. This function
works on both binary and character based files or I/O devices.
ReadStrBin ReadStrBin is used to read a string from a binary I/O device or file.
PROC read_from_file()
VAR iodev file;
VAR num number;
VAR string text;
2.6.3.1 Overview
Purpose
The purpose of raw data communication is to pack different type of data into a
container and send it to a file or I/O device, and to read and unpack data. This is
particularly useful when communicating via a fieldbus, such as DeviceNet.
What is included
To handle raw data communication, RobotWare 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
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 123.
1 Pack data into a rawbytes variable (data of type num, byte or string).
2 Write the rawbytes variable to a file or I/O device.
3 Read a rawbytes variable from a file or I/O device.
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 and I/O devices 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.
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 Description
rawbytes rawbytes is used as a general data container. It can be filled with any
data of types num, byte, or string. It also stores the length of the
valid data (in bytes).
rawbytes can contain up to 1024 bytes of data. The supported data
formats are listed in the instruction PackRawBytes, in Technical refer-
ence manual - RAPID Instructions, Functions and Data types.
Instructions
This is a brief description of each instruction used for raw data communication.
For more information, see the respective instruction in Technical reference
manual - RAPID Instructions, Functions and Data types.
Instruction Description
ClearRawBytes 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 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 WriteRawBytes is used to write data of type rawbytes to any binary
file or I/O device.
ReadRawBytes ReadRawBytes is used to read data of type rawbytes from any binary
file or I/O device.
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
Instructions, Functions and Data types.
Function Description
RawBytesLen RawBytesLen is used to get the valid data length in a rawbytes vari-
able.
PROC write_rawbytes()
VAR num length := 0.2;
VAR string length_unit := "meters";
Close io_device;
ENDPROC
PROC read_rawbytes()
VAR string answer;
Close io_device;
Copy rawbytes
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 rawbytes raw_data_2;
VAR rawbytes raw_data_3;
VAR num my_length:=0.2;
VAR string my_unit:=" meters";
2.6.4.1 Overview
Purpose
The purpose of the file and directory management is to be able to browse and edit
file structures (directories and files).
What is included
To handle file and directory management, RobotWare 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 Code examples on page 127.
1 Open a directory.
2 Read from the directory and search until you find what you are looking for.
3 Close the directory.
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 Description
dir 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.
For more information, see the respective instruction in Technical reference
manual - RAPID Instructions, Functions and Data types.
Instruction Description
OpenDir OpenDir is used to open a directory.
CloseDir CloseDir is used to close a directory.
MakeDir MakeDir is used to create a new directory.
RemoveDir RemoveDir is used to remove an empty directory.
CopyFile 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.
For more information, see the respective instruction in Technical reference
manual - RAPID Instructions, Functions and Data types.
Function Description
ReadDir 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 FileSize is used to retrieve the size (in bytes) of the specified file.
FSSize 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 IsFile test if the specified file is of the specified type. It can also be used
to test if the file exist at all.
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 sizes
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;
2.7.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.
What is included
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 133.
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.
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
Instructions, Functions and Data types.
Data type Description
triggdata triggdata is used to store data about a position event.
A position event can take the form of setting an output signal or run-
ning 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 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 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 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
Instructions, Functions and Data types.
Instruction Description
TriggIO 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 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 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).
Instruction Description
TriggCheckIO 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 po-
sition.
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 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 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 TriggC is a move instruction, similar to MoveC. In addition to the
movement the 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. These
must be defined before calling TriggC.
TriggJ TriggJ is a move instruction, similar to MoveJ. In addition to the
movement the 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. These
must be defined before calling TriggJ.
TriggLIOs TriggLIOs is a move instruction, similar to MoveL. In addition to the
movement the 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 MoveLSync is a linear move instruction that calls a procedure in the
middle of the corner path.
MoveCSync MoveCSync is a circular move instruction that calls a procedure in
the middle of the corner path.
MoveJSync MoveJSync is a joint move instruction that calls a procedure in the
middle of the corner path.
Functions
Fixed Position Events includes no RAPID functions.
System parameters
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 Description
Event Preset Time TriggEquip takes advantage of the delay between the RAPID exe-
cution 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.
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
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
Result
The procedure will be called when the TCP is at the position marked with X (see
illustration).
xx0300000165
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.
Here are some examples of applications:
• 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).
What is included
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.
System parameters
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 136.
These parameters belong to the type Cross Connection in the topic I/O System.
Parameter Description
Name Specifies the name of the cross connection.
Resultant The I/O signal that receive the result of the cross connection as its new
value.
Actor 1 The first I/O signal to be used in the evaluation of the Resultant.
Invert actor 1 If Invert actor 1 is set to Yes, then the inverted value of Actor 1 is used in
the evaluation of the Resultant.
Operator 1 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 The second I/O signal (if more than one) to be used in the evaluation of the
Resultant.
Invert actor 2 If Invert actor 2 is set to Yes, then the inverted value of Actor 2 is used in
the evaluation of the Resultant.
Operator 2 Operand between Actor 2 and Actor 3.
See Operator 1.
Actor 3 The third I/O signal (if more than two) to be used in the evaluation of the
Resultant.
Invert actor 3 If Invert actor 3 is set to Yes, then the inverted value of Actor 3 is used in
the evaluation of the Resultant.
Operator 3 Operand between Actor 3 and Actor 4.
See Operator 1.
Actor 4 The fourth I/O signal (if more than three) to be used in the evaluation of the
Resultant.
Invert actor 4 If Invert actor 4 is set to Yes, then the inverted value of Actor 4 is used in
the evaluation of the Resultant.
Operator 4 Operand between Actor 4 and Actor 5.
See Operator 1.
Actor 5 The fifth I/O signal (if all five are used) to be used in the evaluation of the
Resultant.
Invert actor 5 If Invert actor 5 is set to Yes, then the inverted value of Actor 5 is used in
the evaluation of the Resultant.
2.8.3 Examples
Logical AND
The following logical structure...
xx0300000457
Logical OR
The following logical structure...
xx0300000459
Inverted signals
The following logical structure (where a ring symbolize an inverted signal)...
xx0300000460
Several resultants
The following logical structure can not be implemented with one cross connection...
xx0300000462
... but with three cross connections it can be implemented as shown below.
Resultant Actor 1 Invert actor 1 Operator 1 Actor 2 Invert actor 2
di17 di1 No AND do2 No
do26 di1 No AND do2 No
do13 di1 No AND do2 No
Complex conditions
The following logical structure...
xx0300000461
2.8.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 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.
Purpose
The purpose of RAPID Message Queue is to communicate with another RAPID
task or PC application using PC SDK.
Here are some examples of applications:
• 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.
What is included
The RAPID Message Queue functionality is included in the RobotWare options:
• Multitasking
• RobotStudio Connect
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 Code examples on page 147.
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.
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
• 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
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.
Message content
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]]"
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
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.
Related information
For more information on queues and messages, see Technical reference
manual - RAPID kernel.
Type Task
These parameters belong to the type Task in the topic Controller.
Parameter Description
RMQ Type 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 ap-
plications). 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 con-
troller and external clients (FlexPendant and PC applic-
ations).
The default value is None.
RMQ Mode Defines the mode of the queue.
Can have one of the following values:
• Interrupt - A message can only be received by connect-
ing a trap routine to a specified message type.
• Synchronous - A message can only be received by
executing an RMQReadWait instruction.
Default value is Interrupt.
RMQ Max Message Size The maximum data size, in bytes, for a RAPID Message
Queue message.
An integer between 400 and 3000. The default value is 400.
Note
RMQ Max No Of Messages The maximum number of RAPID Message Queue messages
in the queue to this task.
An integer between 1 and 10. The default value is 5.
Note
Instructions
Instruction Description
RMQFindSlot Find the slot identity number of the queue configured for a
RAPID task or Robot Application Builder client.
RMQSendMessage Send data to the queue configured for a RAPID task or Robot
Application Builder client.
IRMQMessage Order and enable cyclic interrupts for a specific data type.
RMQGetMessage Get the first message from the queue of this task. Can only
be used if RMQ Mode is defined as Interrupt.
RMQGetMsgHeader Get the header part from a message.
RMQGetMsgData Get the data part from a message.
RMQSendWait Send a message and wait for the answer. Can only be used
if RMQ Mode is defined as Interrupt.
RMQReadWait Wait for a message. Can only be used if RMQ Mode is defined
as Synchronous.
RMQEmptyQueue Empty the queue.
Functions
Function Description
RMQGetSlotName 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
Sender
MODULE SenderMod
RECORD msgrec
num x;
num y;
ENDRECORD
PROC main()
VAR rmqslot destinationSlot;
VAR msgrec data;
VAR robtarget p_current;
! 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
RMQFindSlot destinationSlot "RMQ_OtherTask";
! Avoid execution stop due to retry count exceed
ResetRetryCount;
RETRY;
ELSIF ERRNO = ERR_RMQ_FULL THEN
WaitTime 1;
! Avoid execution stop due to retry count exceed
ResetRetryCount;
RETRY;
ENDIF
ENDPROC
ENDMODULE
PC SDK client
public void RMQReceiveRecord()
Continues on next page
Application manual - Controller software OmniCore 147
3HAC066554-001 Revision: J
© Copyright 2019-2022 ABB. All rights reserved.
2 RobotWare-OS
2.9.5 Code examples
Continued
{
const string destination_slot = "RMQ_OtherTask";
IpcQueue queue = Controller.Ipc.CreateQueue(destination_slot,
16, Ipc.MaxMessageSize);
// Display x and y
}
}
if (Controller.Ipc.Exists(destination_slot))
Controller.Ipc.DeleteQueue(Controller.Ipc.GetQueueId(destination_slot));
}
PROC main()
! Connect to queue in other task
RMQFindSlot destinationSlot "RMQ_OtherTask";
ERROR
IF ERRNO = ERR_RMQ_INVALID THEN
WaitTime 1;
! Reconnect to queue in other task
RMQFindSlot destinationSlot "RMQ_OtherTask";
! Avoid execution stop due to retry count exceed
ResetRetryCount;
RETRY;
ELSIF ERRNO = ERR_RMQ_FULL THEN
WaitTime 1;
! Avoid execution stop due to retry count exceed
ResetRetryCount;
RETRY;
ELSEIF ERRNO = ERR_RMQ_TIMEOUT THEN
! Avoid execution stop due to retry count exceed
ResetRetyCount;
RETRY;
ENDIF
ENDPROC
ENDMODULE
if (Controller.Ipc.Exists(destination_slot))
Controller.Ipc.DeleteQueue(Controller.Ipc.GetQueueId(destination_slot));
}
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.
What is included
The RobotWare functionality 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 Code examples for Socket Messaging on page 156.
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.
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).
Overview
When using the functionality Socket Messaging to communicate with a client or
server that is not a RAPID task, the following information can be useful.
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.
Data types
This is a brief description of each data type in Socket Messaging. For more
information, see Technical reference manual - RAPID Instructions, Functions and
Data types.
Data type Description
socketdev A socket device used to communicate with other computers on a net-
work.
socketstatus Can contain status information from a socketdev variable.
Tip
Instruction Description
SocketBind 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.
SocketListen Makes the computer act as a server and accept incoming
connections. It will listen for a connection on the port specified
by SocketBind.
SocketAccept Accepts an incoming connection request. Used by the server
to accept the client’s request.
Note
The server application must be started before the client application, so that the
instruction SocketAccept is executed before any client execute
SocketConnect.
Functions
This is a brief description of each function in Socket Messaging. For more
information, see Technical reference manual - RAPID Instructions, Functions and
Data types.
Function Description
SocketGetStatus 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).
! 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
Description
The RobotWare base functionality User logs generates event logs for the most
common user actions. The event logs are generated in the group Operational
events, number series 1 xxxx.
For more information on handling the event log, see Operating manual - OmniCore
and Technical reference manual - Event logs for RobotWare 7.
Purpose
The purpose of User logs is to track changes in the robot controller related to user
actions. This can for example be helpful to find the root cause if a production stop
occurs.
What is included
The RobotWare base functionality User logs generates event logs for the following
changes related to user actions:
Topic User action
Program execution Changing the speed or run mode (single cycle/continuous).
Making changes to the task selection panel. Setting or reset-
ting non motion execution mode.
Simulate wait instructions Simulating wait instructions, for example WaitTime,
WaitUntil, WaitDx, etc.
RAPID changes Opening or closing RAPID programs or modules, editing
RAPID code, or modifying robot positions.
Program pointer movements Moving the program pointer to main, to a routine, to a posi-
tion, or to a service routine (call routine).
Changes on the mechanical Updating the revolution counters or performing a calibration.
unit
Jogging Changing the tool, the work object, the payload, the coordin-
ate system, or go to a position.
Supervision Setting or resetting the jog or path supervision. Setting the
level of supervision.
Change of configuration Loading configuration data or changing a configuration at-
tribute.
System changes Clearing the event log or changing date and time.
Serial measurement board Changing the data in the serial measurement board or
changing the data in the robot memory.
3 Motion Performance
3.1 Absolute Accuracy [3101-x]
Purpose
Absolute Accuracy is a calibration concept that improves TCP accuracy. 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 compensates for these differences.
Here are some examples of when this accuracy is important:
• Exchangeability of robots
• Offline programming with no or minimum touch-up
• Online programming with accurate movement and reorientation of tool
• Programming with accurate offset movement in relation to eg. vision system
or offset programming
• Re-use of programs between applications
The option Absolute Accuracy is integrated in the controller algorithms and does
not need external equipment or calculation.
Note
xx1300002177
What is included
Every Absolute Accuracy robot is delivered with:
• compensation parameters saved on the robot’s serial measurement board
Note
In a robot system with, for example, an additional axis or track motion, the
Absolute Accuracy is active for the manipulator but not for the additional axis or
track motion.
RAPID instructions
There are no RAPID instructions included in this option.
Overview
The following products are recommended for operation and maintenance of
Absolute Accurate robots:
• Load Identification
• 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 - OmniCore.
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.3 Configuration
9 Tap Cabinet or robot has been exchanged and confirm by tapping Yes.
3.1.4 Maintenance
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
Note
Tool recalibration
For information about tool recalibration, see Tool calibration on page 178.
Motor replacement
Replacement of all motors requires a re-calibration of the corresponding resolver
offset parameter using the standard calibration method for the respective robot.
This is described in the product manual for the robot.
If the motor replacement requires disassembly of the arm, then see Arm
replacement or disassembly on page 164.
Wrist replacement
Replacement of the wrist unit requires a re-calibration of the resolver offsets for
axes 5 and 6 using the standard calibration method for the respective robot.
Note
An update of the defined work objects will make the deviation less in positioning.
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 162. 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 176.
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 - OmniCore).
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
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
xx0300000227
Fake target
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
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
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
z
Measured positions AbsAcc
parameters
(Robot base frame)
y
Measurement
x system
xx1900001203
3.1.7.1 Overview
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:
Action Description
1 Measure fixture alignment Determine the relationship between the measurement
system and the fixture. See Measure fixture alignment
on page 175.
2 Measure robot alignment Determine the relationship between the measurement
system and the robot. See Measure robot alignment
on page 176.
3 Calculate frame relationships Determine the relationship between, for example, the
robot and the fixture. See Frame relationships on
page 177.
4 Calibrate tool Determine the relationship between the robot tool and
other cell components. See Tool calibration on
page 178.
Illustration
=Robtargets
Z
Z
Y
Y
3.
Work object
transformation X
=Mounting pins
X User (Fixture) =Reference points
Robot base
X
Z
3. 1.
Base frame Z 2.
transformation
Y
Y
Measurement
X system base
World
=Reference points
1.
en0300000239
Illustration
Z
Y
Z
X
Y
2
Measurement 3
system base
X
1 4
User (Fixture)
=Reference points
en0300000237
Select method
The relationship between the measurement system and the robot can be determined
in the following ways:
Alignment procedure Description
Alignment to physical base The equivalent to the fixture alignment in which the physical
base pins are measured and aligned with respect to the ref-
erence positions detailed in the product manual for the re-
spective robot.
Alignment to theoretical base Measuring several robot poses and letting the alignment
software determine the robot alignment.
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.
Purpose
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.
What is included
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
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 185.
2 Perform automatic tuning of the joint friction levels using the instructions
FricIdInit and FricIdEvaluate. See Automatic friction tuning on
page 181.
3 Compensate for the friction using 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 186.
• It is not possible to view any test signals with TuneMaster during automatic
friction tuning.
• The movement sequence between FricIdInit and FricIdEvaluate
cannot be longer than 10 seconds.
Note
To use Advanced Shape Tuning, the parameter Friction FFW On must be set to
TRUE.
Example
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;
IF DoTuning THEN
FricIdEvaluate FricLevels;
ENDIF
ENDPROC
Note
A real program would include deactivating the cutting equipment before the
tuning phase.
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,
Functions and Data types.
There are two tune types that are used expressly for Advanced Shape Tuning:
Tune type Description
TUNE_FRIC_LEV 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.
TUNE_FRIC_RAMP By calling the instruction TuneServo with the argument
TUNE_FRIC_RAMP the motor shaft speed at which full friction com-
pensation 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.
Action
4 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 186.
Illustration
en0900000117
Instructions
Instructions Description
FricIdInit Initiate friction identification
FricIdEvaluate Evaluate friction identification
FricIdSetFricLevels Set friction levels after friction identification
Functions
Advanced Shape Tuning includes no functions.
Data types
Advanced Shape Tuning includes no data types.
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.
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.
Continues on next page
188 Application manual - Controller software OmniCore
3HAC066554-001 Revision: J
© Copyright 2019-2022 ABB. All rights reserved.
3 Motion Performance
3.4.1 About Motion Process Mode
Continued
MotionProcessModeSet ACCURACY_MODE;
! 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
Note
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]
WARNING
Incorrect setting of the Motion Process Mode parameters can cause oscillating
movements or torques that can damage the robot.
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.
WARNING
Incorrect tuning for a very low mounting stiffness can cause oscillating
movements or torques that can damage the robot.
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
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.
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.
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.
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.
Continues on next page
198 Application manual - Controller software OmniCore
3HAC066554-001 Revision: J
© Copyright 2019-2022 ABB. All rights reserved.
3 Motion Performance
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 Descriptions
CirPathMode 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.
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;
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 202. 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;
! 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;
! Right semi-circle
MoveC Offs(pSlot, L+R, 0, 0), Offs(pSlot, L, R, 0), v50, z0, tLaser,
\wobj := wSlot;
wSlot
pSlot
xx0900000111
3.5.5 Troubleshooting
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.
4 Motion Supervision
4.1 World Zones [3106-1]
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.
What is included
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 209.
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).
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 byWZLimJointDef or WZHomeJointDef).
A variable of type wzstationary or wztemporary can not be redefined. They
can only be defined once (with WZLimSup or WZDOSet).
World Zones supervision is not accessible when lead-through is active.
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,
Functions and Data types.
Data type Description
wztemporary 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 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 - Om-
niCore.
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 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,
Functions and Data types.
Instruction Description
WZBoxDef 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 sys-
tem. 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 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 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).
Instruction Description
WZLimJointDef 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.
The definition is stored in a variable of type shapedata.
WZHomeJointDef 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.
The definition is stored in a variable of type shapedata.
WZLimSup 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 WZDOSet is used to define, and enable, setting a digital output signal
when the TCP reaches the world zone.
When callingWZDOSet 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 WZDisable is used to disable the supervision of a temporary world
zone.
WZEnable 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 WZFree is used to disable and erase a temporary world zone.
Functions
World Zones does not include any RAPID functions.
xx0300000178
xx0300000206
4.2.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
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.
What is included
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.
Note
If the tool data is wrong, false collisions might be triggered and the robot arm
might drop a short distance during the stop ramp.
4.2.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 - OmniCore.
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.
Overview
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.
Collision illustration
xx0300000361
en0300000360
Motion Supervision
These parameters belong to the type Motion Supervision in the topic Motion.
Parameter Description
Path Collision Detection Turn the collision detection On or Off for program execution.
Path Collision Detection is by default set to On.
Jog Collision Detection Turn the collision detection On or Off for jogging.
Jog Collision Detection is by default set to On.
Path Collision Detection Modifies the Collision Detection supervision level for program
Level execution by the specified percentage value. A large percent-
age 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 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.
Manipulator Supervision Modifies the supervision level for the loose arm detection for
Level 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 Description
Motion Supervision Max Set the maximum level to which the total collision detection
Level tune level can be changed. It is by default set to 300%.
Motion System
This parameter belongs to the type Motion System in the topic Motion.
Parameter Description
Ind collision stop without This parameter is only valid for systems using the MultiMove
brake option. If this parameter is set to TRUE, detected collisions will
be handled independently in RAPID tasks that are executed
independently.
A restart is required for this parameter to take effect.
General RAPID
These parameters belong to the type General RAPID in the topic Controller.
Parameter Description
Collision Error Handler 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
Instructions
This is a brief description of the instructions in Collision Detection. For more
information, see respective instruction in Technical reference manual - RAPID
Instructions, Functions and Data types.
Instruction Description
MotionSup 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.
4.2.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 Description
MotSupOn 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 is turned off, Mot-
SupOn is still high. When the robot starts to move, MotSupOn switches
to low.
Before the first Motors On order after a restart of the robot controller,
MotSupOn will reflect the value of the corresponding system parameter
Path Collision Detection:
• If Path Collision Detection is set to On, MotSupOn will be high.
• If Path Collision Detection is set to Off, MotSupOn will be low.
MotSupTrigg MotSupTrigg goes high when the collision detection triggers. It stays
high until the error code is acknowledged from the FlexPendant.
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.
Note
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%.
Reactivate supervision
If the supervision has been temporarily deactivated, it can be activated with the
following instruction:
MotionSup \On;
Note
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;
Actions to take
Introduction
The function Collision Avoidance monitors a detailed geometric model of the robot.
By defining additional geometrical models of bodies in the robot workarea, the
controller will warn about a predicted collision and stops the robot if two bodies
come too close to each other. The system parameter Coll-Pred Safety Distance
determines at what distance the two objects are considered to be in collision.
The function Collision Avoidance is useful for example when setting up and testing
programs, or for programs where positions are not static but created from sensors,
such as cameras (non-deterministic programs).
Besides the robot itself the function will monitor up 10 objects that is created via
the configurator in RobotStudio. Typical objects to be monitored are tool mounted
on the robot flange, additional equipment mounted on the robot arm (typically axis
3) or static volume around the robot.
The geometric models are set up in RobotStudio.
The functionality is activated by the system input Collision Avoidance. A high signal
will activate the functionality and a low signal will deactivate the functionality. The
functionality is by default active if no signal has been assigned to the system input
Collision Avoidance.
Collision Avoidance is active both during jogging and when running programs.
Also, the RAPID function IsCollFree provides a way to check possible collisions
before moving into a position.
CAUTION
Limitations
Paint robots, IRB 6620LX, and IRB 360 are not supported.
Collision Avoidance cannot be used in manual mode together with responsive
jogging. The system parameter Jog Mode must be changed to Standard.
The Collision Avoidance functionality between 2 robots (or more) can only be
achieved when using a MultiMove system.
CAUTION
Purpose
SafeMove Assistant is a functionality in RobotWare that helps users to program
their application when there is an active SafeMove configuration. The assistant
will read the active configuration and plan the trajectories according to the limits
and settings in that configuration. It will set the speed so that SafeMove will not
trigger violations etc. It will also stop with error message in case the robot is
programmed to enter a forbidden zone etc.
SafeMove Assistant will automatically adjust robot behavior to adopt to the active
SafeMove configuration, the robot will adopt to speed limited zones and stop before
entering forbidden zones.
Note
Description
SafeMove Assistant will check if any SafeMove speed limit is active for any
Cartesian speed checkpoint (TCP, tool points, and elbow). If this is the case, a
corresponding speed limit is applied in the path planner. For technical reasons,
only the speed of the TCP, the wrist center point (WCP), and the elbow are limited
by the path planner. Therefore, in cases where other tool points move faster than
the TCP, SafeMove may trigger a Tool Speed violation. To avoid this, change the
program or decrease the value of the parameter SafeMove assistance speed factor
(see below).
SafeMove Assistant is not active in manual mode.
SafeMove Assistant does not take path corrections generated at lower level into
account. It is therefore an increased risk of SafeMove violations when running
applications like Externally Guided Motion or conveyor tracking.
System parameters
SafeMove Assistant can be disabled for the SafeMove validation etc. This is done
with the parameter Disable SafeMove Assistance, in the type in Motion System.
There are some parameters that can be changed in case robot system has minor
overshoot or in any other way triggers SafeMove violations.
Parameter Description
SafeMove Assist- That has a default setting of 0.96 which corresponds to 96% of speed
ance Speed supervision will be the speed that path planner will use. This parameter
Factor can be decreased to reduce that risk but can in most cases be left at
default value.
SafeMove assist- When robot is running on a zone border there is a small risk that Safe-
ance zone mar- Move can trigger violations when going in and out of the zone. This
gin parameter can be increased to reduce that risk but can in most cases
be left at default value.
For more information, see the parameters in the type Motion System described in
Technical reference manual - System parameters.
5 Motor Control
5.1 Independent Axis [3111-1]
5.1.1 Overview
Purpose
The purpose of Independent Axis 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.
What is included
The RobotWare option Independent Axis 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 Code examples on page 233.
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.
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.
Internal and customer cabling and equipment may limit the ability to use
independent axis functionality on axis 4 and 6.
The option is not possible to use in combination with:
• SafeMove I
• Track Motion (IRBT)
• Positioners (IRBP) on Interchange axes
I Independent Axis can in some cases be combined with SafeMove2 if the additional axis does not
move the robot, and the additional axis is not monitored by SafeMove. Contact your local ABB
sales office team for additional information.
The following is deactivated when option Independent Axes is used:
• Collision detection
Note
Arm
These parameters belongs to the type Arm in the topic Motion.
Parameter Description
Independent Joint Flag that determines if independent mode is allowed for the axis.
Independent Upper Defines the upper limit of the working area for the joint when operating
Joint Bound in independent mode.
Independent Lower Defines the lower limit of the working area for the joint when operating
Joint Bound in independent mode.
Transmission
These parameters belong to the type Transmission in the topic Motion.
Parameter Description
Transmission Gear Independent Axes requires high resolution in transmission gear ratio,
High 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 See Transmission Gear High.
Low
Data types
There are no data types for Independent Axis.
Instructions
This is a brief description of each instruction in Independent Axis. For more
information, see respective instruction in Technical reference manual - RAPID
Instructions, Functions and Data types.
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 Description
IndAMove IndAMove (Independent Absolute position Movement) change an
axis to independent mode and move the axis to a specified position.
IndCMove IndCMove (Independent Continuous Movement) change an axis to
independent mode and start moving the axis continuously at a spe-
cified speed.
IndDMove IndDMove (Independent Delta position Movement) change an axis to
independent mode and move the axis a specified distance.
IndRMove IndRMove (Independent Relative position Movement) change a rota-
tional axis to independent mode and move the axis to a specific pos-
ition within one revolution.
Because the revolution information in the position is omitted,
IndRMove never rotates more than one axis revolution.
IndReset 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 Axis. For more
information, see respective function in Technical reference manual - RAPID
Instructions, Functions and Data types.
Function Description
IndInpos IndInposindicates whether an axis has reached the selected position.
IndSpeed IndSpeed indicates whether an axis has reached the selected speed.
Reset an axis
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.1.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.
What is included
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.
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,
Functions and Data types.
Data type Description
pathrecid 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
Instructions, Functions and Data types.
Instruction Description
StorePath StorePath is used to store the movement path being executed when
an error or interrupt occurs.
StorePath is included in RobotWare base.
RestoPath RestoPath is used to restore the path that was stored by StorePath.
RestoPath is included in RobotWare base.
PathRecStart PathRecStart is used to start recording the robot’s path. The path
recorder will store path information during execution of the robot
program.
PathRecStop PathRecStop is used to stop recording the robot's path.
PathRecMoveBwd PathRecMoveBwd is used to move the robot backwards along a recor-
ded path.
PathRecMoveFwd 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,
Functions and Data types.
Function Description
PathRecValidBwd PathRecValidBwd is used to check if the path recorder is active and
if a recorded backward path is available.
PathRecValidFwd 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.
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;
...
!Move the robot back to the stored position
MoveL p1, v100, fine, gun1;
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.
Continues on next page
Application manual - Controller software OmniCore 239
3HAC066554-001 Revision: J
© Copyright 2019-2022 ABB. All rights reserved.
6 RAPID Program Features
6.1.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;
MoveL p3, vmax, z50, tool1;
MoveL p4, vmax, fine, tool1;
PathRecStop \Clear;
MoveL p5, vmax, fine, tool1;
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;
MoveL p3, vmax, z50, tool1;
MoveL p4, vmax, fine, tool1;
StorePath;
PathRecMoveBwd \ID:=origin_id
\ToolOffs:=[0,0,10];
RestoPath;
PathRecStop \Clear;
Clear Path;
Start Move;
ERROR
StorePath;
IF choice=4 THEN
! Back up to p1
PathRecMoveBwd \ID:=origin_id
\ToolOffs:=[0,0,10];
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
\ToolOffs:=[0,0,10];
ENDIF
ENDIF
For more information, see the section about PathRecStop in Technical reference
manual - RAPID Instructions, Functions and Data types.
...
MoveL p1, vmax, z50, tool1;
PathRecStart id1;
MoveL p2, vmax, z50, tool1;
PathRecStop;
MoveL p3, vmax, z50, tool1;
MoveL p4, vmax, z50, tool1;
MoveL p2, vmax, z50, tool1;
PathRecStart id2;
MoveL p5, vmax, z50, tool1;
StorePath;
PathRecMoveBwd \ID:=id1;
RestoPath;
...
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.
What is included
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.
• The instruction: WaitSyncTask.
• The functions: TestAndSet, TaskRunMec, and TaskRunRob.
Continues on next page
Application manual - Controller software OmniCore 243
3HAC066554-001 Revision: J
© Copyright 2019-2022 ABB. All rights reserved.
6 RAPID Program Features
6.2.1 Introduction to Multitasking
Continued
Note
Basic approach
This is the basic approach for setting up Multitasking. For more information,
seeRAPID components on page 247.
1 Define the tasks you need.
2 Write RAPID code for each task.
3 Specify which modules to load in each task.
Task
These parameters belongs to the type Task in the topic Controller.
Parameter Description
Task 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.
Task in fore- Used to set priorities between tasks.
ground 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.
Type Controls the start/stop and system restart behavior:
• Normal (NORMAL) - The task program is manually started and
stopped (e.g. from the FlexPendant). The task stops at emergency
stop.
• Static (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 (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.
Main entry The name of the start routine for the task program.
Check unre- This parameter should be set to NO if the system is to accept unsolved
solved refer- references in the program while linking a module, otherwise set to YES.
ences
TrustLevel 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 pos-
sible). No jogging or program start can be made. A restart is re-
quired.
• 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.
Parameter Description
MotionTask 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 Mul-
tiMove 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,
Functions and Data types.
Data type Description
taskid 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 258.
syncident 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 pro-
grams.
For code example, see WaitSyncTask example on page 252.
tasks A variable of the data type tasks contains names of the tasks that will
be synchronized by the instruction WaitSyncTask.
For code example, see WaitSyncTask example on page 252.
Instructions
This is a brief description of each instruction in Multitasking. For more information,
see the respective instruction in Technical reference manual - RAPID Instructions,
Functions and Data types.
Instruction Description
WaitSyncTask 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.
For code example, seeWaitSyncTask example on page 252.
Functions
This is a brief description of each function in Multitasking. For more information,
see the respective function in Technical reference manual - RAPID Instructions,
Functions and Data types.
Function Description
TestAndSet 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 re-
source.
For code example, seeExample with flag and TestAndSet on page 256.
TaskRunMec Check if the task program controls any mechanical unit (robot or other
unit).
For code example, seeTest if task controls mechanical unit on page 257.
TaskRunRob Check if the task program controls any robot with TCP.
For code example, seeTest if task controls mechanical unit on page 257.
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.
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
Main task program:
MODULE module1
PERS bool startsync:=FALSE;
PROC main()
startsync:= TRUE;
...
ENDPROC
ENDMODULE
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.
Interrupt example
Main task program:
MODULE module1
PROC main()
SetDO do1,1;
...
ENDPROC
ENDMODULE
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
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.
Main task program:
MODULE module1
PERS pos object_position:=[0,0,0];
PERS tasks task_list{2} := [["MAIN"], ["BACK1"]];
VAR syncident sync1;
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 main()
WHILE TRUE DO
!Call routine to calculate object_position
calculate_position;
PROC calculate_position()
...
object_position:= ...
ENDPROC
ENDMODULE
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.
Main task program:
MODULE module1
PERS string routine_string:="";
PROC main()
!Call clean_gun in background task
routine_string:="clean_gun";
SetDO do5,1;
WaitDO do5,0;
PROC main()
WaitDO do5,1;
%routine_string%;
SetDO do5,0;
ENDPROC
PROC clean_gun()
...
ENDPROC
PROC routine1()
...
ENDPROC
ENDMODULE
Note
For a task to have control of a robot, the parameter Type must be set to normal,
and the type MotionTask must be set to YES. See System parameters on page 245.
6.2.5.3 taskid
taskid syntax
A task always has a predefined variable of type taskid that consists of the name
of the task and the suffix "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";
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.
7 Communication
7.1 FTP&SFTP client [3116-1]
Purpose
The purpose of FTP&SFTP Client is to enable the robot to access remote mounted
disks, for example a hard disk drive on a PC.
Here are some examples of applications:
• Backup to a remote computer.
• Load programs from a remote computer.
Network illustration
External computer
Ethernet TCP/IP
xx1900001202
Description
Several robots can access the same computer over an Ethernet network.
Once the FTP/SFTP protocol is configured, the remote computer can be accessed
in the same way as the controller's internal hard disk.
What is included
The RobotWare option FTP&SFTP client gives you access to the system parameter
types FTP Client and SFTP Client.
Basic approach
This is the general approach for using FTP&SFTP client.
1 Configure an FTP/SFTP 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.
SFTP supports the following servers:
• Rebex version 1.0.3
Requirements
The external computer must have:
• TCP/IP stack
• FTP Server or SFTP Server
Tip
For Internet Information Services (IIS) in Windows, the directory listing style is
configurable.
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.
• When using the SFTP Client the maximum length for a file path including the
file name is 248 characters. The whole path is included in the 248 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 FTP
Parameter Value
Name myFTP
Server path C:\robot_1
Example SFTP
Parameter Value
Name mySFTP
System parameters
See Technical reference manual - System parameters.
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.
Here are some examples of applications:
• Backup to a remote computer.
• Load programs from a remote computer.
Description
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.
What is included
The RobotWare option NFS Client gives you access to the system parameter type
Application protocol and its parameters: Name, Type, Transmission protocol, Server
address, Server type, Trusted, Local path, Server path, User ID, Group ID, and
Show Device.
Basic approach
This is the general approach for using NFS Client.
1 Configure an NFS 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
The external computer must have:
• TCP/IP stack
• NFS Server
Limitations
When using the NFS Client the maximum length for a file path including the file
name is 248 characters. The whole path is included in the 248 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 Value
Name myNFS
Server path C:\robot_1
Overview
RobotStudio is the programming, configuration and commissioning tool for
OmniCore controllers. RobotStudio acts directly on the active data in the controller
and enables activities like RAPID programming, update/booting of the systems
software and system configuration. Connecting RobotStudio directly to the local
management port is enabled by default, but connecting RobotStudio over a public
network requires this option RobotStudio Connect.
9 Engineering tools
9.1 RobotWare Add-In
9.2.1 Overview
Purpose
The purpose of Path Corrections is to be able to make online adjustments of the
robot path according to input from sensors. With the set of instructions that Path
Corrections offers, the robot path can be compared and adjusted with the input
from sensors.
What is included
The RobotWare option Path Corrections 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 Corrections. For a detailed example
of how this is done, see Code example on page 276.
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
The instruction CorrWrite is intended with low speed and moderate values of
correction. Too aggressive values will be clamped. The correction values should
be tested in RobotStudio to confirm the performance.
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 the option Path Corrections. For
more information, see the respective data type in Technical reference
manual - RAPID Instructions, Functions and Data types.
Data type Description
corrdescr 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 the option Path Corrections. For
more information, see the respective instruction in Technical reference
manual - RAPID Instructions, Functions and Data types.
Instruction Description
CorrCon 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 CorrDiscon deactivates path correction. Calling CorrDiscon will
disconnect a correction generator.
CorrClear CorrClear deactivate path correction. Calling CorrClear will dis-
connect all correction generators.
CorrWrite 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 the option Path Corrections. For more
information, see the respective function in Technical reference manual - RAPID
Instructions, Functions and Data types.
Function Description
CorrRead CorrRead reads the total correction made by a correction generator.
Interrupts
To create programs using Path Corrections, you need to be able to handle
interrupts. For more information on interrupts, see Technical reference manual -
RAPID Overview.
Program code
VAR intnum int_no1;
VAR corrdescr id;
VAR pos sens_val;
PROC PathRoutine()
!Connect to the correction generator
CorrCon id;
!Execute correction
CorrWrite id, sens_val;
Description
The RobotWare base functionality Auto Acknowledge Input is an option that enables
a system input which will acknowledge the dialog presented on the FlexPendant
when switching the operator mode from 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.
B D
binary communication, 117 data, 141
binary data, 153 datapos, 22
birth certificate, Absolute Accuracy, 172 data search functionality, 21
BitAnd, 19 data types
BitCheck, 19 Multitasking, 247
BitClear, 19 deactivate supervision, 223
bit functionality, 18 declarations, 249
BitLSh, 19 deflection, 168
BitNeg, 19 digital I/O signals, 135
BitOr, 19 dir, 126
BitRSh, 19 directory management, 125
BitSet, 19 discarded message, 143
BitXOr, 19 dispatcher, 254
BookErrNo, 41
byte, 19
E
errdomain, 38
ByteToStr, 19
error interrupts, 37
C error sources in accuracy, 167
calibrate tool, 178 ErrRaise, 38
calibration data, 162 errtype, 38
calibration process, 170 Ethernet, 261, 264
calibration tools, 161 event messages, 40
CalibWare, 161 event number, 40
cell alignment, 174 Event Preset Time, 132
certificate, Absolute Accuary, 172 external axes, 213
change calibration data, 162 external axis, 229
character based communication, 117
Check unresolved references, Task type, 245
F
fake target, 168
CirPathMode, 200
false triggering, 224
ClearRawBytes, 122
Fieldbus Command Interface, 112
Close, 118
FIFO, 142
CloseDir, 126
file communication, 116
collision, 214
file management, 125
Collision Avoidance, 225
FileSize, 126
collision detection
file structures, 125
YuMi robots, 212
fixed position events, 129
ABB AS
Robotics & Discrete Automation
Nordlysvegen 7, N-4340 BRYNE, Norway
Box 265, N-4349 BRYNE, Norway
Telephone: +47 22 87 2000
ABB Inc.
Robotics & Discrete Automation
1250 Brown Road
Auburn Hills, MI 48326
USA
Telephone: +1 248 391 9000
abb.com/robotics
3HAC066554-001, Rev J, en