Ngon Ngu Lap Trinh RBCN

Industrial Robot Language - IRL (DIN 66312) Page 1 of 126
COSIMIR® · Programming Language IRL

Industrial Robot Language

- IRL (DIN 66312)
This is preliminary documentation. Some of the
Elements, that are not supported by COSIMIR or
PCROB (due to the used IRL compiler) are marked
with the symbol preceding this line.
DIN 66312 describes the common construction of a

higher programming language for industrial robots (IRL =
Industrial Robot Language). It defines the syntax and
the semantics of IRL. IRL allows the user of this standard
to program the movement of the robot and the logical
program flow in an user oriented form. An IRL program
can be transfered into an ICR (Intermediate Code for
Robots) or IRDATA (DIN 66314) representation by an
appropriate compiler.
See also
Programs and Program Parts
Declaration Parts
Procedures
Functions
Predefined Functions
Data Lists
System Specification
System Constants and System Variables
IRL Language Description
Definition Conventions
Symbols and Identifiers
Predefined Identifiers
file://C:\Documents and Settings\Owner\Local Settings\Temp\~hh7635.htm 25/03/2009

Standard Data Types
User Defined Data Types
Geometric Data Types
Movement Statements
Program Flow Statements
I/O Statements
Parallel Process Statements
©·2000·IRF·EFR·Dortmund

IRL Language Description
Lexical Elements
The syntax in this section describes the formation of

lexical elements out of characters and the separation of
these elements from each other. Therefore, the syntax
is not of the same kind as that used in the rest of this
standard.
General Remarks
The lexical elements of an IRL program are:
- Word symbols
- Identifiers
- Predefined Identifiers
- Characterstrings
- Numbers
Character Set
The character set is taken from the ISO 646 (7 bits

coded character set for information processing

interchange) in its current edition.
Letters
Letter =
"a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" |
"l" | "m" |
"n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
"y" | "z" |
"A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" |
"L" | "M" |
"N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X"
| "Y" | "Z" |
"_".
Outside of strings the case is ignored.
Example:
The identifiers HOME, Home, hOme are equivalent.
Digits
Digit =
"0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9".
See also


Definition Conventions
The meta language used to describe the syntax of IRL in

this standard is based on the Backus Naur Form (BNF).
The notation was changed and extended to accomplish
an easy description and to convert recursive productions
into iterative ones. For the definition of the syntax of
the IRL language in this standard, the meta symbols
according to the following are used.
meta symboldescription
=defined as

|alternative
.end of definition
[x]no or one appearance of x
{x}no, one or multiple appearance of x
(x|y)select x or y
"xyz"terminal symbol xyz
Identifiernonterminal symbol
Example:
RealConstant =
DecimalConstant Exponent |
DecimalConstant "." { Digit } [ Exponent ] |
"." DecimalConstant [ Exponent ].
DecimalConstant, Digit and Exponent are nonterminal

symbols.
"." is a terminal symbol.


Programs and Program Parts

Program =
ProgramHead
SystemSpecification
ProgramDeclarationPart
RoutineList
[ "BEGIN" StatementBlock ]
"ENDPROGRAM" [ ";" ].
ProgramHead =
"PROGRAM" ProgramIdentifier ";" CompilerDirective.
RoutineList =
{
ProcedureDeclaration [ ";" ] |
ExternalProcedureDeclaration ";" |

FunctionDeclaration [ ";" ] |
ExternalFunctionDeclaration ";" |
ProcessDeclaration [";"]
}.
An IRL program consists of a program declaration part

and a statement part. The declarations may include
initialization of variable values and declaration of
functions and procedures including externals. The
values of declared teach / permanent variables will be
taken from the associated data list(s). After starting a
program all global initializations are executed, then the
statements in the statement part are executed using the
declared functions and procedures.
The program declaration part or the statement part can

be empty. The latter is only useful in connection with
an Export Declaration.
Example:
PROGRAM test;
{ procedures "moveto" and "operation" for testing}
PROCEDURE moveto ();
BEGIN
{ procedure statements }
ENDPROC;{ end procedure "moveto" }
PROCEDURE operation ();
BEGIN
{ procedure statements }
ENDPROC;{ end procedure "operation" }
BEGIN
operation();{ test of procedure "operation" }
moveto();{ test procedure "moveto" }
WRITELN('end of test');
ENDPROGRAM;
Programs can refer to a specification part which

contains system data.


Import- and Export Declarations
ImportDeclaration =
"FROM" ProgramIdentifier "IMPORT"
( "ALL" | ImportIdList ) ";".
ImportIdList =
Identifier { "," Identifier }.
ExportDeclaration =
"EXPORT"
( "ALL" | ExportIdList )
[ "TO" ProgramIdList ] ";".
ExportIdList =
ProgramIdList =
ProgramIdentifier { "," ProgramIdentifier }.
Import- and export declarations introduce the objects of

a program to/from other programs or program parts.
Nested objects can only be imported or exported
entirely.
An import declaration defines the program name from

which the objects specified in the name list are taken.
If ALL is specified all objects of that program are
imported.
An import declaration or an export declaration is only

allowed in the program declaration part of a program.
Example:
PROGRAM discharge;
FROM magazin IMPORT ALL;
{ all objects of program "magazin" can be imported }

FROM parts IMPORT start,partnumber;
{ two objects of "parts" }
FROM seek IMPORT x;
{ write "x" in every statement }
EXPORT f1;
{ "f1" exported }
EXPORT discharge_x TO charge;
{ "discharge_x" exported to "charge"}
VAR { Declarations of program "discharge": }
POSE: f1;
INT: i,discharge_x;
PROCEDURE schedule();
VAR INT: local_x;
BEGIN
local_x := 3;{ assignment to local "x" }
x := 17;{ assignment to "x" in program "seek" }
ENDPROC;
BEGIN
discharge_x := 99;
{ assignment to "x" of program "discharge" }
MOVE PTP mag1;
{ "mag1" of program "magazin" }
x := 0;
{ assignment to "x" in program "seek" }
schedule();
{ overwriting of "x" in program "seek" by "schedule()" }

WRITE(x);
ENDPROGRAM.
Modular Programming and Testing
With IRL it is possible to divide programs into program

parts which can be coded, compiled and tested
separately. Afterwards it is possible to link the different
parts into a complete program.
The same parts may be used in different programs.
Example:
PROGRAM dummy;
FROM test IMPORT operation;
BEGIN
{ ... }
operation();
{ ... }
ENDPROGRAM;

Declaration Parts
INTERRUPT, STANDARD_IN and STANDARD_OUT

are currently not supported in COSIMIR and PCROB.
ProgramDeclarationPart =
{
DeclarationPart |
ImportDeclaration |
ExportDeclaration |
DataListSpecification |
RobotSpecification |
"INTERRUPT" { InterruptDeclaration } |

"STANDARD_IN" ":=" Identifier ";" |

"STANDARD_OUT" ":=" Identifier ";"
}.
The program declaration part contains a usual

declaration part with global definitions and declarations
as well as program specific declarations, that are not
allowed as part of function or procedure declaration.
The declaration part consists of definitions of constants,

declarations of types and declaration of variables
including signals and channels. In addition to the
program declaration part any function or procedure
declaration may contain such a declaration part for
local definitions and declarations.
DeclarationPart =
(
"CONST" { ConstantDefinition } |
"TYPE" { TypeDeclaration } |
"VAR" { VariableDeclaration }
)
{
"CONST" { ConstantDefinition } |
"TYPE" { TypeDeclaration } |
"VAR" { VariableDeclaration }
}.
STANDARD_IN and STANDARD_OUT define the file or

channel used by input or output statements as default.

Constant Definition
Constant Definition
ConstantDefiniton =
TeachConstantDefinition | UsualConstantDefinition.
Usual Constant Definition
The constant definition introduces a constant name

which represents a fixed value.
UsualConstantDefinition =

Type ":" ConstantIdList ":=" Expression ";".
ConstantIdList =
ConstantIdentifier { "," ConstantIdentifier }.
Expression and Type must be of same data type.
Example:
REAL : pi := 3.1415926;
Teach Constant Definition
TeachConstantDefinition =
TeachType ":" TeachConstantIdList ";".
TeachConstantIdList =
TeachConstantIdentifier
{ "," TeachConstantIdentifier }.
The values of Teach Constants are taken from a data list

file. The constants are set to an "undef"-state unless a
data list file is specified which contains these constants.
Any application of an "undef" constant will cause a run
time error.
Each Teach Constant is of global scope and there is no

local Teach Constant Definition allowed.

Formal Parameters
FormalParameter =
[ "IN" | "OUT" | "INOUT" ] ParameterSpecification
{ ";"
[ "IN" | "OUT" | "INOUT" ] ParameterSpecification
}.
ParameterSpecification =
ParameterType ":" ParameterIdList |
ConformantScheme ":" Identifier.
ParameterType =
Type |

TeachType |
SignalType |
SemaphoreType .
ParameterIdList =
ConformantScheme =
"ARRAY" "[" IndexTypeSpecList "]" "OF" Type.
IndexTypeSpecList =
IndexTypeSpecification { "," IndexTypeSpecification }.
IndexTypeSpecification =
TypeIdentifier ":"
ConformantParameter ".." ConformantParameter.
ConformantParameter = Identifier.
If the class of the parameter specified by IN, OUT,

INOUT is missing this parameter is an INOUT parameter.
Three mechanisms for passing parameters are possible:
'call by reference': Pointers to the parameters are

passed.
Every change of the value within the called procedure

or function causes a change of the variable of the
calling program. This passing mechanism is used for
output parameters (OUT) and in/output parameters
(INOUT).
The numbers of actual and formal parameters have to

be identical and the data types have to be parameter
compatible. Passing of arrays see below.
Note:
An output parameter (OUT) is not readable.
'call by value': The values of the parameters are

passed.
A change of the value of a parameter in the called

procedure or function has no effect on the value of the
parameter in the calling program. Results cannot be
returned by this method. This passing mechanism is for
input parameters (IN).
The numbers of actual and formal parameters have to

be identical and the data types have to be assignment

compatible.
'conformant scheme': The purpose of the (formal)

conformant parameters is to provide a possibility of
working with array parameters of unknown size but
known type. During the execution of the procedure or
function, the statements of the first and second
conformant scheme parameters represent the lower and
upper limit value of the corresponding actual
parameter.
Index type specification must be INT or CHAR.
Note:
Array parameters can also be declared using array data

type instead of a conformant scheme for instance, e.g.:
PROCEDURE test(INOUT array_type1: test_array);
parameter compatibility:
The data types of the corresponding actual and formal

parameter are parameter compatible:
-if both types are simple or standard types and if they

have the same name of data type.
-if both types are ARRAY types and if they are either of
the same type or in the case of a formal conformant
scheme if the numbers of dimensions are identical and
the types of the elements are assignment compatible
for input parameters (call by value) and parameter
compatible for in/output and output parameters (call by
reference). And if the indices are assignment
compatible in any case.
-if both types are LIST types and if there elements are
paramater compatible.
-if both types are RECORD types, if all components of

the records are parameter compatible two by two.
Exception: The predefined data types POSITION and

ORIENTATION are not parameter compatible.
-if both types are FILE types and if the types of

elements are parameter compatible.
-if both types are TEACH types and if the proper types
of these teach types are parameter compatible.

-if both types are INPUT types and if the types of these
signal types are parameter compatible.
-if both types are OUTPUT types and if the types of

these signal types are parameter compatible.
Example:
PROGRAM test;
TYPE
ARRAY [4..20] OF REAL = array_type1;
ARRAY [1..10] OF REAL = array_type2;
VAR
array_type1: f1;
array_type2: f2;
PROCEDURE init (INOUT ARRAY [INT:

lowindex..highindex] OF REAL: proc_array);
VAR INT: i;
BEGIN
FOR i:=lowindex TO highindex
proc_array [i] := 10.0;
ENDFOR;
ENDPROC;
BEGIN
init (f1);
init (f2);
ENDPROGRAM {test};


Constants
RSXYZYXZ
ZYZ2ZYXVANG
QUAT
Integer Constants
IntegerConstant =
DecimalConstant |
BinaryConstant |
OctalConstant |
HexadecimalConstant.
DecimalConstant:
A decimal constant consists of a sequence of digits. It is

of type "INT" (Integer) and interpreted as decimal.
DecimalConstant =
Digit { Digit }.
A decimal constant is unsigned and it is positive.

Negative constants are built with Expression.
The maximum number of digits is limited by the range

of the integer data type.
Note:
The number of digits depends on the implementation;

for constant computation the compiler shall use always
at least 32 bit.
BinaryConstant:
The following notation stands for the constant which is

interpreted to base 2:
BinaryConstant =
"2#" ( "0" | "1" | "_" )
{ "0" | "1" | "_" }.
The symbol "2#" can be followed by the digits 0 or 1 or

by underlines. The maximum number of digits is limited
by the range of the integer data type. The last digit is
the least significant one.

OctalConstant:
The following definition stands for the constant which is

interpreted to base 8:
OctalConstant =
"8#" ( "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "_" )
{ "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "_" }.
The symbol "8#" can be followed by the digits 0 to 7 or

by underlines. The maximum number of digits is limited
by the range of the integer data type. The last digit is
the least significant one.
HexadecimalConstant:
Constants can also be hexadecimal which means that

they are interpreted to base 16. The letters A to F
correspond to the decimal values 10 to 15.
HexadecimalConstant =
"16#" ( Digit | "A" | "B" | "C" | "D" | "E" | "F" | "_" )
{ Digit | "A" | "B" | "C" | "D" | "E" | "F" | "_" }.
The symbol "16#" may be followed by hexadecimal

characters or by underlines. The maximum number of
the hexadecimal characters is limited by the range of
the integer data type. The character which is positioned
on the farest right side has the least significance.
Note:
The character '_' in non decimal integer constants serves

only to format the constant for human convenience.
Real Constants
RealConstant =
DecimalConstant Exponent |
DecimalConstant "." { Digit } [ Exponent ] |
"." DecimalConstant [ Exponent ].
Exponent =
( "E" | "e" ) ["+" | "-"] DecimalConstant.
A real constant is unsigned and it is positive. Negative

constants are built with Expression.
Example:
5.

100.07
.3
23.4E5
10.2E-3
Characters and Strings
CharacterString =
"'" { Any-Character-Except-"'" | "''" } "'".
All characters of the character set are permitted.
A CharacterString which consists of one character only is

of type CHAR and is called a character constant.
A CharacterString with more than one character is of

type STRING and is called a string constant. The
maximum length of a string constant should be
restricted to 255.
Note:
To include a quote mark (character ') in a

CharacterString, it has to be written twice.
Example:
'alarm'
'abc''def'
Record Constants
CallOrRecord =
Object "(" [ ValueList ] ")".
ValueList =
Expression { "," Expression }.
Every Expression in ValueList represents the value of a

record component. The number and the sequence of
components is fixed by the type declaration.
Object describes the type of the record constant. This

information is optional.
Example:
POSITION( 17.2, -20.4, 33.4 )

In the case of nested records the component value is

again a record constant.
Example :
JOINT (MAIN_JOINT( 10.2, -220.4, 135.5, -90.0, 0.0,

90.0 ),
ADD_JOINT( -90.0 ) )
Boolean Constants
BooleanConstant = "TRUE" | "FALSE".
Boolean constants can only be true (<>0) or false (0).

They are represented by the word symbols TRUE or
FALSE, respectively.
Range of Value
The minimum range of the integer data type is:
-2147483647 to +2147483647 (32 bits)
The minimum range of the real data type is (32 bits):
-1.7 E38 to -1.7 E-38
1.7 E-38 to 1.7 E38
and 'TrueZero'
The accuracy is not fixed.
Note:
For calculation of constant expressions the compiler

always works with a precision of 32 bits.
The range of the boolean data type is true (<>0) and

false (0).
These values represent a minimum demand for an IRL

implementation.


Procedures
IRL Procedures
A procedure call is a statement. Therefore a given

ReturnStatement does not have a value.
ProcedureDeclaration =
"PROCEDURE" ProcedureIdentifier
"(" [ FormalParameter ] ")" ";"
[ DeclarationPart ] "BEGIN" StatementBlock "ENDPROC".
External Procedures
External procedures are currently not supported

in COSIMIR and PCROB. Similar functionality can be
achieved using inline IRDATA code in IRL procedures.
Unlike IRL procedures the body of external procedures is

not defined within the IRL program but, for example, in
the robot control system. The
ExternalProcedureDeclaration offers the possibility to
extend the scope of IRL in accordance with the features
of the robot control system or additional equipment in
use. An ExternalProcedureDeclaration is allowed in the
SystemSpecification only.
ExternalProcedureDeclaration =
"EXTERNALPROCEDURE" ProcedureIdentifier
"(" [ FormalParameter ] ")".
Such external procedures may be used for instance to

process specific sensor data.

Functions
IRL Functions
Unlike procedures, functions return a value and can

therefore be used in expressions like variables.

FunctionDeclaration =
"FUNCTION" FunctionIdentifier
"(" [ FormalParameter ] ")" ":" PredefinedType ";"
[ DeclarationPart ] "BEGIN" StatementBlock "ENDFCT".
The data type of the function value is defined with the

Type. Function values must have a predefined but not
robot specification type.
A function is left by the return statement. The value of

the expression in this statement is passed to the calling
program as the result value.
Example: (signum function)
FUNCTION sign (IN REAL: x ): INT;
{declaration part}
BEGIN
{statements}
IF x>0.0 THEN
RETURN 1;
ENDIF;
IF x<0.0 THEN
RETURN -1;
ENDIF;
RETURN 0;
ENDFCT;
External Functions
External functions are currently not supported

in COSIMIR and PCROB. Similar functionality can be
achieved using inline IRDATA code in IRL functions.
The ExternalFunctionDeclaration corresponds with the

ExternalProcedureDeclaration. An
ExternalFunctionDeclaration is allowed in the
SystemSpecification only.
ExternalFunctionDeclaration =

"EXTERNALFUNCTION" FunctionIdentifier
"(" [ FormalParameter ] ")" ":" PredefinedType.
Such external functions may be used for instance to

process specific sensor data.

Predefined Functions
ABS ACOSANGLEX
ANGLEYANGLEZANGLEZ2
APPENDCASINATAN2
CHRCOMPARECONCATS
COSCROSSDELETEC
DOTEOFEOL
EXTRACTSFLOATGETCHR
INVLENGTHLOCATE
ORDORIQUATORIRS
ORIVANGORIXYZORIYXZ
ORIZYXORIZYZ2QUATA
QUATBQUATCQUATD
ROTANGLEROTAXISROUND
SETCHRSINSIZE
SQRTTANTRAFO
TRAFOINVTRUNC


Parallel Processes
IRL allows the definition and use of processes that are

executed in parallel with other processes defined within
the program. This for example enables the programmer
to write a main program moving the robot and a second
process, simultaneously reading data from an intelligent
sensor and changing the path of the robot depending on
this data. In addition to these parallel processes,
defined, started and stopped within an IRL-program the
controller may allow the execution of several programs
or tasks on a higher level. Those programs can probably
be started or stopped independently by the user. How
the controller handles the execution and control of
these programs is not part of this standard. IRL does not
provide elements to allow access for one program to
variables of another independent program and vice
versa. IRL does offer functions to handle the
communication of and to share variables between
processes started within an IRL program. Thus,
dependent processes or processes which have to share
data must be defined and started/stopped within one
IRL program. To keep the complexity of the language as
low as possible the instruction set for parallel processing
is quite small. Nevertheless it offers all necessary
features to make use of parallel processing in robot
applications.
One problem to be solved in connection with parallel

processes is the access to shared variables. The parallel
writing or reading of shared variables (variables that can
be accessed by several parallel processes) has to be
prevented. Therefore parallel processes in IRL can only
access variables explicitly defined as SHARED. The
access has to be announced to the control by the LOCK
and UNLOCK statements. When a process has locked a
shared variable (that means it has gained access to this
variable) no other process can read or write this
variable until the process has unlocked the variable
again. The other processes trying to get access to this
variable (by a LOCK statement) are stopped until the
variable is unlocked. If more than one process wants to
read or write a shared variable the processes are served
in the order they claimed the access.
In contrary to just using semaphores for the protection

of variables against multiple access this method is safer,

because it forces the user to claim access to shared
variables. So multiple access to the same variable is not
possible as it would produce a runtime error.
Additionally no special semaphore variables have to be
defined by the user.
Another problem concerning parallel processes is their

synchronization. For this purpose Semaphores are used
in IRL.
Definition of parallel processes
ProcessDeclaration =
"PROCESS" ProcessIdentifier
"(" [ FormalParameter ] ")" [ IntegerConstant ] ";"
DeclarationPart "BEGIN" StatementBlock "ENDPROCESS".
A parallel process is defined like a procedure. The only

difference is that the keyword PROCEDURE is
substituted by the keyword PROCESS and only formal
parameters of class "IN" are allowed. Additionally an
optional parameter can be specified. This optional
parameter must be an IntegerConstant between 0 and
255. It defines the priority of the process, from lowest
priority (0) to highest priority (255). This priority of
processes cannot be compared to the priority of
interrupts. How the control handles processes with
different priorities has to be defined in its users manual.
Processes are terminated by executing a
ReturnStatement or by reaching the ENDPROCESS
keyword at the end of the process declaration.

Data Lists
The IRL data lists are synonymous for the

COSIMIR position lists. All COSIMIR positions lists can
directly be used as IRL data lists. The following table
lists the correspondence between the position list
entry types and the IRL data types.
Position typeIRL data type

World Coordinates+ConfigurationROBTARGET
World CoordinatesPOSE
MRL 5-axis coordinates
Joint CoordinatesMAIN_JOINT
Add. AxisADD_JOINT
BooleanBOOL
IntegerINT
RealREAL
Position without OrientationPOSITION
TextSTRING
Data lists are files which contain names and values of

PERMANENT and TEACH data objects. All predefined
data types including those which are declared by the
System Specification file and arrays or lists of these
types are applicable. They are administrated by the
robot controller and are independent of IRL programs or
IRL program execution. There is only one instance of
such a variable, i. e. the alteration of a PERMANENT (or
TEACH) variable by a program will persist after program
termination.
Every program is associated with its default data list

(which owns the name of the program). In case of
"DECLOFF" the IMPORT DATALIST statement is optional
for this data list. Any number of additional data lists
may be used one after another.
The identification between the IRL data objects and the

data list elements is done by their names. The IMPORT
DATALIST statement associates the given data list to the
program and all following PERMANENT (or TEACH)
declarations cause an initialization trial from that data
list until a new IMPORT DATALIST statement is
encountered. lf no IMPORT DATALIST statement is given,
the default data list is used. If the name of a
PERMANENT (or TEACH) data object is not found in the
actual data list it is added there and set to an "undef"-
state. lf the types of the data objects within the data
list and within the program are not identical they are
checked as follows:
- TEACH constants:The data list object should be

assignment compatible to the constant.
- TEACH variables:They should be assignment

compatible in both directions.
If the result is positive the initialization is done and a

warning is given to the user indicating the type
conversion performed. If the result is negative no
initialization is done and a runtime error occurs.
The DataList Specification which is not allowed within

the declaration part of a procedure or function is as
follows:
DataListSpecification =
"IMPORT" "DATALIST" Expression ";".
The Expression describes path and filename. Therefore

expression has to be of type ARRAY OF CHAR or STRING.
Note:
It is recommended that the compiler may be told e.g.

by a switch to extract all TEACH or PERMANENT objects
declared within a program to a new or existing data list
file. Tools should be available to fill, extract, change
and update data lists by means of Teach-In methods,
editing or printing. Crossreferences between program(s)
and data list(s) should also be possible. A time stamp
with at least the creation date and the date of last
modification may also be useful for every item within a
data list.

System Specification
When compiling and linking programs in COSIMIR

use of predefined system specifications is
recommended. These predefined system
specifications are installed as SYSTEM.IRL and
SYSTEM.ROB (compiled format) in the subdirectories
IRL4AXIS, IRL5AXIS and IRL6AXIS of the COSIMIR
installation directory. These system spefications are
used for robots with 4, 5, or 6 axes (joints) if the

option "Use Joint Count for Include Path" in the dialog

box "Compiler Settings" is checked.
To use a system specification of your own (required

for robots with additional axes), uncheck this option,
make a copy of an appropriate system specification
(SYSTEM.IRL) into the current directory and modify it.
Then compile it (Command "Execute/Compile") to
SYSTEM.ROB. Afterwards your IRL programs in the
current directory will use this new system
specification.
The system specification used in COSIMIR has

some extensions to the standardized system
specification. Furthermore it is used to implement
several of the predefined functions.
The System Specification is stored by the producer of

the robot controller in a special file. The file contains
system data, for example the declaration of data types
for the robot configuration. This way it is possible to
adapt IRL for different applications and systems.
A default System Specification exists which contains a

minimum of data types.
SystemSpecification=
[ "SYSTEM_SPECIFICATION" Expression ";" ].
The Expression describes path and filename. Therefore

expression has to be of type ARRAY OF CHAR or STRING.
The System Specification file has to contain the

following declarations:
CONST
INT: R_NTURNS := 2;
{ maximum number of joints in a cell which can rotate
more than 360 degrees }
INT: R_NADDJ := 1;
{ maximum number of additional joints in a cell; see
type ADD_JOINT }
INT: R_NJ := 7;
{number of joints; must correspond with type JOINT}
{ The different ways to define Orientations }
STRING : RS := 'RS';

STRING : XYZ := 'XYZ';
STRING : YXZ := 'YXZ';
STRING : ZYX := 'ZYX';
STRING : ZYZ2 := 'ZYZ2';
STRING : VANG := 'VANG';
STRING : QUAT := 'QUAT';
{ Total number of devices }
INT :R_DEVICE_NUMBER := 4;
{ The next 5 definitions are used for D_AXES_TYPE in

D_SPEC_TYPE }
INT :AX_NONE := -1; { No device }
INT :AX_MAIN := 0; { Main axes (robot) }
INT :ADAX_IS := 1; { Additional axes starting the

kinematical chain; e.g. a rail }
INT :ADAX_IE := 2; { Additional axes ending the

kinematical chain }
INT :ADAX_EX := 3; { External additional axes; e.g. a

positioner }
{ The following 4 values are returned by GETSTATUS

(...) }
INT :R_PROCESS_READY := 0;
INT :R_PROCESS_RUNNING := 1;
INT :R_PROCESS_STOPPED := 2;
INT :R_PROCESS_BLOCKED := 3;
TYPE
RECORD REAL: lower, upper; ENDRECORD = BOUNDS;
RECORD
REAL: A1, A2, A3, A4, A5, A6;

{the number of joints can be six or smaller}

ENDRECORD = MAIN_JOINT;
RECORD
REAL: AA1;
ENDRECORD = ADD_JOINT;
RECORD
MAIN_JOINT: M_JOINT;
ADD_JOINT: A_JOINT;{name and type compatibility with

ROBTARGET}
ENDRECORD = JOINT;
RECORD
POSE: PSE;
INT: STATUS;
ARRAY[1..R_NTURNS] OF INT: TURNS;
ADD_JOINT: A_JOINT;
ENDRECORD = ROBTARGET;{ ROBTARGET has to be

defined suitable for all robots in a common cell; the
exact semantic of the structure ROBTARGET has to be
explained in comment }
RECORD
INT :D_NO; { Unique identification number of this

device; must be >= 0 }
INT :D_AXES_TYPE; { Type of additional axes: AX_MAIN,

ADAX_IS, ADAX_IE, ADAX_EX; for information only }
INT :D_PRED_DEVICE; { Identification number of the

preceeding device in the kinematical chain; -1 if there
is no predecessor }
INT :D_NJ; { Number of joints of this device }
ENDRECORD = D_SPEC_TYPE;
RECORD
REAL:R_ACC;

ARRAY[1..R_NJ] OF REAL:R_ACC_PTP;
REAL:R_C_PTP;
REAL:R_C_CP;
REAL:R_C_SPEED;
ARRAY[1..R_DEVICE_NUMBER] OF INT : R_DEVICES;
JOINT:R_JOINT_ACT;
ROBTARGET:R_ROBTARGET_ACT;
ROBTARGET:R_ROBTARGET_START;
ROBTARGET:R_ROBTARGET_END;
ROBTARGET:R_ROBTARGET_INTER;
REAL:R_SPEED_ACT;
REAL:R_SPEED;
ARRAY[1..R_NJ] OF REAL:R_SPEED_PTP;
REAL:R_SPEED_ORI;
POSE:R_BASE;
POSE:R_TOOL;
ENDRECORD = R_SPEC_TYPE;
ROBOT ROBOT_AND_POSITIONER :=
{ robot 1 used together with the 2 axis external

positioner }
R_SPEC_TYPE(50.0, [50.0, 50.0, 50.0, 50.0, 50.0, 50.0,

50.0],
50.0, 200.0, 50.0,
[ 1 {robot 1}, 3 {2 axis positioner},
AX_NONE, AX_NONE {just to fill up} ],
JOINT(250.0, 350.0, 250.0, 150.0, 0.0, 250.0, 0.0),
ROBTARGET(
POSE(POSITION(100.0,1000.0,0.0),ORIRS

(90.0,0.0,90.0)),
0,[0,0],0.0),
ROBTARGET(
(90.0,0.0,90.0)),
0,[0,0],0.0),
ROBTARGET(
(90.0,0.0,90.0)),
0,[0,0],0.0),
ROBTARGET(
(90.0,0.0,90.0)),
0,[0,0],0.0),
0.0, 50.0, [100.0, 100.0, 100.0, 50.0, 50.0, 50.0, 100.0],

50.0,
POSE(POSITION(0.0,0.0,0.0),ORIRS(0.0,0.0,0.0))
POSE(POSITION(0.0,0.0,-100.0),ORIRS(90.0,0.0,0.0)));
ROBOT ROBOT_2 := { robot 2 used without any

additional axes }
R_SPEC_TYPE( 50.0,
[100.0, 50.0, 50.0, 50.0, 50.0, 50.0, 50.0],
50.0, 250.0, 50.0,
[ 2 {robot 2}, AX_NONE, AX_NONE,
AX_NONE {just to fill up} ],
(150.0, 250.0, 350.0, 150.0, 250.0, 0.0, 180.0 ),
(((200.0,200.0,10.0),ORIXYZ(90.0,0.0,90.0)),
0,[0,1],180.0),
(((200.0,200.0,10.0),ORIXYZ(90.0,0.0,90.0)),
0,[0,1],180.0),

(((200.0,200.0,10.0),ORIXYZ(90.0,0.0,90.0)),
0,[0,1],180.0),
(((200.0,200.0,10.0),ORIXYZ(90.0,0.0,90.0)),
0,[0,1],180.0),
0.0, 50.0, [100.0, 100.0, 100.0, 50.0, 50.0, 100.0,

100.0], 50.0,
((0.0,0.0,0.0),ORIRS(0.0,0.0,0.0) )
((0.0,0.0,-200.0),ORIRS(0.0,0.0,90.0) ) );
VAR
ARRAY[1..R_NJ] of CHAR: R_JT;{types of joint}
ARRAY[1..R_NJ] OF BOUNDS: R_JBD;{limits of joints}
STRING: R_DEF_ORI := XYZ;

{ RS | XYZ | YXZ | ZYZ2 | ZYX | VANG | QUAT }
ARRAY[1..R_DEVICE_NUMBER] OF D_SPEC_TYPE :
D_DEVICES :=
[ (1, AX_MAIN, -1, 6), { 6 axis robot 1 }
(2, AX_MAIN, -1, 6), { 6 axis robot 2}
(3, ADAX_EX, -1, 2), { a 2 axis positioner }
(4, ADAX_EX, -1, 3) { a 3 axis positioner }
]; { all devices }

Predefined constants and variables do not have to be

declared by the user and they are to be used just as

normal constants or variables, respectively.
The CSR name is the name of the variable or component

with the same meaning in MMS Companion Standard for
Robots (ISO 9506-3).
The names of the predefined constants, variables and

components always start with "R_".
See also
Predefined Variables
Predefined System Constants


Comments
Comment =
"{" { CommentCharStream | Comment } "}"
CommentCharStream =
{ Any-Character-Exept-"{"-or-"}" }.
Accepted are all characters of the character set (incl.

end-of-line), except of the opening and closing curly
bracket. Comments may be nested.

Word Symbols
Word symbols are reserved which means they are not

allowed to be identical with identifiers.
ACCACC_PTPACT_ROB

ADAX_CONTROLALLAND
ARRAYATBRAKE
BEGINCANCELCASE
C_PASSCIRCLECLOSE
CONSTCONTINUEC_CP
C_PTPC_SPEEDDATALIST
DECLDECLOFFDECLON
DECLSYSDEFAULTDELAY
DEVICEDISABLEDIV
DODURATIONELSE
ENABLEENDCASEENDERROR
ENDFCTENDFORENDIF
ENDPROCENDPROCESSENDPROGRAM
ENDRECORDENDWHILEERROR
EXOREXPORTEXTERNALFUNCTION
EXTERNALPROCEDUREFALSEFAST
FILEFORFROM
FUNCTIONGETSTATUSGOTO
HALTHIGHIF
IMPORTININOUT
INPUTINTERRUPTINTO
LINLISTLISTADD
LISTDELLISTINDEXLISTINS
LISTLENGTHLOCKLOW
MODMOVEMOVE_INC
NOTOFOFF

ONOPENOR
OUTOUTPUTPATH
PAUSEPERMANENTPROCEDURE
PROCESSPROGRAMPTP
PULSEREADREADLN
READRACRECORDREPEAT
RESUMERETURNROBOT
SECSEMAPHORESEMA_SIGNAL
SEMA_WAITSHAREDSPEED
SPEED_ORISPEED_PTPSTANDARD_IN
STANDARD_OUTSTARTSTEP
STOPSYNACTSYSTEM_SPECIFICATION
TEACHTHENTIME
TIMEOUTTOTRUE
TYPEUNLOCKUNTIL
VARWAITWHEN
WHILEWOBBLEWRITE
WRITELNWRITERAC

Identifiers are allowed to be of any length. All

characters of one identifier are significant. All
identifiers have to be different from word symbols.
Identifier =

Letter { Letter | Digit }.
For a better readability the following identifiers are

distinguished in this standard:
ProgramIdentifier =Identifier.
TeachConstantIdentifier =Identifier.
ConstantIdentifier =Identifier.
StructuredTypeIdentifier =Identifier.
SimpleTypeIdentifier =Identifier.
StandardTypeIdentifier =Identifier.
SystemTypeIdentifier =Identifier.
TeachTypeIdentifier =Identifier.
SignalTypeIdentifier =Identifier.
VariableIdentifier =Identifier.
SignalIdentifier =Identifier.
ProcedureIdentifier =Identifier.
FunctionIdentifier =Identifier.
TypeIdentifier =Identifier.
LabelIdentifier =Identifier.
ComponentIdentifier =Identifier.

Predefined Identifiers
Functions

Channels
Constants
Types

Predefined Functions for String Handling
Not all of the string handling functions are

currently supported in COSIMIR and PCROB.
IdentifierType of Types ofExplanation
resultparameters
APPENDCSTRINGSTRING, CHAR
Appends the character c to the end of the string s.
COMPAREINTSTRING, STRING
Compares string s1 with string s2. Returns the index of
the first character that differs. If the two strings are
identical 0 is returned.
CONCATSSTRINGSTRING, STRING
Appends the characters of the string s2 to the end of
the string s1.
DELETECSTRINGSTRING, INT, INT

Deletes the characters from the string s, that are
specified by the integer i1 (start index) and the integer
i2 (final index). If the second index is less than the first
index nothing will be deleted.
EXTRACTSSTRINGSTRING, INT, INT

Extracts a part of the string s, that is specified by the
integer i1 (start index) and the integer i2 (final index).
If the second index is less than the first index an empty
string is returned.
GETCHRCHARSTRING, INTGets one character out of the

string s indexed by the integer i.

LENGTHINTSTRINGReturns the length of the string s

(number of characters).
LOCATEINTSTRING, STRING
Checks if string s2 is a substring of string s1. If it is the
first index of s1 where s2 starts is returned. If not 0 is
returned.
SETCHRSTRINGSTRING, CHAR, INT

Copies the string s, sets one character of s indexed by
the integer i to the value of character c.
SIZEINTSTRINGReturns the maximal size of the string s.


Predefined Variables
Predefined constants and variables do not have to be

declared by the user and they are to be used just as
normal constants or variables, respectively.
Variablewrite protection
nametype|meaning
R_ACT_ROBR_SPEC_TYPEnactual robot
R_TARGET_BASEPOSEnactual cell base coordinate

system
R_DEF_ORISTRINGndefault orientation mode
Trigger variables used in SynactStatements:
R_MOVE_TIMEREALytime gone from the start of the

actual robot movement
R_SCALE_FORWREALyfactor (%) of the movement

distance already covered
R_SCALE_BACKREALyfactor (%) of the movement

distance still to cover
R_DISTANCE_FORWREALydistance from the start point

(only LIN and CIRCLE movements)
R_DISTANCE_BACKREALydistance to the end point (only

LIN and CIRCLE movements)

Predefined Constants
The following predefined constants exist. There values

have to been defined in the System Specification:
constantpredefined
nametypefixed valuemeaning
R_NTURNSINTnumber of joints that can rotate more

then 360 degrees
R_NADDJINTmax. number of additional joints
R_NJINTnumber of joints
RSSTRING'RS'constants specifying different
XYZSTRING'XYZ'descriptions of orientations
YXZSTRING'YXZ'used in system functions to assign
ZYXSTRING'ZYX'orientations, write
ZYZ2STRING'ZYZ2'statements and read
VANGSTRING'VANG'statements
QUATSTRING'QUAT'
NO_ADAX_CONTROLINT0constants specifying the type of

coordinated movement, here the default
TCP_KEEPINT1world coordinate TCP position is kept
TCP_KEEP_RELINT2TCP position relative to a device is

kept

DEVICE_RELINT3movement execution relative to a

device
R_PROCESS_READYINT0constants returned by the system

function getstatus, here process ready
R_PROCESS_RUNNINGINT1process running
R_PROCESS_STOPPEDINT2process stopped
R_PROCESS_BLOCKEDINT3process blocked
R_DEVICE_NUMBERINTnumber of devices in the cell
AX_NONEINT-1placeholder for a non device in the

device group specifications
AX_MAININT0constants specifying different

device types, here the main axes
(robot)
ADAX_ISINT1additional axes starting the

kinematical chain, e. g. a rail
ADAX_IEINT2additional axes ending the

kinematical chain
ADAX_EXINT3external additional axes,

e. g. a positioner
For every robot defined by a Robot Specification a

predefined record with the name of the robot exists.
Every record consists of the following components.
Some of these components are write protected (y)
outside the System Specification and are not allowed to
be used on the left side of an user written assignment.
The rest of them is not write protected (n).
componentCSRwrite protection
namenametype|meaning
R_ACCREALnacceleration (path)
R_ACC_PTPARRAY[1..R_NJ]nacceleration factor (axes,

%)
OF REAL
R_C_PTPREALnpath smoothing:
axis distance (factor, %)

R_C_CPREALnpath smoothing:
distance to the intermediate point
R_C_SPEEDREALnpath smoothing:
(% of programmed speed)
R_JOINT_ACTR_AJVJOINTyactual robot position in robot

coordinate system
R_ROBTARGET_ACTROBTARGETyactual robot position
R_ROBTARGET_ACT.PSE
R_CTUPPOSEyactual tool point (commanded pose)
R_ROBTARGET_STARTROBTARGETyrobot position at the

start of the actual movement statement
R_ROBTARGET_ENDROBTARGETyrobot position to be
reached at the end of theactual movement statement
R_ROBTARGET_INTERROBTARGETyrobot position at the

last executed interrupt
R_SPEED_ACTREALyactual speed (path)
R_SPEEDR_PSTUREALnspeed (path)
R_SPEED_PTPARRAY[1..R_NJ]nspeed factor (axes, %)
OF REAL
R_SPEED_ORIREALnorientation speed
R_BASER_TUBPOSEnactual robot base coordinate system
R_TOOLR_TTMPOSEnactual tool correction
A commanded pose describes that pose which will be

commanded to the transformation algorithm.
Predefined system variables which are not write

protected had to be set by a default value inside the
System Specification.


Predefined Functions for Mathematical

Operations
Not all of the mathematical functions are

resultparameters
ABSREALREALAbsolut value
INTINT -"-
ACOSREALREALArc cosine, results in the interval [0,180]
ASINREALREALArc sine, results in the interval [-90,90]
ATAN2REALREAL, REALArc tangent 2, results in the

interval
(-180,180] are equal to the arc component of the polar
coordinates of the Cartesian value pair (x,y)
COSREALREALCosine (unit: degree)
CROSSPOSITIONPOSITION, POSITION
Cross or Vector product
DOTREALPOSITION, POSITION
Inner or Scalar product
FLOATREALINTConvert
INVPOSEPOSEInverse of POSE
ROUNDINTREALRound to the nearest
integer value
SINREALREALSine (unit: degree)
SQRTREALREALSquare root
TANREALREALTangent (unit: degree)
TRAFOROBTARGETJOINTTransformation axes into

cartesian coordinates and

TRAFOINVJOINTROBTARGETviceversa, both according to

the actual base (R_BASE) and tool (R_TOOL) correction
of the actual robot (R_ACT_ROBOT) and to the actual
cell base coordinate system (R_TARGET_BASE)
TRUNCINTREALTruncate to an integer value by ignoring

the digits after the decimal point
The functions which work on the geometric data types

are described in the topic about Orientation Data Types.

Miscellaneous Predefined Functions
As I/O for channels and files is currently only

supported for the CONSOLE in COSIMIR and PCROB,
the functions EOF and EOL are not supported.
resultparameters
EOFBOOLFileTypeEnd of file
EOLBOOLFILE OF CHAREnd of line
CHRCHARINTCharacter with the ASCII-Code equal to the

value of the parameter
ORDINTCHARASCII-Code Value of the Character


Types
INTREAL

CHARSTRINGTEXT
BOOL
ORIENTATIONPOSITION
POSEROBTARGET
ADD_JOINTMAIN_JOINT
JOINT

Standard Data Types
StandardType = StandardTypeIdentifier.
There are 5 predefined Standard Data Types with the

predefined identifiers STRING, TEXT, POSITION,
ORIENTATION and POSE.
String Type
The predefined data type STRING describes objects

which can hold a number of ASCII characters. The
maximum length of STRING type objects is restricted to
255. The first element of a string is referenced with the
index 1. The controller should reserve additional space
to store the maximum and the actual size of any string.
For manipulating objects of type STRING predefined
functions can be used.
Text Type
The predefined data type TEXT is used for file handling

in sequential text files and for channel handling. The
data type bases on data type CHAR and is defined as
FILE OF CHAR.
See also
Predefined Geometric Data Types


Simple Type
SimpleType = SimpleTypeIdentifier.
There are 4 predefined Simple Data Types with the

predefined identifiers BOOL, CHAR, INT and REAL.
Boolean Type
The predefined data type name BOOL describes objects

which can only hold the values true (<>0) and false (=0).
Character Type
The predefined data type name CHAR describes objects

which can hold exactly one ASCII character.
Integer Type
The predefined data type INT describes integer values.
Real Type
The predefined data type REAL describes real numbers.


Array Types
An array is a data structure consisting of a fixed number

of components which are all of the same type. An array
element is accessed by indices.
ArrayTypeDescription =
"ARRAY" "[" IndexBoundList "]" "OF" Type.
IndexBoundList =
IndexBound { "," IndexBound }.

The dimension of an array is determined by the number

of indices. IndexBound describes the lower and upper
bounds of an array.
IndexBound =
Expression ".." Expression.
Expressions are allowed to be only constants of the data

type INT or CHAR.
Example:
TYPE
ARRAY [4..10] OF ROBTARGET = p_type;
{one dimensional array, with elements of type

ROBTARGET}
ARRAY [1..100,1..80] OF CHAR = text_type;
{two dimensional array, elements of type CHAR}


List Types
Lists are currently not supported in COSIMIR and

PCROB.
A list is a data structure consisting of a variable number

of components which are all of the same type. A list
element can be accessed by indices, the first index is 1,
the highest index is equal to the length of the list.
Additional there are statements to insert, append or
delete single list elements.
ListTypeDescription =
"LIST" "OF" Type.
Example:
TYPE

LIST OF ROBTARGET = dynamic_path;
{list type with variable number of elements of type

ROBTARGET}

System Data Types
SystemType = SystemTypeIdentifier.
There are 6 predefined System Data Types with the

predefined identifiers MAIN_JOINT, ADD_JOINT, JOINT,
ROBTARGET, D_SPEC_TYPE and R_SPEC_TYPE. These
predefined record types are system specific and have to
be defined in the System Specification.

File Types
Files are currently not supported in COSIMIR and

PCROB.
FileTypeDescription =
"FILE" "OF" Type.
IRL defines symbolic names of file types and files. The

"real" structure of the files is not treated by IRL,
because the structure depends on the operating system.
IRL allows the following file types:
- Sequential text files
These files are declared as FILE OF CHAR and are stored

as ASCII-files. They are treated sequentially.

The data type TEXT is predefined as FILE OF CHAR .
- Sequential typed files
These files only store values of a certain type defined by

Type given in the FileType definition. They are treated
sequentially.
- Random access typed files
These files only store values of a certain type defined by

Type given in the FileType definition. They are treated
in a random access manner.
- Channels

Signal Types
SignalTypeDeclaration =
SignalTypeDescription ":" SignalTypeIdentifier.
SignalTypeDescription =
( "INPUT" | "OUTPUT" ) SimpleType.
The declaration of Signals is allowed and so attached

data types may be defined.
SignalType =
SignalTypeIdentifier |
SignalTypeDescription.

Robot Specification Type
The Type R_SPEC_TYPE consists of the robot specific

predefined system variables. As well as the system

specific geometric data types it must be declared in the

System Specification. For every robot used within an IRL
program a record of that type has to be initialized by a
Robot Specification.
Example:
TYPE
RECORD
REAL:R_ACC;
ARRAY[1..R_NJ] OF REAL:R_ACC_PTP;
REAL:R_C_PTP;
REAL:R_C_CP;
REAL:R_C_SPEED;
ARRAY[1..R_DEVICE_NUMBER] OF INT : R_DEVICES;
JOINT:R_JOINT_ACT;
ROBTARGET:R_ROBTARGET_ACT;
ROBTARGET:R_ROBTARGET_START;
ROBTARGET:R_ROBTARGET_END;
ROBTARGET:R_ROBTARGET_INTER;
REAL:R_SPEED_ACT;
REAL:R_SPEED;
ARRAY[1..R_NJ] OF REAL:R_SPEED_PTP;
REAL:R_SPEED_ORI;
POSE:R_BASE;
POSE:R_TOOL;


User Defined Data Types
Userdefined data types are restricted to structured,

teach, signal or semaphore types.
Structured Data Types
StructuredTypeDeclaration =
StructuredTypeDescription ":" StructuredTypeIdentifier
StructuredTypeDescription =
RecordTypeDescription |
ArrayTypeDescription |
ListTypeDescription |
FileTypeDescription.
See also
Record Types
Array Types
List Types
File Types
Teach Types
Signal Types
Semaphore Types

Type Declaration
IRL includes predefined data types and allows the

definition of several user specific data types. The
predefined data types consist of simple data types
(BOOL, INT, REAL or CHAR), standard data types
(STRING, TEXT, POSITION, ORIENTATION or POSE) and
the so called system data types (MAIN_JOINT,

ADD_JOINT, JOINT, ROBTARGET, D_SPEC_TYPE or

R_SPEC_TYPE). The properties of the system data types
are partially determined in the system specification.
Only structured data types can be determined by the

user, namely structures (RECORD) arrays (ARRAY), lists
(LIST) or files (FILE), and only predefined data types can
be more precisely specified by additional informations
namly by the key words TEACH, PERMANENT, SIGNAL or
SEMAPHORE. TEACH- or PERMANENT-specifications for
teach data types are allowed for all predefined data
types including all system data types, but no robot
specification type (R_SPEC_TYPE). The SIGNAL-
specification for signal data types is only allowed for
simple data types, the SEMAPHORE-specification is only
possible in connection with boolean or integer types.
The predefined data types TEXT up to R_SPEC_TYPE

simultaneously are structured data types, TEXT is a
special file type (FILE OF CHAR), the other types except
ORIENTATION are structures. For the data types
POSITION up to ADD_JOINT the term geometric data
types is also allowed.
TypeDeclaration =
StructuredTypeDeclaration |
TeachTypeDeclaration |
SignalTypeDeclaration |
SemaphoreTypeDeclaration.
Type Description and Type Identifier
By the needs of variable declaration and constant

definition it is necessary to have possibilities to
reference to specified data types. This can be done by
explicit type description or by using type identifiers.
A type identifier represents the name of an existing

predefined or userdefined data type.
Type =
PredefinedType |
StructuredTypeIdentifier |
StructuredTypeDescription.
Predefined Data Types
PredefinedType =
SimpleType |
StandardType |
SystemType.

See also
Simple Type
Standard Types
System Types

Record Types
A userdefined record type introduces a new data type.
RecordTypeDescription =
"RECORD" ComponentList "ENDRECORD".
ComponentList =
Type ":" ComponentIdList
{ ";" Type ":" ComponentIdList }.
ComponentIdList =
ComponentIdentifier { "," ComponentIdentifier }.
A record type is a collection of several objects which

may be of different data types. These objects are called
components. If one component is a record type itself
the record is nested.
Each component has an identifier by which it can be

accessed. Identifier and data type of the components
are described in the definition of the record type. The
identifier has to be unique within one record type
description.
Example:
TYPE
RECORD
position_type: p1, p2;
REAL: current;

ENDRECORD = test_type;

Geometric Data Types
Geometric data types and the attached

operators enable the programmer to handle
datas from CAD-systems, to optimize robot
movements under various aspects, or to
calculate the path of a robot under sensor
definition.
The geometric data types are used for

description of position and orientation of
robots or effectors or other objects. These
types is underlying a cartesian coordinate
system whose origin and orientation will be
defined during the installation of the robot
control system. It is called world coordinate
system and all other coordinate systems are
directly or indirectly related to it. The values
of an object description can be related to
any reference system, but the language does
not support the explicit specification of this
relation. Therefore the programmer using
the geometric operations defined later to
combine such object descriptions is
responsible for matching the relations
between the corresponding reference
systems assumed by these operations.
If the reference system of an object

description is not the world coordinate
system in the definitions and in the examples
of this standard variables are used with an
upper left index specifying the reference
system. In most cases the index identifier
corresponds to a POSE or ROBTARGET
variable representing the reference
coordinate system.
For the record types MAIN_JOINT,

ADD_JOINT, JOINT, ROBTARGET,
D_SPEC_TYPE and R_SPEC_TYPE see the
following chapter.

See also
Position Data Type
Orientation Data Types
Pose Data Type
System Data Types
Robot Target Data Type
Joints Data Type
Device Specification Type
Robot Specification Type

Pose Data Type
TYPE
RECORD
POSITION: POS;
ORIENTATION: ORI
ENDRECORD = POSE;
The predefined data type POSE is composed of the

components POS and ORI of POSITION and ORIENTATION
type, respectively. Besides other possible
interpretations a variable of type POSE can specify a
transformation between two coordinate systems, the
components representing the origins position and the
direction of the second coordinate system in relation to
the first one or the position and orientation of an object
or the robot TCP in relation to the world coordinate
system.
In order to select a POSE component, the POSE structure

must be splitted in its POSITION and ORIENTATION part

and then these datatypes have to be handled in the

above described way. Besides this the type conversion in
assignment statements can be used to select the
POSITION or ORIENTATION part of a POSE type
expression.
Assignment to a POSE variable:
VAR
POSITION: first_pos, next_pos;
ORIENTATION: ori;
POSE: f,g;
BEGIN
f.POS := first_pos;
f.ORI := ori;
g := POSE (next_pos,f.ORI);
Selection of a component of POSE:
next_pos := f.POS;
ori := g.ORI;

Orientation Data Types
Quaternion orientation functions are currently

not supported in COSIMIR and PCROB.
The inner structure of the predefined data type

ORIENTATION is fixed by the producer of the IRL-
compiler.
This type describes the direction of a coordinate system

in space in relation to a reference system. The zero
orientation is identical with the orientation of the

reference system. The internal realization of the data

type ORIENTATION in the programming system is no part
of this standard, but for the exact semantic
specification of the geometric operations the
representation of an orientation by a rotation matrix is
used.
If an orientation describes the direction of a coordinate

system R1 in relation to a reference system R the
corresponding rotation matrix M = ( Rn Ro Ra ) consists
of three columns equal to the R-coordinates of the
three basic vectors Rn, Ro and Ra of the coordinate
system R1.
For every orientation ori there is one unique rotation

matrix here written as M = M(ori), and because of the
properties of the basic vectors of a cartesian coordinate
system the identity M-1 = MT is true for all M.
Besides other possible interpretations an ORIENTATION

type variable can specify a rotation or the direction of a
coordinate system describing a transformation. This can
be seen in the following equations using normal matrix
operations.
Rotation: Rp' = M(Rori) * Rp
Here Rp and Rp' represent the vector p before and after

the rotation represented by Rori, all variables specified
in relation to the same reference system R.
Transformation: Rp = M(Rori) * R1p
Here R1p represents the local coordinates of the Point P

in relation to the coordinate system R1, Rori describing
the direction of R1 in relation to R. The result Rp
represents the coordinates of the same Point P in
relation to R.
It is sufficient to define the orientation by some

rotations, but there are different ways to specify the
behavior of the rotations. Therefore the rotations are
notified as different function calls, each one is defining
another meaning of the rotation values. The calculation
of the internal representation from the given
orientation function is a task of the programming
system.
Assignment to an orientation variable:
VAR

ORIENTATION: ori;
POSITION: n1,o1,a1,v;
REAL: a,b,c,d;
BEGIN
ori := ORIRS(a,b,c);
first a rotates about the x-axis of the reference system,

then b about the y-axis of the original reference system,
third c rotates about the z-axis of the original reference
system
ori := ORIXYZ(a,b,c);
first a rotates about the x-axis of the reference system,

then b about the new y-axis of the rotated reference
system, third c rotates about the new z-axis of the two
times rotated reference system
ori := ORIYXZ(a,b,c);
first a rotates about the y-axis of the reference system,

then b about the new x-axis of the rotated reference
system, third c about the new z-axis of the two times
rotated reference system
ori := ORIZYX(a,b,c);
first a rotates about the z-axis of the reference system,

system, third c about the new x-axis of the two times
rotated reference system (equal to ORIRS(c,b,a))
ori := ORIZYZ2(a,b,c);
first a rotates about the z-axis of the reference system,

system, third c about the new z-axis of the two times
rotated reference system
ori := ORIVANG(v,a);
a rotates about the axis v, described in the reference

system
ori := ORIQUAT(a,b,c,d);
a, b, c, d are parameters of the quaternion specification

ori := ORIMAT(n1,o1,a1);
n1, o1, a1 are unit vectors representing the three

columns of a rotation matrix, they build a rigth-handed
coordinate system
Selection of a component of ORIENTATION:
Selecting a component of an orientation, i.e. rotation

angle or axis of rotation or quaternion value, there is
the need to specify the kind of orientation which should
underlie the values; this is done by an additional
parameter of the select function.
VAR
ORIENTATION: ori;
POSITION: n1,o1,a1,v;
REAL: r;
BEGIN
r := ANGLEX(RS,ori);
result: rotation about the x-axis under ORIRS definition
r := ANGLEX(XYZ,ori);
... under ORIXYZ definition
r := ANGLEX(YXZ,ori);
... under ORIYXZ definition
r := ANGLEX(ZYX,ori);
... under ORIZYX definition
r := ANGLEY(RS,ori);
result: rotation about the y-axis under ORIRS definition
r := ANGLEY(XYZ,ori);
r := ANGLEY(YXZ,ori);

r := ANGLEY(ZYZ2,ori);
... under ORIZYZ2 definition
r := ANGLEY(ZYX,ori);
r := ANGLEZ(RS,ori);
result: rotation about the z-axis under ORIRS definition
r := ANGLEZ(XYZ,ori);
r := ANGLEZ(YXZ,ori);
r := ANGLEZ(ZYZ2,ori);
... under ORIZYZ2 definition
r := ANGLEZ(ZYX,ori);
r := ANGLEZ2(ZYZ2,ori);
result: rotation about the z2-axis under ORIZYZ2

definition
v := ROTAXIS(ori);
result: vector of rotation under ORIVANG definition
r := ROTANGLE(ori);
result: rotation about the v-axis under ORIVANG

definition
r := QUATA(ori);
result: parameter a of the quaternion specification
r := QUATB(ori);
result: parameter b ...
r := QUATC(ori);

result: parameter c ...
r := QUATD(ori);
result: parameter d ...
a1 := VECTORA(ori);
result: unit vector representing the third column of the

rotation matrix
n1 := VECTORN(ori);
result: unit vector representing the first column of the

rotation matrix
o1 := VECTORO(ori);
result: unit vector representing the second column of

the rotation matrix
ENDPROGRAM;
It is important, that the definition of an orientation can

use values greater than 90 or 180 degree, but that the
selection of an orientation component will always yield
a value between -180 and 180 degree. Furthermore the
results of a select operation can differ from the input
value which are used for generating the orientation,
because of the ambiguity of angle statements in the
mathematical world.
To solve the following three problems it is necessary to

specify the results of these select operations in detail.
Even if all angle results are defined as degree between -
180 and 180 there is no unique solution for every
orientation value. Thats why some of the results must
be between -90 and 90 degree or between 0 and 180
degree, respectively. Secondly even then there exist
orientation values with more than one possible correct
solution of the select operations. Then some default
values should be used. Thirdly the results of the select
operations are not independent from each other.
Especially if one angle was set to such a default value
then the select operations must give results which yield
to the original orientation using the underlying
orientation definition function.
The exact specification of the possible results of the

select operators for every kind of orientation definition
is given in a short form, specifying the select operators
of the same kind of orientation in complex.

For a := ANGLEX(RS,ori), b := ANGLEY(RS,ori) and c :=

ANGLEZ(RS,ori) the following must be true:
-180 <= a <=180- first rotation about the x-axis
-90 <= b <=90 - second rotation about the y-axis
-180 <= c <=180- third rotation about the z-axis
if b = -90 or b = 90 then a := 0 (no rotation about the x-

axis) and the value of c must realize that ORIRS(a,b,c) is
equal to the original orientation
For a := ANGLEX(XYZ,ori), b := ANGLEY(XYZ,ori) and c :=

ANGLEZ(XYZ,ori) the following must be true:
-180<= a <=180 - first rotation about the x-axis
-90<= b <=90 - second rotation about the y-axis
-180<= c <=180 - third rotation about the z-axis
if b = -90 or b = 90 then a := 0 (no rotation about the x-

axis) and the value of c must realize that ORIXYZ(a,b,c)
is equal to the original orientation
For a := ANGLEY(YXZ,ori), b := ANGLEX(YXZ,ori) and c :=

ANGLEZ(YXZ,ori) the following must be true:
-180 <= a <= 180 - first rotation about the y-axis
-90 <= b <= 90 - second rotation about the x-axis
-180 <= c <= 180 - third rotation about the z-axis
if b = -90 or b = 90 then a := 0 (no rotation about the y-

axis) and the value of c must realize that ORIYXZ(a,b,c)
is equal to the original orientation
For a := ANGLEZ(ZYZ2,ori), b := ANGLEY(ZYZ2,ori) and

c := ANGLEZ2(ZYZ2,ori) the following must be true:
-180 <= a <= 180 - first rotation about the z-axis
0 <= b <= 180 - second rotation about the y-axis
-180 <= c <= 180 - third rotation about the new z-axis
if b = 0 or b = 180 then a := 0 (no rotation about the y-

axis) and the value of c must realize that ORIZYZ2
(a,b,c) is equal to the original orientation

For a := ANGLEZ(ZYX,ori), b := ANGLEY(ZYX,ori) and c :=

ANGLEX(ZYX,ori) the following must be true:
-180 <= a <= 180 - first rotation about the z-axis
-90 <= b <= 90 - second rotation about the y-axis
-180 <= c <= 180 - third rotation about the x-axis
if b = -90 or b = 90 then a := 0 (no rotation about the y-

axis) and the value of c must realize that ORIZYZ2
(a,b,c) is equal to the original orientation
For v := ROTAXIS(ori) and r := ROTANGLE(ori) the

following must be true:
v must be a unit vector
0 <= r <= 180 - rotation about the v-axis
if r = 0 then v := ( 0, 0, 1 ) (parallel to z-axis)
if r = 180 then ((v.x > 0) or ((v.x = 0) and (v.y > 0)) or
((v.x = 0) and (v.y = 0) and (v.z = 1)))
For a := QUATA(ori), b := QUATB(ori), c := QUATC(ori)

and d := QUATD(ori) the Quatrupel (a,b,c,d) must be a
unit quaternion with:
0 <= a - per definition
if a = 0 then ((b > 0) or ((b = 0) and (c > 0)) or
((b = 0) and (c = 0) and (d = 1)))
Example:
VAR
ORIENTATION: ori1, ori2;
REAL: r;
BEGIN
ori1 := ORIRS(90,90,0);
the orientation of the reference system will be rotated

about the x-axis of the reference system with 90 degree
and afterwards about the y-axis of the original
reference system with 90 degree

ori2 := ORIXYZ(90,90,0);
the orientation of the reference system will be rotated

about the x-axis of the reference system with 90 degree
and afterwards about the new y-axis of the rotated
reference system with 90 degree
r := ANGLEZ(RS,ORIZYZ2(90,90,90));
assigns to r the rotation angle 180 degree about the

original z-axis; the other solution with a rotation of 0
degree about the z-axis including a rotation of 180
degree about the y-axis is not possible because of
ANGLEY(RS,ORIZYZ2(90,90,90)) must between -90 and
90
ENDPROGRAM;
Note:
Even with the given exact specification the use of the

select operators on a sequence of continuous
orientation values can lead to non-continuous results
which is very dangerous if the results should be used to
control some robot or additional axis. But only this
specification makes it possible to detect such problems
by the user and to write algorithms that may handle
such non-continuous values.

Robot Target
ROBTARGET has to be defined suitable for all robots in a

common cell; the exact semantic of the structure
ROBTARGET should be explained in a comment.
ROBTARGET describes the position and orientation of

the tool center point (TCP) of an industrial robot.
ROBTARGET consists of a pose type part which defines
the position and the orientation of the TCP, some parts
which describes the exact status of the robot axes and if
necessary the position of additional axes.
Objects of this data type may be operands of geometric

operations or in special statements (e.g. MOVE PTP).

Example:A robot with additional axis
TYPE
RECORD
POSE: PSE;
INT: STATUS;
ARRAY[1..R_NTURNS] OF INT: TURNS;
ADD_JOINT: A_JOINT;
ENDRECORD = ROBTARGET;
In this example STATUS describes an additional degree

of freedom (for example 'shoulder right or left'). The
relation between values of data type INT and the robot
configuration is system dependent. TURNS describes the
number of rotations of 360 degree performed by some
of the axes. R_NTURNS defines the maximum number of
joints in a cell which can rotate more than 360 degrees.

Teach Types
TeachTypeDeclaration =
TeachTypeDescription ":" TeachTypeIdentifier.
TeachTypeDescription =
( "TEACH" | "PERMANENT" ) PredefinedType.
The global declaration of TEACH-variables is allowed

and so attached data types may be defined.
TeachType =
TeachTypeIdentifier |
TeachTypeDescription.


Joints
The predefined data type JOINT describes the position

of the TCP of an industrial robot in the robot coordinate
system. Its definition depends on the number of axis of
the industrial robot. According to the axis type, the
components are either angles (rotation axis) or
distances (translation axis).
JOINT is composed of the components M_JOINT and

A_JOINT of MAIN_JOINT and ADD_JOINT type,
respectively to distinguish between main axis and
additional axis. The components A_JOINT of this type
JOINT and of the above defined type ROBTARGET must
be identical. This implicates, that the predefined
functions TRAFO and TRAFOINV must not change the
values of this ADD_JOINT type component.
The predefined data types MAIN_JOINT, ADD_JOINT and

JOINT have to be defined in the System Specification.
Example:
TYPE
RECORD REAL: A1,A2,A3,A4,A5 ENDRECORD =

MAIN_JOINT;
RECORD REAL: AA1,AA2,AA3 ENDRECORD = ADD_JOINT;
RECORD
MAIN_JOINT: M_JOINT;
ADD_JOINT : A_JOINT
ENDRECORD = JOINT;


Program Flow
ProgramflowStatement =
GotoStatement |
ConditionalBranchStatement |
CaseStatement |
LoopStatement |
WaitStatement |
PauseStatement |
ReturnStatement |
ProgramHaltStatement |
InterruptStatement |
ResumeStatement |
SynactStatement.
See also
Goto Statement
Conditional Branch Statement
Case Statement
For Loop Statement
Repeat Loop Statement
While Loop Statement
Wait Statement
Pause Statement
Return Statement
Program Halt Statement
Interrupt Statement
Resume Statement
Synact Statement


Goto Statement
GotoStatement =
"GOTO" LabelIdentifier.
The GOTO statement forces control to the statement

which is marked by the label. The label must be within
the same function or procedure. A jump is not allowed
to lead into a block.
A label identifier is not declared by a declaration of

variables.

For Loop
ForStatement =
"FOR" Object ":=" Expression "TO" Expression
[ "STEP" Expression ]
StatementBlock "ENDFOR".
The first Expression is the limit to start the loop, the

second Expression is the limit to end the loop. The third
Expression is the increment. The default increment is 1.
Negative increments are allowed.
All expressions must be arithmetical expressions. They

and the Object must be of data type INT. Before the
StatementBlock of the ForStatement starts execution all
three expressions are evaluated.
In the case of positive increment the StatementBlock is

executed if the value of Object which represents the
counter is less or equal to the second Expression. With
negative increment the counter has to be greater or
equal for execution. In the case of zero increment the
StatementBlock is executed as long as it is not left by a
GotoStatement.
After leaving the loop with a GotoStatement the counter

keeps its current value. After normal completion of the
loop the counter is equal to the first value that does not
match the condition for the execution of the statement
block.

Example:
FOR i := 1 TO 10
MOVE LIN palette [i];
ENDFOR;

Case Statement
CaseStatement =
"CASE" Expression "OF"
CaseList [ "DEFAULT" [ ":" ] StatementBlock ]
"ENDCASE".
CaseList =
Case { ( "|" | "WHEN" ) Case }.
Case =
[ CaseConstantList ":" StatementBlock ].
CaseConstantList =
CaseConstant { "," CaseConstant }.
CaseConstant =
Expression.
The CASE statement dispatches control to one of the

StatementBlocks in its list, according to the calculated
value of its arithmetical Expression. If no CaseConstant
matches the calculated value the DEFAULT block is
executed.
DEFAULT is optional. If there is no DEFAULT block and

no CaseConstant is matched control is passed to the
next statement.
Expression and CaseConstants must be of data type INT

or CHAR.
Example:
CASE workpiece OF

WHEN 0:length := 1;
WHEN 1,6:length := 5;
DEFAULT: length := 0;
ENDCASE;

Conditional Branch Statement
ConditionalBranchStatement =
"IF" Expression
"THEN" StatementBlock
[ "ELSE" StatementBlock ]
"ENDIF".
The statement block following the keyword THEN is

executed if the result of the logical Expression has the
value true (<>0).
If the Expression has the value false (=0) the statement

block behind the keyword ELSE is executed. The ELSE-
block may be omitted.
Every IF needs an ENDIF.
Example:
IF x > 1
THEN
y := 50;
z := 20;
ELSE
y := 30;
ENDIF;
IF x < 25 THEN y := 30; z := 10; ELSE z := 2*y; ENDIF;


Procedure Call
ProcedureCall =
ProcedureIdentifier "(" [ ValueList ] ")".
The call of procedure starts the execution of this

procedure. The actual parameters are passed to the
corresponding formal parameters. Therefore the
number of expressions and of formal parameters has to
be identical and the types have to be parameter
compatible to the formal parameters.

While Loop
WhileStatement =
"WHILE" Expression StatementBlock "ENDWHILE".
The statement block will be repetitively executed as

long as the evaluation of the logical Expression returns
true (<>0). If the first interpretation of Expression
returns false (=0) the statement block will not be
executed at all.
Every WHILE needs an ENDWHILE.
Example:
i := 1;
WHILE i<=10
MOVE LIN palette[i];
i := i+1;

ENDWHILE;

Repeat Loop
RepeatStatement =
"REPEAT" StatementBlock "UNTIL" Expression.
The statement block is executed once. Afterwards the

logical Expression is interpreted. If it has the value false
(=0) the execution of the StatementBlock is repeated,
otherwise the next statement is executed.
Every REPEAT needs an UNTIL
Example:
i := 1;
REPEAT
MOVE LIN palette[i];
i := i+1;
UNTIL i>10;

Resume Statement
Interrupts and the RESUME statement are

currently not supported in COSIMIR and PCROB.
ResumeStatement =
"RESUME".

The ResumeStatement terminates the execution of an

interrupt procedure. It can only be used within a
procedure called by an InterruptStatement.
The difference between the termination of an interrupt

procedure by the ReturnStatement and by the
ResumeStatement is the position where the program is
continued. The ReturnStatement as well as the
"ENDPROC"-keyword cause the resumption of the
program at the position where it had been interrupted
whereas after a ResumeStatement the program
continues with the statement behind the interrupted
statement on the program level where the interrupt has
been defined.
To make use of the advantages of the ResumeStatement

the program has to be adequately structured. It is
advised to put all statements that might be interrupted
into one procedure and to use the top-level of the
program for definitions and error handling only. In the
example given an interrupt occuring within the
procedure "Main" would be handled by the "Int_Gripper"
procedure. If this procedure is terminated by the
ResumeStatement - e.g. because the error cannot be
eleminated - the program is continued with the
statement following the "Main" function call, no matter
in what part of "Main" or in which function called by
"Main" the program had been interrupted. By this errors
during program execution can easily be handled at one
point of the program.
Example:
PROGRAM ResumeDemo;
VAR
INT:ErrorNumber;
INTERRUPT DECL 41 WHEN GripperError=TRUE DO

Int_Gripper();
PROCEDURE Int_Gripper();
BEGIN
...
ErrorNumber:=1;

RESUME;
ENDPROC;
BEGIN
INTERRUPT ON 41;
Main();{complete body of the program}
INTERRUPT OFF;
CASE ErrorNumber OF
WHEN 0: ...
WHEN 1: ...
...
ENDCASE;
ENDPROGRAM

Return Statement
ReturnStatement =
"RETURN" [ Expression ].
The return statement terminates the execution of a

function or a procedure.
The execution of a function must always end with a

RETURN statement. A return value must be passed to
the calling program. Therefore the data type of
Expression must be equal to the data type of the
function.
A procedure can be left by a RETURN statement. A

return value is not allowed. If no RETURN statement is
given, the procedure will be left after having reached
the end.


I/O Statements
Signals
Signal identifiers are treated like variables. They can be

checked by using expressions and set by value
assignments.
Example:
CONST
BOOL: lowlevel := FALSE;
BOOL: highlevel := TRUE;
VAR
INPUT BOOL: IN_1 AT 1, IN_2 AT 2, IN_3 AT 3;
OUTPUT REAL: ANOUT_2 AT 2;
OUTPUT BOOL: OUT_5 AT 5;
BEGIN
OUT_5 := lowlevel; { reset output 5: }
IF IN_1 = highlevel THEN ...{ branch, if input 2 has high

level }
ANOUT_2 := 3.4;{ analog value 3.4 to output 2 }
WAIT FOR IN_2 = lowlevel;{ wait, until input 2 is low }
Every appearance of a signal in an expression causes an

inquiry to the interface.
Furthermore there is the possibility to define user

specific signal identifiers by signal declarations.


Write Statement
I/O for channels and files is currently only

supported for the CONSOLE in COSIMIR and PCROB.
WriteStatement =
( "WRITE" | "WRITELN" ) "(" FormatList ")" |
"WRITERAC" "(" Expression "," ElementNumber ","
ValueList ")".
FormatList =
[ OutputValue
[ ":" Expression
[ ":" Expression
[ ":" Expression
]]]
{ "," OutputValue
[ ":" Expression
[ ":" Expression
[ ":" Expression
]]]
}
].
OutputValue = Expression.
ElementNumber = Expression.
With the write statement, followed by a file identifier

or a channel identifier and a list of expressions, the
expression values are written to the file or channel.
- Sequential typed files
The output data always are ASCII.
In the FormatList the first element of OutputValues may

be an Object which defines the FileType. This object
represents the required file or channel identifier. If it is
missing STANDARD_OUT is used as default.
Every (other) element of the FormatList may consist of

up to four expressions. The first of them is the
OutputValue, that defines the value to be written. The

other three expressions specify the way the

OutputValue is to be written. They are called
Fieldwidth, Precision and OriMode.
If the second expression is of type INT it defines the

Fieldwidth. It is only allowed for OutputValues of type
INT or REAL (or those containing these types like
POSITION).
If the third expression is of type INT it defines the

Precision. It is only allowed for OutputValues of type
REAL (or those containing a REAL like POSITION).
If the last of the expressions is of type STRING it defines

the OriMode. It must be one of the following predefined
constants: RS, XYZ, YXZ, ZYZ2, ZYX, VANG or QUAD. The
specification of OriMode is only allowed for
OutputValues that are of type ORIENTATION (or contain
that type like POSE).
The Fieldwidth value describes the number of digits to

be written for the REAL or INT OutputValue (or for each
REAL or INT within OutputValue). The default value for
Fieldwidth is 10.
The Precision is the number of digits behind the decimal

point for the REAL value to be written (or for each
REAL). The default value for Precision is 4.
If the value "Fieldwidth minus Precision" is not sufficient

to represent the digits to the left of the decimal point
but a Fieldwidth value of 10 (the default) would be
sufficient the necessary number of digits will
automatically written instead. If even a Fieldwidth
value of 10 (the default) would not be sufficient a
representation using a decimal exponent will be used
automatically in that case (e.g. -1.23456789E+15).
Writing an orientation type value (or a value containing

an orientation type) the OriMode expression defines the
orientation mode that will be used to represent the
printed value. The default value for OriMode is defined
in the system specification by R_DEF_ORI.
A boolean value will be written as '0' (FALSE) or

'1' (TRUE).
The following examples show the representation of the

printed values:
WRITE(orivar:4:2:XYZ);

==> ORIXYZ(-11.22, 44.44, -33.33)
WRITE(orivar:ZYX);
==> ORIZYX( -45.0001, 0.0, 45.6789)
with defaults for Fieldwidth and Precision, here: 10 and

4.
WRITE(orivar);
==> ORIRS( 12.3456, 89.0123, -3.0)
uses the default orientation specification, here: RS.
WRITE(orivar:2:1:VANG);
==> ORIVANG(( 1.0, 0.0, 0.0), 145.0)
with the first three components describing the unit

vector of the rotation, and the fourth component
comprises the rotation angle (note that here 2 digits are
not sufficient to express the correct value, so more
digits are written).
WRITE(orivar:3:1:QUAT);
==> ORIQUAT( 11.0, 0.1, 0.3)
- Random access typed files
The first Expression has to be a File Type Variable. It

represents the required file or channel identifier.
The output data must have the type which is defined by

the component type of the File Type Variable of the
first Expression, otherwise an error will be created.
The element to be written is defined by ElementNumber

which is an expression of data type INT. If the element
number does not exist (e. g. too large) the element
number is set to the last element number + 1. The end
of a set is not checked during writing.
- Channels
Channels are handled as sequential text files.
The write statement with line feed (WRITELN) only is

allowed in connection with sequential text files. After
writing a CR/LF is appended.


Read Statement

ReadStatement =
( "READ" | "READLN" ) "(" ObjectList ")" |
"READRAC" "(" Expression "," ElementNumber ","
ObjectList ")".
ObjectList =
Object { "," Object }.
The read statement reads data from the file or the

channel and assigns them to the objects. The use of the
different file types is analog to the write statement.
Reading an orientation type variable by "READ(orivar)"

needs the following input:
ORIRS(value1, value2, value3)
ORIZYX(value1, value2, value3)
ORIQUAT(value1, value2, value3, value4)
ORIVANG(value1, value2, value3, value4)
"READ(orivar)" results in:
orivar:=ORIRS(value1, value2, value3)
orivar:=ORIVANG(POSITION(value1, value2, value3),

value4)
The read statement with linefeed (READLN) is only

allowed in connection with sequential text files. It
causes a jump behind the next line feed after reading.
A boolean value will be read as '0' (FALSE) or '1' (TRUE).



Channels
Channels are currently not supported in

COSIMIR/PCROB.
SER_1 .. SER_xserial interfaces (x = number of

interfaces)
PAR_1 .. PAR_xparallel interfaces (x = number of

interfaces)
KEYBOARD
PANEL
PRINTER
SCREEN
TTY
HPU( hand programming unit )
MCP( manual control panel )


Open Statement

This means that the OPEN statement is not supported.
OpenStatement =
"OPEN" "(" Object "," Expression ","
Expression "," Object ")".

The first Object has to be a FileType. It defines the file

pointer. The second Object returns an error code of
data type INT.
The first Expression must be a character string, that

defines the name and the accesspath of the file. This
string is systemdependent and is not fixed by this
standard.
The second Expression defines the working mode of the

file:
'R' =open file for reading from the beginning.
'W' =open file for writing from the beginning;
if the file already exists it will be erased.
'A' =open file for writing at the end.
'RAC' =open file for random access.
The options 'R', 'W', 'A' and 'RAC' are meaningless to

channels.
If the file is opened for random access it is opened for

reading and writing from given position.
A sequential file which was opened for writing cannot

be read. A sequential file which was opened for reading
cannot be accessed for writing.
If a file or a channel is just opened the open statement

causes an implicit closing and an opening again. This can
be used to position the pointer for reading back to the
beginning of a file.

Close Statement

This means that the CLOSE statement is not

supported.
With the close statement an open file or an open

channel is closed. If file pointer is omitted all open files
and channels (except PANEL, SCREEN, KEYBOARD, TTY,
HPU and MCP) are closed.
CloseStatement =
"CLOSE" [ "(" Expression ")" ].
Expression defines the file pointer and has to be an

Identifier.

I/O for Channels and Files

File_I_O_Statement =
OpenStatement |
CloseStatement |
WriteStatement |
ReadStatement.
A file or a channel has to be opened before the first

write statement or read statement. If a file does not
exist it is created.
Channels that are defined with the predefined channel

identifier PANEL, SCREEN, KEYBOARD, TTY, HPU and
MCP must not be opened.

Pulse Statement

The PULSE statement is currently not supported

in COSIMIR and PCROB.
PulseStatement =
"PULSE" Object ( "HIGH" | "LOW" ) "DURATION" ":="
Expression.
The PulseStatement sets a binary output to high or low

level for a specified time. The object is an OUTPUT
signal type and specifies the output to be pulsed. HIGH
or LOW, respectively define whether the output is set to
high or low level. The expression is the duration of the
pulse in seconds and of data type REAL. The
PulseStatement has no effect if the output specified
already has the given level.
Example:
...
OUTPUT BOOL: Reset AT 15;
...
PULSE Reset HIGH DURATION := 0.2;
{set binary output 15 to high-level for 200 ms}
...

Expressions
Expression =
"+" Expression |
"-" Expression |
"NOT" Expression |
Expression Operator Expression |
Object |
IntegerConstant |
RealConstant |
BooleanConstant |
CharacterString |

CallOrRecord |
Precedence |
ArrayInit.
Precedence =
"(" [ ValueList ] ")".
Expressions may be of some kinds. The following types

are distinguished in their semantics:
Arithmetical Expressions
Logical Expressions
Geometric Expressions
Interpretation of Expressions
For the interpretation of an expression, the operator of

higher priority will always be used first. Operators of
the same rank are interpreted from left to right.
Parentheses may be used to change this order.
The priority of the different operators is defined from

top (highest priority) to bottom (lowest priority)
according to the following table:
NOT, + , - (unary)high priority
*, / , MOD, DIV, @
+, -
<, >, >=, <=
=, <>
AND
EXOR, ORlow priority
The type of an expression depends on the type of

operands and on the used operators.


Arithmetical Expressions
The operands in arithmetical expressions have to be of

the simple data types CHAR, REAL or INT. Operands of
data type CHAR are implicitly converted to type INT.
The ASCII-value is interpreted as unsigned integer.
The result type of a binary arithmetical Expression is

determined according to the following table:
operand 1operand 2result
INTINTINT, REAL with operator "/"
INTREALREAL
INTCHARINT, REAL with operator "/"
REALINTREAL
REALREALREAL
REALCHARREAL
CHARINTINT, REAL with operator "/"
CHARREALREAL
CHARCHARINT, REAL with operator "/"
A connective of two operands of different data types

leads to a type conversion.
The operands of DIV and MOD have to be of data type

INT or CHAR.

Logical Expressions
Operands of logical expressions have to be of a simple

data type. The result of a comparison is of data type
BOOL.
Operands of the data type CHAR are converted to data

type INT before evaluation.
Using operands of the data types INT and BOOL the

result type of a binary logical Expression is determined
according to the following table:
operand 1operand 2result
BOOLINTnot allowed.
INTINTINT (bit pattern operation)
INTBOOLnot allowed
BOOLBOOLBOOL (logical operation)
The operator NOT carries out the logical negation.

Applied to "0" (FALSE) it yields "1" (TRUE). In all other
cases it yields "0" (FALSE).

Geometric Expressions
In the following definitions of geometric operations the

specified types of operands mean that every expression
being an operand of such an operation will be
automatically converted into this operand type before
performing the operation. This will be done according to
the same rules as used for the cast operators. If the
type of an operand is specified by a cast operator and
this type is not the required operand type then the
implicit type conversion will be done after the
execution of the explicit type conversion specified by
the cast operator. The value of the resulting operand
may differ from the original value of the operand, even
if the required operand type and the type of the original
operand are identical (see example k).
type oftype oftype of
nroperand1operand2resultshort description
operator

1POSITION+POSITIONPOSITIONaddition of two positions
2POSITION-POSITIONPOSITIONsubtraction of positions
3POSITION/REALPOSITIONdivision of all components

with real number
4POSITION*REALPOSITIONmultiplication of all
5REAL*POSITIONPOSITIONposition components with real

number
6ROBTARGET@POSEROBTARGETrelative translation and

rotation
Now the semantic of the last geometric operation will

be defined in more detail.
Relative translation and rotation (symbol '@')
Be RK1 a ROBTARGET type variable and R1R2 a POSE

type variable with RK1 = (RR1,add1) =
((Rori1,Rpos1),add1) = ((RM1,Rpos1),add1) where add1
includes the STATUS TURNS and A_JOINTS components
of RK1 and R1R2 = (R1ori2,R1pos2) = (R1M2,R1pos2),
then the ROBTARGET type result RK3 = (RR3,add3) =
((Rori3,Rpos3),add3) = ((RM3,Rpos3),add3) of the
operation RK1 @ R1R2 is defined by the following three
equations
RM3= RM1 * R1M2
Rpos3= RM1 * R1pos2 + Rpos1
add3= add1.
The first operand is seen as a configuration of the robot

TCP which is translated by the position R1pos2 and
rotated by the orientation R1ori2. These components
are related to the reference system R1 represented by
the pose RR1, so it describes a relative movement of the
robot TCP where the direction and rotation depends on
the actual orientation of the robot TCP.
Examples:
a)Calculating the transformation of a position we can

use the @-operator. Be RR1 a POSE type variable and
R1p a POSITION type variable with RR1 = (Rori1,Rpos1) =
(RM1,Rpos), then the result Rp of the operation
POSITION( RR1 @ R1p) is defined as

Rp= RM1 * R1p + Rpos1,
using normal matrix operations. This operation assumes,

that R1p are the local coordinates of the Point P in
relation to the local coordinate system R1, represented
by the POSE variable. The result are the global
coordinates of the same Point P in relation to the
original reference system R which is also the reference
system of R1.
b)Calculating the result of the rotation of a vector, the

@-operation can also be used because of the intern
conversion from an ORIENTATION to a POSE and the
identity of the necessary matrix operations.
c)Calculating the result of the multiplication of two

transformations it is again possible to use the @-
operator. Be RR1 and R1R2 two POSE type variables with
RR1 = (Rori1,Rpos1) = (RM1,Rpos1) and R1R2 =
(R1ori2,R1pos2) = (R1M2,R1pos2), then the POSE type
result RR2 = (Rori3,Rpos3) = (RM3,Rpos3) of the
operation RR1 @ R1R2 is defined by the following two
equations
RM3= RM1 * R1M2
Rpos3= RM1 * R1pos2 + Rpos1.
This operation assumes, that R1 is a transformation

which describes the position and orientation of a local
coordinate system R1 in relation to the reference
system R, and R2 describes the position and orientation
of another local coordinate system in relation to the
system R1. The result describes the position and
orientation of R2 in direct relation to the original
reference system R.
d)Calculate for a given position R1p, related to

reference system R1, the component values, expressed
in the reference system R2S which is related to its
reference system R2. We want to get Sp, so we have to
form a chain, starting with S and ending in P:
Sp= SR2 @ R2R1 @ R1p

= SR2 @ R2Worldsystem @ WorldsystemR1 @ R1p
= INV(R2S) @ INV(WorldsystemR2) @ WorldsystemR1 @
R1p
e)Calculate the pose S which transfers pose1 in pose2

(pose1 and pose2 refer to the reference system R,
system S refers to pose1); therefore the following
equation must be true:

Rpose1 @ pose1S = Rpose2
This yields: pose1S = INV(Rpose1) @ Rpose2
Calculate the pose S which transfers pose1 in pose2 (all

three systems refer to the reference system R);
therefore the following equation must be true:
RS @ Spose1' = Rpose2
where Spose1' is numerically identic with Rpose1. This

yields:
RS = Rpose2 @ INV(Spose1')
which could be expressed with the numerically identic

expression:
RS = Rpose2 @ INV(Rpose1)
f)Combining the two orientations ori1 and ori2 to a new

orientation ori3, so that POSITION (ori3 @ p) = POSITION
(ori1 @ POSITION (ori2 @ p)) will be true for every
position p, using the assignment
ori3 := ori1 @ ori2
will yield to the correct result where M3 = M1 * M2 using

the implicit and explicit type conversion properties. For
instance the equation ORIXYZ(a,b,c) = ORIXYZ(a,0,0) @
ORIXYZ(0,b,0) @ ORIXYZ(0,0,c) is true. More general the
combination of orientations by "@" corresponds to the
description of an orientation by some rotations each one
related to the resulting reference system after
execution of the rotations given before.
g)Combining the two rotations ori1 and ori2 to a new

rotation ori3, so that rotating any vector p by ori3 to
get p'' is the same as first rotating p by ori1 to get p'
and then rotating p' by ori2 to get p'' (that means p'' =
ori2 @ p' = ori2 @ POSITION (ori1 @ p) = ORIENTATION
(ori2 @ ori1 ) @ p = ori3 @ p) the assignment
ori3 := ori2 @ ori1
will yield to the correct result where M3 = M2 * M1 using

the implicit and explicit type conversion properties. For
instance the equation ORIRS(a,b,c) = ORIRS(0,0,c) @
ORIRS(0,b,0) @ ORIRS(a,0,0) is true. More general the
combination of orientations by "@" with operands in

reverse order corresponds to the description of an

orientation by some rotations all related to the same
reference system.
h)Computing a circular movement with changing gripper

orientation
VAR
INT: i;
ORIENTATION: rot1 := ORIRS(0,0,30);
POSITION: pos1 := rot1 @ (100,0,0);
ARRAY [1..12] OF ROBTARGET: usercircle;
BEGIN
usercircle[1] := R_ROBTARGET_ACT;
FOR i := 2 to 12
usercircle[i] := usercircle[i-1] @ POSE(rot1,pos1);
{here pose does not describe the cast operator but a
record constant }
ENDFOR;
ENDPROGRAM;
i)Computing a circular movement with fixed but

unknown gripper orientation
VAR
INT: i;
POSITION: pos1 := (100,0,0);
ORIENTATION: ori1 := ORIRS(0,0,30);
ARRAY [1..12] OF ROBTARGET: usercircle;
BEGIN
usercircle[1] := R_ROBTARGET_ACT;
FOR i := 2 to 12

usercircle[i] := usercircle[i-1];
pos1 := ori1 @ pos1;
usercircle[i].PSE.POS :=
usercircle[i-1].PSE.POS + pos1;
ENDFOR;
ENDPROGRAM;
j)Calculate the ROBTARGET value K1 for grasping a part

on place 1 with coordinates represented by ps1, using
the tought ROBTARGET value K2 from gripping the same
part with the same gripper on place 2 with coordinates
represented by ps2. Assuming that the relations
between K1 and ps1 and between K2 and ps2 are equal
we can form a chain which is used in the @-expression.
Before that we have to define the additional
components of K1 which here is done by copying the
components of K2.
K1 := K2
K1.PSE := ps1 @ INV(ps2) @ K2.PSE
k)If p1 and p2 are variables of type POSE, where p2 has

a non-zero orientation component, then the result of
the expression
p1 @ POSITION(p2)
differs from the result of the expression
p1 @ p2
because the POSITION type value in the first expression

is expanded by a zero orientation as default to get a
POSE type value before computing the result of the @-
operation.

The operation "ROBTARGET @ POSE = RESULT" covers a

lot of interesting and useful applications:
type of 1sttype of 2ndinterestinginterpretation
operandoperandcomponent of
robtarget
POSEPOSITIONPOSEshifting the POSE with given

POSITION relative to given POSE
POSEPOSITIONPOSITIONshifting the POSITION-component

of the POSE with given POSITION relative to given POSE
(not identical with addition of vectors)
POSITIONPOSEPOSEshifting the POSE with given

POSITION relative to the basis of the given POSE
ORIENTATIONORIENTATIONORIENTATIONcombining two
rotations to a new rotation (see example g))
ORIENTATIONPOSITIONPOSITIONrotation of a vector
POSITIONORIENTATIONPOSEPOSE-Generator
POSITIONPOSITIONPOSITIONaddition of vectors
POSITIONINV(POSITION)POSITIONdifference of vectors

Operators
Operator =
"*" | "/" | "DIV" | "MOD" | "@" |
"+" | "-" |
"<" | ">" | "<=" | ">=" |
"=" | "<>" |
"AND" |
"OR" | "EXOR".
arithmetical operators:
+addition

-subtraction, sign operator
/division
*multiplication
DIVinteger division
MODmodulo function
boolean operators:
ANDlogical and
ORlogical or
NOTlogical not (unary operator, not in syntax rule)
EXORexclusive or
logical operators:
=equal
>greater
<less
<>not equal
>=greater equal
<=less equal
geometric operators:
+addition
-subtraction
/division
*multiplication
@relative translation and rotation



Function Calls
A function call starts the execution of a local or

external function. The actual parameters are passed to
the formal parameters. Parenthesis are necessary even
if no parameters are passed.
CallOrRecord =
Object "(" [ ValueList ] ")".
ValueList =
In this case Object defines the identifier of the

function, therefore this information is necessary
contrary to Record Constant. The Expressions of the
ValueList represent the actual parameters. Therefore
the number and the type of expressions has to
correspond to the formal parameters.
Example:
a:=SIN(X);
b:=DISTANCE(point_1,point_2);
c:=init();

Statements
Construction of Statements
Statement =
[
Assignment |
ProcedureCall |
ProgramflowStatement |
MovementStatement |
I_O_Statement |
ListControlStatement |

ParallelProcessStatement
].
A sequence of statements is called a block.
StatementBlock =
{ LabelIdentifier ":" | Statement ";" }.
Blocks may be empty.
Assignment
Assignment =
Object ":=" Expression.
The Expression has to be assignment compatible to the

left side.
If the data types of both sides are different a type

conversion to the data type of the Object is done
automatically according to the following tables:
= = no typeconversion
x = typeconversion
- = not allowed
simple data typeof object
REALBOOLINTCHAR
of expressionREAL=---
BOOL-=x-
INTxx=x
CHARx-x=
geometric data typeof object
POSITIONORIENTAT.POSEROBTARGET
of expressionPOSITION=-x2x2
ORIENTAT.-=x2x2
POSEx1x1=x2
ROBTARGETx1x1x1=

There is no possible type conversion between simple

data and geometric data types. In the second table the
type conversion follows the same rules as described for
the cast operators. So its not necessary to use the cast
operators for whole expressions on the right hand side
of an assignment statement.
For following non simple types of Expression and of

Object an assignment is allowed (they are then called
assignment compatible):
-if both types are ARRAY types, if the numbers of

elements are identical and if the types of the elements
are assignment compatible.
-if both types are LIST types and if the types of the
elements are assignment compatible. After the
assignment the object list has as many elements as the
list in the right hand side expression had before.
-if both types are RECORD types and if all components

of the records are assignment compatible two by two.
Exception: The predefined data types POSITION and

ORIENTATION are not assignment compatible.
-if both types are FILE types and if the types of

elements are assignment compatible.
-if one or both types are TEACH types and if the proper
types of these teach types are assignment compatible.
-if one or both types are signal types, if the proper

types (type1, type2) are assignment compatible and if
the assignment is one of the following assignments:
Object:=Expression
type2INPUT type1
OUTPUT type2type1
OUTPUT type2INPUT type1



Movement Statements
MovementStatement =
LinearMovement |
PointToPointMovement |
CircleMovement |
BrakeStatement.
Path and PTP Statements
LinearMovement =
( "MOVE" | "MOVE_INC" ) "LIN" ToPoint
ContinuePathParameter.
PointToPointMovement =
( "MOVE" | "MOVE_INC" ) "PTP" ToPoint
PointToPointParameter.
CircleMovement =
( "MOVE" | "MOVE_INC" ) "CIRCLE" Circle
ContinuePathParameter.
ToPoint =
Expression | Path.
Circle =
Expression "," Expression | Path.
Path =
"PATH" [ Expression ":" ]
( Object "[" [ IndexBound ] "]" |
"(" ValueList ")" ).
Note:
All the expressions and the array or list elements shall

be geometric expressions.
The tool center point (TCP) of the industrial robot

moves according to the given interpolation. In
MOVE statements the values of the geometric
expressions and of the array elements are interpreted as
absolute coordinates. The target pose in ToPoint is
always given in dependence upon the base coordinate
system and with respect to the actual tool (R_TOOL).
There are only allowed expressions with the result types

ROBTARGET, MAIN_JOINT, ADD_JOINT or JOINT.
Expressions with the result types POSITION,
ORIENTATION or POSE will be converted into
ROBTARGET values using the components of the
ROBTARGET at the starting point of the actual

movement.
In MOVE_INC statements the values of the geometric

expressions and of the array elements are interpreted as
increments. POSITION, ORIENTATION or POSE
components will be handled as defined for the @-
operation. MAIN_JOINT or ADD_JOINT components will
simply be added to the actual axes values.
Statement without PATH:
In LIN and PTP movements the geometric expression

defines the target position. In CIRCLE movements the
second geometric expression defines the target position.
The coordinates X,Y,Z of the first expression are used as
intermediate point.
Statement with PATH:
Normally the desired path is defined in a list or an one

dimensional array of geometric data type ORIENTATION,
POSITION, POSE, MAIN_JOINT, ADD_JOINT, JOINT or
ROBTARGET. It can also be given as a comma separated
list of values of such geometric expressions. In case of
data types ORIENTATION or POSITION the missing
components are taken from the current position
(R_ROBTARGET_ACT.PSE).
The intermediate points are treated as in statements

without PATH. A type conversion is done from POSE to
ROBTARGET.
The optional geometric expression within the PATH

branch must be of data type POSE. It transforms all the
positions of the array or of the list by "optional
expression" @ PATH.
In the case of LIN or PTP the path is interpolated

according to the statement. Additional parameters and
system variables are valid.
In the case of CIRCLE elements with odd indices define

the coordinates X,Y,Z of the intermediate points and
elements with even indices define the coordinates of
the target position.
The number of points must be even.
The first array or list element is the first point of the

path.
Path smoothing:

Normally the robot stops at the target position. If a path

smoothing parameter is defined the robot will not stop.
The kind of path smoothing depends on the defined
additional parameter (see below).
Additional parameters:
Additional parameters are only valid for the movement

statement in which they are defined (in contrast to the
system variables).
PTP additional parameters:
PTP additional parameters are currently not

supported in COSIMIR and PCROB. Use system
variables (R_C_PTP, ...) instead.
PointToPointParameter =
[ "ACT_ROB" ":=" Expression ]
{
"C_PTP" [ ":=" Expression] |
"C_PASS" |
"SPEED_PTP" [ ":=" Expression ] |
"ACC_PTP" [ ":=" Expression ] |
"TIME" ":=" Expression |
"UNTIL" Expression
[ "ERROR" StatementBlock "ENDERROR" ] |
"ALTER_BY" ProcedureCall
}.
parameterdescription
ACT_ROBSpecification of the desired robot. This is only

active for the actual move command and opens the
scope of the associated predefined record containing
the move parameters. Expression must be an identifier
corresponding to a robot specified by a Robot
Specification. If not an error will occur.
Default: system variable R_ACT_ROB.
C_PTPThe arithmetical expression means the factor (%)

of the axis distance to the intermediate point where the
smoothing starts. For each axis exists a machine
parameter (path smoothing ON/OFF).
Default: system variable R_C_PTP.
C_PASSActivates a path smoothing algorithm that starts

the transition when the next set point is passed through.
Thus all points programmed will definitely be passed.

SPEED_PTPThe arithmetical Expression defines an array

of factors (%) of a given movement speed.
Example: SPEED_PTP := [ 50.0, 50.0, 100.0, 50.0, 50.0,

50.0, 100.0 ];
Default: system variable R_SPEED_PTP.
ACC_PTPThe arithmetical Expression defines an array of

factors (%) of a given movement acceleration.
Default: system variable R_ACC_PTP.
TIMETime for movement
UNTILStop of movement if the logical Expression

becomes true (<>0). In this case the statement block
following "ERROR" is executed if this error handling
exists.
Only SIGNALS are allowed as variables.
ALTER_BYSpecification of an external procedure

controlling the actual movement, for instance by
processing sensor signals. This procedure has to be
declared as EXTERNAL. The use of ordinary IRL
procedures is not possible. The robot control vendor or
if the robot controller allows the implementation of
user specific external routines the user are responsible
for the functionality of the external procedure in
connection with the MovementStatement.
SPEED_PTP and TIME as well as C_PTP and C_PASS are

mutually exclusive.
CP additional parameters:
Some of the CP additional parameters are

currently not supported in COSIMIR and PCROB. Use
system variables (R_C_CP, ...) instead.
ADAX_CONTROL and DEVICE parameters ARE

ContinuePathParameter =
[ "ACT_ROB" ":=" Expression ]
[ "ADAX_CONTROL" ":=" Expression ]
[ "DEVICE" ":=" Expression ]
{
"C_CP" [ ":=" Expression ] |

"C_SPEED" [ ":=" Expression ] |

"SPEED_ORI" [ ":=" Expression ] |
"C_PASS" |
"SPEED" [ ":=" Expression ] |
"ACC" [ ":=" Expression ] |
"TIME" ":=" Expression |
"UNTIL" Expression
[ "ERROR" StatementBlock "ENDERROR" ] |
"WOBBLE" |
"ALTER_BY" ProcedureCall
}.
parameterdescription
ACT_ROBSpecification of the desired robot. This is only

active for the actual move command and opens the
scope of the associated predefined record containing
the move parameters. Expression must be of type
ARRAY OF CHAR or STRING and contains the name of the
robot. If the name does not correspond to a robot
specified in the System Specification a runtime error
will occur.
Default: system variable R_ACT_ROB.
ADAX_CONTROLSpecification of the coordinated

movement with respect to additional axes. The
Expression describes the type of coordinated movement.
The possible values are
NO_ADAX_CONTROL: usual movement without special

coordination
of additional axes
TCP_KEEP: The current position and orientation of the

TCP in world
coordinates is kept. Only the ADD_JOINT component of
ToPoint or
Circle is considered for the movement.
TCP_KEEP_REL: The current position and orientation of

the TCP
relative to the coordinate system of the device given by
DEVICE:=Expression is kept. Only the ADD_JOINT
component of
ToPoint or Circle is considered for the movement.
DEVICE_REL: The movement is executed relative to the

(possibly moving)
coordinate system of the device given by
DEVICE:=Expression.

Default: NO_ADAX_CONTROL
DEVICEDefinition of the device coordinate system for

movements relative to additional axes' by the device
identification (D_NO of the D_SPEC_TYPE type). The
Expression must be of type INT. This parameter can only
be used in conjunction with the ADAX_CONTROL
parameter.
Default: 1 (should be defined in every case)
C_CPThe arithmetical expression means the distance to

the intermediate point where the smoothing starts (path
smoothing ON/OFF).
Default: system variable R_C_CP.
C_SPEEDPath smoothing speed value in % of

programmed speed (path smoothing ON/OFF)
Default: system variable R_C_SPEED.
SPEED_ORIspeed orientation, length of the path must be

zero.
Default: system variable R_SPEED_ORI.
C_PASSActivates a path smoothing algorithm that starts

the transition when the next set point is passed through.
Thus all points programmed will definitely be passed.
SPEEDThe arithmetical Expression defines the

movement speed (path).
Example: SPEED := 350.0;
Default: system variable R_SPEED.
ACCThe arithmetical Expression defines the movement

acceleration (path).
Default: system variable R_ACC.
TIMETime for movement
UNTILStop of movement if the logical Expression

becomes true (<>0). In this case the statement block
following "ERROR" is executed if this error handling
exists.
Only SIGNALS are allowed as variables.
WOBBLEsuperimposed movement
ALTER_BYSpecification of an external procedure

controlling the actual movement, for instance by

processing sensor signals. This procedure has to be
declared as EXTERNAL. The use of ordinary IRL
procedures is not possible. The robot control vendor or
if the robot controller allows the implementation of
user specific external routines the user are responsible
for the functionality of the external procedure in
connection with the MovementStatement.
SPEED and TIME as well as C_CP, C_SPEED and C_PASS

are mutually exclusive.
Examples:
- movement statements:
VAR
INPUT BOOL: alarm AT 1;
ROBTARGET: p1 := ( ( (100.0, 1000.0, 0.0), ORIRS(90.0,

0.0, 90.0) ), 4, 100, 0);
{The last but two entry represents the
RecordComponent Status, this describes the robot
configuration; the last two values represent additional
axes, there is no TURNS component}
ROBTARGET:p2 := ( ( (200.0, 200.0, 10.0), ORIXYZ(90.0,

0.0, 90.0) ), 8, 200, 0);
{the meaning of status is system dependent. For
example number 4 means elbow left and number 8
means elbow right}
BEGIN
MOVE LIN p1; { linear movement to P1 }
p1.status := 8; { change of the configuration: elbow left

to elbow right }
MOVE PTP p1;
MOVE LIN p2 UNTIL alarm; { move to P2, stop

movement, when signal 'alarm' becomes true }
MOVE_INC PTP POSITION(10,30,0);
MOVE PTP R_ROBTARGET_ACT @ POSITION(10,30,0);

{ both commands have the same meaning, shifting the
robot TCP position according as local coordinates
related to the TCP system itself }

MOVE PTP POSITION(20,20,-100) @ R_ROBTARGET_ACT;

{ shifting the robot TCP position according as global
coordinates related to the world coordinate system }
ENDPROGRAM;
- movement with path
DECLOFF;
VAR
ARRAY[1..10] OF ROBTARGET: path1;
LIST OF ROBTARGET: listpath := [p1,p2];
POSE:p3, p4;
BEGIN
MOVE PTP PATH (p1, p2, p3, p4);{ implicit declaration

of p1, p2 as ROBTARGET }
MOVE LIN PATH path1[];
LISTADD p4 TO listpath;
LISTINS p3 INTO listpath AT 3;
MOVE PTP PATH listpath;{results in the same movement

as the first statement of that block}
MOVE CIRCLE PATH path1[3..8];
- Programming of the velocity:
R_SPEED := 100.0;
{ Assumed an overridefactor for the velocity is equal to

1.0 (100%). }
{ An overridefeature of a robot controller is outside the

scope of this standard. }
MOVE LIN corner;{ velocity = 100.0 mm/s }
MOVE LIN home SPEED := 200.0;{ velocity = 200.0

mm/s }
MOVE LIN start_pos;{ velocity = 100.0 mm/s }
{ Assumed an overridefactor for the velocity changed to

0.8 (80%). }
MOVE LIN corner;{ velocity = 80.0 mm/s }
MOVE LIN home SPEED := 200.0;{ velocity = 160.0

mm/s }
MOVE LIN start_pos;{ velocity = 80.0 mm/s }


Brake Statement
The BRAKE statement is currently not supported

in COSIMIR and PCROB.
BrakeStatement =
"BRAKE" ["FAST"].
The BrakeStatement is used to terminate the movement

of the robot within procedures called by interrupts. As
explained with the interrupt statement an interrupt can
stop the program flow within a movement. Usually the
movement would continue during the processing of the
interrupt procedure. To avoid collision the interrupt
procedure should stop any movement with the
BrakeStatement.
If the BrakeStatement is performed without the FAST

keyword the robot will slow down as fast as possible
without leaving the programmed path. If the FAST
keyword is added the robot is stopped abruptly,
probably leaving the path (emergency brake).

Pause Statement

PauseStatement =
"PAUSE" [ Expression ].
The program is halted until the worker sets the signal

'START' of the robot control system.
Expression has to be of type ARRAY OF CHAR or STRING.

If an expression is given it is written to the message line
of control system and deleted after the worker sets the
signal 'START'. If no message line exist the expression is
written to the standard output device (STANDARD_OUT).
Example:
PAUSE 'Please change palette';


Program Halt Statement
ProgramHaltStatement =
"HALT".
The ProgramHaltStatement stops the execution of the

program.


Wait Statement
WaitStatement =
"WAIT"
( Expression "SEC" |
"FOR" Expression
[ "TIMEOUT" Expression "SEC"
[ "ERROR" StatementBlock "ENDERROR" ]
]

).
WAIT SEC: The program is halted for the number of

seconds given in the arithmetical Expression.
WAIT FOR: The program is continued when the logical

Expression has the value true (<>0).
If an additional time is given and if the logical

expression becomes true before this timeout period
ends the program is continued immediately. Otherwise
the statement block following "ERROR" will be executed
before the program execution is continued.
Only WAIT SEC and WAIT FOR are currently

supported in COSIMIR and PCROB.
Example:
WAIT 2.4 SEC;{wait 2.4 sec }


Parallel Processes Statements
ParallelProcessStatement =
ProcessControlStatement |
VariableControlStatement |
GetStatusStatement |
SemaphoreControlStatement.
IRL allows the definition and use of processes that are

executed in parallel with other processes defined within
the program. There are statements controlling the
parallel processes themselves, statements controlling
the variables declared as shared variables and
statements controlling semaphores to synchronize
parallel processes with them.
Controlling parallel processes
ProcessControlStatement =
StartStatement |
StopStatement |

ContinueStatement |
CancelStatement.
Starting a process
A process is started with the StartStatement. If the

process had not been started before it is loaded and
started at the beginning. If it had been started but is
running or stopped by a StopStatement the
StartStatement has no effect. If a process had
terminated itself (by a ReturnStatement or the
ENDPROCESS keyword) or was terminated by the
CancelStatement the process is also started at the
beginning. The ValueList contains the actual parameters
for the process.
StartStatement =
"START" ProcessIdentifier "(" ValueList ")".
Stopping a process
The StopStatement stops the execution of the given

process and of all processes started by the stopped
process (child processes). If no ProcessIdentifier is
specified the process or program which calls the
StopStatement is stopped. A stopped process can be
restarted at any time and at the point it was stopped by
the ContinueStatement.
StopStatement =
"STOP" [ ProcessIdentifier ].
Continuing a process
A stopped process can be continued by the

ContinueStatement. If the process is running or had
been terminated the ContinueStatement has no effect.
Child processes which where running when the process
to be continued had been stopped are also continued.
ContinueStatement =
"CONTINUE" ProcessIdentifier.
Terminating a process
A process can be terminated by the CancelStatement. A

terminated process cannot be continued at the point it
had been stopped. All child processes are terminated as
well. The process is completely deleted, all local
variables are lost and it has to be reloaded to start it
again (the StartStatement does this automatically). If no
ProcessIdentifier is given, all processes are terminated.

CancelStatement =
"CANCEL" [ ProcessIdentifier ].

List Control Statements
Lists are currently not supported in COSIMIR and

PCROB.
ListControlStatement =
ListElementInsertionStatement |
ListElementAddingStatement |
ListElementDeletionStatement |
ListLengthStatement |
ListElementIndexStatement.
ListElementInsertionStatement =
"LISTINS" Expression "INTO" Object "AT" Expression.
ListElementAddingStatement =
"LISTADD" Expression "TO" Object.
ListElementDeletionStatement =
"LISTDEL" Expression "OF" Object.
ListLengthStatement =
"LISTLENGTH" "(" Object "," Object ")".
ListElementIndexStatement =
"LISTINDEX" "(" Object "," Expression "," Object ")".
The first Expression of an

ListElementInsertionStatement and the only Expression
of a ListElementAddingStatement have to be assignment
compatible with the type of the elements of the list.
The second Expression of a
ListElementInsertionStatement or the only Expression of
a ListElementDeletionStatement are used to describe
the index of a list element and so they must be
assignment compatible with INT. In any
ListControlStatement Object has to be of a List Type.
The insertion of a new element given by the first

expression into a list takes place previous to the index

given by the second expression. After insertion the
index of the new element is equal to the given index.
The index can range from 1 up to the actual length of
the list + 1. In the latter case the element insertion has
the same result as adding. If the index is outside that
range a runtime error occurs.
Adding a new list element simply takes place at the end

of the list.
To delete an element of a list the index of that element

has to be given. The index can range from 1 up to the
actual length of the list. In other cases a runtime error
occurs.
To get the actual length of a list the

ListLengthStatement is used. The first Object there
must be a list identifier, the second Object the actual
list length is assigned to must be an identifier of type
INT or CHAR, respectively. With an empty list the result
is zero.
With the ListElementIndexStatement it is possible to get

the value of the index of the first list element which is
equal to the given Expression that has to be assignment
compatible with the type of the list elements. The first
Object in the statement must be a list identifier, the
second Object the index is assigned to must be an
identifier of type INT or CHAR, respectively. If no
equality is found the result is zero.

Synchronized Action Statement
Synchronized actions are currently not

supported in COSIMIR and PCROB.
SynactStatement =
"SYNACT" "WHEN" Expression "DO"
( Assignment | PulseStatement ) [ "DELAY" Expression ].
The SynactStatement (SYNchronized ACTion) serves for

the fast and exact reaction on an event during the

actual robot movement. It must be inserted just before

the MOVE statement to activate the cyclic and parallel
monitoring of the logic condition expressed by the first
Expression.
When the condition becomes true (<>0) the given

Assignment or PulseStatement is executed exactly once
in parallel to the execution of the MOVE statement.
After this or at the end of the movement the monitoring
of the condition stops.
The condition must be a simple logical expression

without function calls or nested expressions,
respectively. It may contain predefined system variables
refering to times or distances. There are predefined
variables refering to the start or to the end point of a
movement.
In addition the optional definition of a time delay of the

event reaction is possible. The second Expression is the
positive or negative time delay given in seconds.
Multiple SynactStatements for one MOVE statement are

allowed but any SynactStatement controls only one
MOVE statement.
Example:
VAR
OUTPUT BOOL: out_5 AT 6;
ROBTARGET: point_1;
...
BEGIN
...
SYNACT WHEN R_DISTANCE_F > 20.0 DO out_5 := TRUE;
MOVE LIN point_1;
...
ENDPROGRAM

Semaphore Types
In COSIMIR/PCROB a SemaphoreTypeDescription
differs in the following way:
SemaphoreTypeDescription =
"SEMA" Identifier.
SemaphoreTypeDeclaration =
SemaphoreTypeDescription ":"
SemaphoreTypeIdentifier.
SemaphoreTypeDescription =
"SEMAPHORE" SimpleType.
The semaphore data type in IRL is dedicated to the

synchronization of multiple processes.
There are two types of semaphores in IRL. Boolean

semaphores that can only be true (=0) or false (<>0) and
integer semaphores with the range of the integer data
type.
SemaphoreType =
SemaphoreTypeIdentifier |
SemaphoreTypeDescription.

Synchronization of Parallel Processes Using Semaphores
SemaphoreControlStatement =
SemaphoreWaitStatement |
SemaphoreSignalStatement.
SemaphoreWaitStatement =
"SEMA_WAIT" "(" Object ["," Expression] ")".
SemaphoreSignalStatement =
"SEMA_SIGNAL" "(" Object ["," Expression] ")".

IRL supports the use of semaphores to synchronize parallel processes. Semaphores

can be of boolean or integer type. They must be initialized in their declaration.
Every semaphore has an associated queue of processes waiting for this semaphore.
This queue may be empty. Processes requesting a semaphore are served according
to a first-in first-out rule. There are two indivisible operations that can be
performed on semaphores the SemaphoreWaitStatement and the
SemaphoreSignalStatement.
The Object in each statement must be of type SemaphoreType. The optional

argument Expression must only be given for integer semaphores not for binary
semaphores and it must be greater than 0. If this argument is given the semaphore
control operation is indivisibly executed Expression times with Expression evaluated
as an integer value. If Expression is missing the operation will be executed once.
The meaning of signalling and waiting are explained in detail for each type of
semaphore.
Binary Semaphores
A process that requests a binary semaphore using the SemaphoreWaitStatement

continues execution if the semaphore has been true (<>0). In the
SemaphoreWaitStatement the value of the semaphore is set to false (=0) and can
only be set to true again by the SemaphoreSignalStatement. If the value of the
semaphore is false while executing the SemaphoreWaitStatement the process is put
into the BLOCKED state and added to the end of the semaphore's queue of
processes waiting for it. Whenever a SemaphoreSignalStatement is executed while
there are waiting processes in the semaphore's queue the first process in the queue
is put into the state RUNNING and removed from the queue but the semaphore's
value stays at false. The semaphore's value will only be changed to true, if the
SemaphoreSignalStatement is executed while the queue is empty.
Example:
...
VAR
SEMAPHORE BOOL: a := FALSE, b := FALSE;
POSE: p;
SENSORDATA: sendata;
...
{ Task A: Sensor-Data processing } { Task B: Robot movements }

... ...
WHILE TRUE WHILE TRUE
{ Read sensor data } .

read_sensor_data(sendata); .
{ Process sensor data } { wait for position }
p := pos_from_data(sendata); SEMA_WAIT a;
{ calculated position available for task { move to position }

B}
MOVE LIN p;
SEMA_SIGNAL a;
{ we are there }
{ wait for position reached }
SEMA_SIGNAL b;
SEMA_WAIT b;
.
ENDWHILE;
.
...
ENDWHILE;
...
Integer Semaphores
Integer semaphores are handled slightly differently than boolean semaphores.

Whenever a process requests an integer semaphore using the
SemaphoreWaitStatement, the Expression will be evaluated to an integer value. If
Expression is missing, it will default to 1. The value of Expression will be
subtracted from the current value of the semaphore and this will become the new
value of the semaphore. If the result is greater or equal than 0 the process will be
continued. If the resulting semaphore's value is less than 0 the process will be put
into the BLOCKED state and added to the end of the semaphore's queue of
processes waiting for it.
Whenever a process executes the SemaphoreSignalStatement the Expression, if

present, will be evaluated to an integer value. If Expression is missing it will
default to 1. The resulting value will be added to the current value of the
semaphore. If there are processes in the semaphore's queue as many processes as
the semaphore's new value will be put into the state RUNNING and for every
process the semaphore's value will be decremented again. All these operations are
executed indivisibly in the SemaphoreSignalStatement.


Interrupt Statement
Interrupts are currently not supported in

COSIMIR and PCROB.
The InterruptStatement is used to instantly react on

certain events, no matter which part of a program is
just executed. The condition within the
InterruptStatement is permanently tested by the robot
control system in parallel with the normal program flow.
When the condition becomes true (<>0) the program
flow is interrupted and the given procedure is called.
The interrupt can even stop the execution within a
statement (e.g. a movement statement) so the
programmer has to be aware, that the movement may
continue during execution of the called interrupt
procedure. If the movement has to be stopped this can
be done with the brake statement within the interrupt
procedure.
After the complete execution of the interrupt procedure

or when the procedure is terminated by a
ReturnStatement the program is continued exactly
where it was interrupted (provided that the interrupt
procedure did not terminate the complete program).
That means the execution of the program will continue
with the execution of the interrupted statement. But if
the interrupted statement is a movement statement and
the interrupt procedure contains a BRAKE or another
movement statement the interrupted statement has not
to be continued. So it depends on the executed
interrupt procedure whether the target point of an
interrupted movement statement was reached or not.
The three system variables R_ROBTARGET_START,
R_ROBTARGET_END and R_ROBTARGET_INTER (they
store the start and target position of the actual
movement statement and the position at the interrupt)
can be used to reconstruct a definite state before
returning from an interrupt procedure.
The programmer has to keep in mind that any interrupt

switched on will charge the control, thus the number of
active user defined interrupts should not become too
large, though this is not restricted by IRL.
The INTERRUPT DECL allows the definition of an

interrupt. This statement does not start the interrupt
processing. The first expression has to be of data type
integer and is used for identification within other
interrupt statements and defines the priority. Thus
interrupts of the same priority are not allowed. The

priority defines the order interrupts are processed in,

the highest priority is 255, the lowest is 0. The priorities
from 128 to 255 are reserved for system interrupts and
may thus not be used for user defined interrupts.
Available system interrupts and their priorities have to
be determined in the documentation of the control in
use. The second expression is the logical expression that
has to become true to start the procedure given in the
ProcedureCall-parameter. Only procedures may be
called (no functions), parameters within the call are
allowed. All variables used in this expression have to be
of global scope. To reduce the time needed by the
control for testing the logical expression, the expression
should be as simple as possible. Nevertheless IRL does
not restrict its complexity.
As mentioned above the INTERRUPT DECL statement

does not activate the interrupt processing. This enables
the programmer to put all interrupt statements at the
beginning of the program to improve readability of the
program. To easily change priorities it is recommended
to define all interrupt identifiers (and priorities) as
integer constants in the declaration part of the program
or in the system declaration. System interrupt
identifiers have to be defined in the system declaration.
InterruptStatement = "INTERRUPT"
("ON" | "OFF" | "ENABLE" | "DISABLE" ) [ Expression ].
The INTERRUPT ON statement activates the interrupt

processing of the interrupt with the identifier given in
the optional expression. If no expression is given all
interrupts defined are activated.
The INTERRUPT OFF statement deactivates the interrupt

processing of the given interrupt. If no expression is
given all interrupts are deactivated. Interrupts occurring
when the interrupt is deactivated are not buffered.
INTERRUPT ENABLE / DISABLE enables or disables the

interrupt processing. Only activated interrupts can be
disabled and only disabled interrupts can be enabled.
The difference between an interrupt switched off and
disabled is, that interrupts occurring in disabled status
are buffered and performed when the interrupt is
enabled again in order of their priority. If no expression
is given, all interrupts are enabled / disabled.

Getting the Status of a Process
GetStatusStatement =
"GETSTATUS" "(" ProcessIdentifier "," Object ")".
The GetStatusStatement returns the actual status of the

given process. As part of the System Specification there
have to be declared integer constants for each process
state. Possible states are:
0= R_PROCESS_READY:the process is ready.

1= R_PROCESS_RUNNING:the process is running.
2= R_PROCESS_STOPPED:the process is stopped.
3= R_PROCESS_BLOCKED:the process is blocked.
The following figure shows all possible states of a

process and the statements controlling the changes
between different states.

Devices and Groups (Additional Axes)
IRL supports additional axes. These additional axes are controlled by the robot
controller and may be for example external devices like positioners or internal
devices like a linear axis (rail) the robot is mounted on. The joint values of these
devices are determined by the A_JOINT component (of type ADD_JOINT) of JOINT
or ROBTARGET variables.
IRL allows only PTP movements of additional axes but it enables the user to
synchronize the movements of the robot and the additional axes in time as well as
kinematically.
To execute a movement synchronized in time a normal MOVE statement with a

ToPoint with an A_JOINT component will be sufficient.
For a movement synchronized in time and in space (kinematically) a MOVE

statement with the ADAX_CONTROL and DEVICE parameters will be used.
For this type of kinematically synchronized movements the specification of a group

of devices, that are moved in a coordinated fashion, is necessary. To allow this,
each device in a cell is described in the system specification using the array

D_DEVICES of R_DEVICE_NUMBER elements of the system data type D_SPEC_TYPE.
Example (exctract from the system specification):
CONST
INT :R_DEVICE_NUMBER := 4;
INT :AX_NONE := -1; { No device }
INT :AX_MAIN := 0; { Main axes (robot) }
INT :ADAX_IS := 1; { Additional axes starting the kinematical chain; e.g. a rail }
INT :ADAX_IE := 2; { Additional axes ending the kinematical chain }
INT :ADAX_EX := 3; { External additional axes; e.g. a positioner }
TYPE
RECORD
INT :D_NO; { Unique identification number of this device; must be >= 0 }
INT :D_AXES_TYPE; { Type of additional axis: AX_MAIN, ADAX_IS, ADAX_IE,

ADAX_EX; for information only }
INT :D_PRED_DEVICE; { Identification number of the preceeding device in the

kinematical chain; -1 if there is no predecessor }
VAR
ARRAY[1..R_DEVICE_NUMBER] OF D_SPEC_TYPE :
D_DEVICES :=
[ (1, ADAX_IS, -1, 1), { a rail }
(2, AX_MAIN, 1, 6), { a 6 axis robot mounted on the
rail }
(3, ADAX_EX, -1, 2), { a 2 axis positioner }
(4, ADAX_EX, -1, 3) { a 3 axis positioner }
]; { all devices }

Furthermore the individual configuration of kinematically coordinated devices is

defined by the R_DEVICES array of the robot specification, which enumerates all
devices that will be considered in movement statements for that group of devices.
In the following example four groups of devices are defined. GROUP_1 and
GROUP_2, based upon the previous example, differ only in the external positioner;
the group POSITIONER_1 comprises only the 2 axis positioner whereas
POSITIONER_2 comprises only the 3 axis positioner:
ROBOT GROUP_1 :=
R_SPEC_TYPE(
...
[ 1 {rail}, 2 {robot}, 3 {2 axis positioner},
...
);
ROBOT GROUP_2 :=
R_SPEC_TYPE(
...
[ 1 {rail}, 2 {robot}, 4 {3 axis positioner},
...
);
ROBOT POSITIONER_1 :=
R_SPEC_TYPE(
...
[ 3 {2 axis positioner},
AX_NONE, AX_NONE, AX_NONE {just to fill up} ],
...
);
ROBOT POSITIONER_2 :=

R_SPEC_TYPE(
...
[ 4 {3 axis positioner},
AX_NONE, AX_NONE, AX_NONE {just to fill up} ],
...
);
Using these definitions we can build the following example, that uses multitasking
to load and unload the two positioners and to do some welding. Task A does the
welding, Task B loads and unloads positioner 1 and Task C (not listed) loads and
unloads positioner 2:
{ Task A: Welding } { Task B: Loading and Unloading 1 }

... ...
{ use the robot together with the 2 axis R_ACT_ROB := POSITIONER_1;

positioner 1 }
WHILE TRUE
R_ACT_ROB := GROUP_1;
{ load positioner 1 }
{ wait for workpiece on positioner 1 }
load_positioner(1);
SEMA_WAIT positioner_1_loaded;
SEMA_SIGNAL positioner_1_loaded;
weld(1); { do welding }
{ wait for welding on 1 done }
SEMA_SIGNAL positioner_1_done;
SEMA_WAIT positioner_1_done;
{ use robot with 3 axis positioner 2 }
unload_positioner(1);
R_ACT_ROB := GROUP_2;
ENDWHILE;
{ wait for workpiece on positioner 2 }
SEMA_WAIT positioner_2_loaded;
weld(2); { do welding }
SEMA_SIGNAL positioner_2_done;
...
Switching between the groups is done by the R_ACT_ROB variable or the ACT_ROB
clause.

Assignment of ADD_JOINT components and device joints:
As the ADD_JOINT system data type comprises all additional axes in a cell, the
manufacturer of the robot controller has to document the assignment of the
components of the ADD_JOINT structure and the devices in the cell. This
assignment will be fixed. In a movement statement only those additional axes will
be moved, that belong to the actual group of devices.
Device "TCP" coordinate systems:
Furthermore the manufacturer has to document the position and orientation of all
device "TCP" coordinate systems, that might be used for relative movements.
Types of coordinated movements:
The ADAX_CONTROL parameter of the movement statements defines the type of

kinematically coordinated movement. There are three types of movements:
NO_ADAX_CONTROL: usual movement without special coordination of additional

axes
TCP_KEEP: The current position and orientation of the TCP in world coordinates is
kept. The addional axes are moved according to the ADD_JOINT component of
ToPoint or Circle. If the movement of the additional axes would move the TCP, the
robot's joints are moved to compensate for that.
TCP_KEEP_REL: The current position and orientation of the TCP relative to the
"TCP" coordinate system of the device given by DEVICE:=Expression is kept. Only
the ADD_JOINT component of ToPoint or Circle is considered for the movement.
This type of movement is useful to re-orient a workpiece on a positioner while
keeping the relative position of the tool towards the workpiece.
DEVICE_REL: The movement is executed relative to the (possibly moving) "TCP"

coordinate system of the device given by DEVICE:=Expression. This type of
movement is intended to move the robot e.g. on a linear path relative to a
workpiece moved by a positioner.
Example:
{ A cell composed of a robot and an external positioner }
{ Extract from the System specification }
CONST
INT : R_DEVICE_NUMBER := 2;
TYPE
RECORD
...

ARRAY[1..R_DEVICE_NUMBER] OF INT: R_DEVICES;
...
ROBOT
ROB_AND_POS := R_SPEC_TYPE(
...
[ 1 {the robot }, 2 { the external positioner } ],
...
);
VAR
{ The robot and the positioner }
ARRAY[1..R_DEVICE_NUMBER] OF D_SPEC_TYPE:
D_DEVICES := [ (1, AX_MAIN, -1, 6) { a 6 axis robot },
(2, ADAX_EX, -1, 3) { a 3 axis external positioner } ];
{--- part of the robot program --- }
VAR
TEACH POSE: start, p1, p2, p3;
ADD_JOINT: pos_start := ADD_JOINT(0.0,0.0,0.0);
TEACH ADD_JOINT: pos_p1, pos_p2, pos_p3;
BEGIN
R_ACT_ROB := ROB_AND_POS;
{ Move the robot and the positioner to the starting position. No kinematical
synchronization }
MOVE PTP ROBTARGET(start,0,[0,0],pos_park);
{ Start welding, while moving the tool relative to the workpiece moved by the
positioner. The robot movement is kinematically synchronized with the movement
of the workpiece. }
start_weld(3.0);

MOVE LIN ROBTARGET(p1,0,[0,0],pos_p1)
ADAX_CONTROL:=DEVICE_REL
DEVICE:=2;
MOVE CIRCLE ROBTARGET(p3,0,[0,0],pos_p3),
ROBTARGET(p3,0,[0,0],pos_p3)
ADAX_CONTROL:=DEVICE_REL
DEVICE:=2;
stop_weld();

Position Data Type
TYPE
RECORD REAL: X,Y,Z ENDRECORD = POSITION;
The predefined data type POSITION is given by three

real numbers, describing the coordinate values in X-, Y-
and Z-direction. The three values will be assigned in a
single way to a record component or can be treated as
an entity.
Assignment to a position variable:
VAR
POSITION: p;
REAL: x := -10.5;
BEGIN
p.X := x;
p.Y := p.Y * 0.5;
p.Z := 2.01;

p := (x,p.y*0.5,2.01);
p := POSITION(100.0,150.0,200.0);
Selection of a component of POSITION:
x := p.X;

Device Specification Type
The Type D_SPEC_TYPE is used to define the devices

that are controlled by the robot controller. These
devices are the robot(s) and all devices that are
controlled via additional axes like rails, positioners
mounted at the robot mounting flange and external
positioners.
Example:
TYPE
RECORD
INT :D_NO; { Unique identification number of this

device; must be >= 0 }
INT :D_AXES_TYPE; { Type of additional axes: AX_MAIN,

ADAX_IS, ADAX_IE, ADAX_EX; for information only }
INT :D_PRED_DEVICE; { Identification number of the

preceding device in the kinematical chain; -1 if there is
no predecessor }
All devices together are described in the Array

D_DEVICES with R_DEVICE_NUMBER elements. To define
groups of devices, that are controlled together by MOVE
statements, the R_SPEC_TYPE is used.


Multi Robot Handling
Multi robot handling is currently not supported

in COSIMIR and PCROB. Use separate programs to
control multiple robots instead.
All robots used within an IRL program must be specified

within the System Specification. The following Robot
Specification can only be used there. It is possible to
use it more than once. The identifier of each robot
within one System Specification must be unique.
RobotSpecification =
"ROBOT" Identifier ":=" CallOrRecord ";".
CallOrRecord has to be a constant of type R_SPEC_TYPE

to initialize the robot specific system parameters.
For every robot declared by a Robot Specification a

record variable of type R_SPEC_TYPE is automatically
declared having an identifier equal to that of the robot
given in the specification. Because this record variable
has to be initialized all the parameters have a defined
value at the beginning of the program.
Even if the controller handles only one robot a Robot

Specification is necessary.
The use of the ACT_ROB clause within a move command

or an assignment to the corresponding system variable
R_ACT_ROB within the statement part of a program
opens the scope of the robot specific record associated
with the used robot identifier. So there is no need to
write e.g. this_robot.R_SPEED if the speed parameter of
this_robot shall be accessed and R_ACT_ROB holds the
value this_robot. Of cause a parameter of any other
robot can be accessed by the normal record selector,
e.g. another_robot.R_SPEED. Furthermore the use of
the ACT_ROB clause or an assignment to the R_ACT_ROB
variable selects the desired robot for the following
move commands.
The use of the ACT_ROB clause or an assignment to

R_ACT_ROB will cause an error if the used expression

does not correspond to an identifier of a robot specified
in the System Specification.
By default R_ACT_ROB holds the value of the first

specified robot and so the corresponding record scope is
open at the beginning of the program execution.

Objects
Objects have a predefined or structured data type.
Object =
Identifier |
ArrayOrListElement |
RecordComponent.
RecordComponent =
Object "." ComponentIdentifier.
ArrayOrListElement =
Object "[" ArrayExpressionList "]".
ArrayExpressionList =
The number of the arithmetical expressions in an

ArrayExpressionList must be equal to the dimension of
the array or list. So in the case of lists or one
dimensional arrays there must be exactly one
Expression. The expressions to index the array or list
elements have to be of data type INT or CHAR,
respectively.
Example:
Given the following declarations:
TYPE
ARRAY [1..5] OF ROBTARGET = position_type;
{ Array with elements of type ROBTARGET }

RECORD
ROBTARGET: p;
REAL: current;
ENDRECORD = spot;{ record type definition }
VAR
ROBTARGET: p1; { variable of record type ROBTARGET }
position_type: pos_array;{ variable of type

position_type }
spot: door; { variable door of record type spot }
In this case the following record components are

correct:
p1.PSE.POS.X{ x component of p1 }
pos_array[1].PSE.POS.X{ x component of the first

element of pos_array }
door.p.PSE.POS
door.p.PSE.POS.X
door.current

Processing Sensor Data in IRL
Except the ALTER_BY-specification in

MovementStatements IRL provides no explicit sensor
signal processing statements.
With the possibility of the declaration of external

functions and procedures and of the definition and use
of parallel processes there are many tools available to
implement a great variety of cell specific, robot specific
or user specific sensor processing tasks. This is true with
computations critical in time (realized by external

procedures or functions) as with very complex

computational task which may be realized by parallel
processes.
On the other hand and because of the great number of

different sensor signals, sensor functions and
parameters influencing the sensor processing it is
impossible to give a useful selection of recommended
routines handling the sensor data processing.

Controlling shared variables
The LOCK and UNLOCK statements are currently

not supported in COSIMIR and PCROB. Semaphores
must be used instead.
The variables controlled by the following statements

have to be declared as shared variables and each
process using a shared variable must include the
declaration of it.
VariableControlStatement =
LockStatement |
UnlockStatement.
Locking variables
LockStatement =
"LOCK" Identifier { "," Identifier }.
The LockStatement enables a process to access the

shared variables or system resources (like robot arms,
serial or parallel interfaces, channels, signals etc.) given
in the identifier list. In the following shared variables
and system resources are called resources. Only one
process a time can lock a certain resource. If a process
has locked a resource (or several resources) all other
processes trying to lock that resource are automatically
stopped until the resource is unlocked. Then the second
process that tried to lock the resource gets the access
and continues. The waiting processes are served in the
order they tried to get access to the resource.

Unlocking variables
UnlockStatement =
"UNLOCK" [ Identifier { "," Identifier } ].
The UnlockStatement returns control over the locked

resources given in the identifier list to the system. The
system then decides, whether another process gets
access to those resources. If the UnlockStatement is
called without any identifier, all resources locked by the
process are unlocked.

Units
velocity (path) [mm/s]
acceleration (path)[mm/(s*s)]
distance [mm]
angle [degree]
time [sec]
velocity (axis) real factor (%) of a maximum value
acceleration (axis)real factor (%) of a maximum value


Ngon Ngu Lap Trinh RBCN

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ngon Ngu Lap Trinh RBCN

Uploaded by

Copyright:

Available Formats

Industrial Robot Language - IRL (DIN 66312) Page 1 of 126

COSIMIR® · Programming Language IRL

Industrial Robot Language

DIN 66312 describes the common construction of a

Programs and Program Parts

System Constants and System Variables

IRL Language Description

Symbols and Identifiers

file://C:\Documents and Settings\Owner\Local Settings\Temp\~hh7635.htm 25/03/2009

Standard Data Types

User Defined Data Types

Geometric Data Types

Program Flow Statements

Parallel Process Statements

COSIMIR® · Programming Language IRL

IRL Language Description

The syntax in this section describes the formation of

The lexical elements of an IRL program are:

The character set is taken from the ISO 646 (7 bits

file://C:\Documents and Settings\Owner\Local Settings\Temp\~hh7635.htm 25/03/2009

interchange) in its current edition.

Outside of strings the case is ignored.

The identifiers HOME, Home, hOme are equivalent.

Symbols and Identifiers

COSIMIR® · Programming Language IRL

The meta language used to describe the syntax of IRL in

file://C:\Documents and Settings\Owner\Local Settings\Temp\~hh7635.htm 25/03/2009

[x]no or one appearance of x

{x}no, one or multiple appearance of x

"xyz"terminal symbol xyz

DecimalConstant, Digit and Exponent are nonterminal

"." is a terminal symbol.

COSIMIR® · Programming Language IRL

Programs and Program Parts

file://C:\Documents and Settings\Owner\Local Settings\Temp\~hh7635.htm 25/03/2009

An IRL program consists of a program declaration part

The program declaration part or the statement part can

{ procedures "moveto" and "operation" for testing}

PROCEDURE moveto ();

ENDPROC;{ end procedure "moveto" }

PROCEDURE operation ();

ENDPROC;{ end procedure "operation" }

operation();{ test of procedure "operation" }

moveto();{ test procedure "moveto" }

Programs can refer to a specification part which

file://C:\Documents and Settings\Owner\Local Settings\Temp\~hh7635.htm 25/03/2009

contains system data.

COSIMIR® · Programming Language IRL

Import- and Export Declarations

Import- and export declarations introduce the objects of

An import declaration defines the program name from

An import declaration or an export declaration is only

FROM magazin IMPORT ALL;

{ all objects of program "magazin" can be imported }

file://C:\Documents and Settings\Owner\Local Settings\Temp\~hh7635.htm 25/03/2009

FROM parts IMPORT start,partnumber;

{ two objects of "parts" }

FROM seek IMPORT x;

{ write "x" in every statement }

EXPORT discharge_x TO charge;

{ "discharge_x" exported to "charge"}

VAR { Declarations of program "discharge": }

VAR INT: local_x;