ngon ngu lap trinh rbcn

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

of 126Industrial Robot Language - IRL (DIN 66312)

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

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

Symbols and Identifiers ©·2000·IRF·EFR·Dortmund


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. ©·2000·IRF·EFR·Dortmund


Import- and Export Declarations

ImportDeclaration = "FROM" ProgramIdentifier "IMPORT" ( "ALL" | ImportIdList ) ";".

ImportIdList = Identifier { "," Identifier }.

ExportDeclaration = "EXPORT" ( "ALL" | ExportIdList ) [ "TO" ProgramIdList ] ";".

ExportIdList = Identifier { "," Identifier }.

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; ©·2000·IRF·EFR·Dortmund


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 = Identifier { "," Identifier }.

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}; ©·2000·IRF·EFR·Dortmund




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 ©·2000·IRF·EFR·Dortmund




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(

POSE(POSITION(100.0,1000.0,0.0),ORIRS(90.0,0.0,90.0)),

0,[0,0],0.0),

ROBTARGET(


0,[0,0],0.0),

ROBTARGET(


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 ©·2000·IRF·EFR·Dortmund


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. ©·2000·IRF·EFR·Dortmund


Predefined Identifiers


Functions



Channels

Constants

Types ©·2000·IRF·EFR·Dortmund


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. ©·2000·IRF·EFR·Dortmund


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 currently supported in COSIMIR and PCROB.


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 ©·2000·IRF·EFR·Dortmund


Types

INTREAL



CHARSTRINGTEXT

BOOL

ORIENTATIONPOSITION

POSEROBTARGET

ADD_JOINTMAIN_JOINT

JOINT ©·2000·IRF·EFR·Dortmund


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. ©·2000·IRF·EFR·Dortmund


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 ©·2000·IRF·EFR·Dortmund


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;

ENDRECORD = R_SPEC_TYPE; ©·2000·IRF·EFR·Dortmund




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 ©·2000·IRF·EFR·Dortmund


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 ©·2000·IRF·EFR·Dortmund


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; ©·2000·IRF·EFR·Dortmund


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; ©·2000·IRF·EFR·Dortmund


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, then b about the new y-axis of the rotated reference 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, then b about the new y-axis of the rotated reference 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; ©·2000·IRF·EFR·Dortmund




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; ©·2000·IRF·EFR·Dortmund


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 ©·2000·IRF·EFR·Dortmund


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). ©·2000·IRF·EFR·Dortmund




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 ) ©·2000·IRF·EFR·Dortmund


Open Statement

I/O for channels and files is currently only supported for the CONSOLE in COSIMIR and PCROB. 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

I/O for channels and files is currently only supported for the CONSOLE in COSIMIR and PCROB. 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}

... ©·2000·IRF·EFR·Dortmund


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 ©·2000·IRF·EFR·Dortmund


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 = Expression { "," Expression }.

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(); ©·2000·IRF·EFR·Dortmund


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 ©·2000·IRF·EFR·Dortmund




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 currently supported in COSIMIR and PCROB.

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 } ©·2000·IRF·EFR·Dortmund


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'; ©·2000·IRF·EFR·Dortmund


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 } ©·2000·IRF·EFR·Dortmund


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 ©·2000·IRF·EFR·Dortmund




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

{ Read sensor data }

...

WHILE TRUE

.



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.

read_sensor_data(sendata);

{ Process sensor data }

p := pos_from_data(sendata);

{ calculated position available for task B }

SEMA_SIGNAL a;

{ wait for position reached }

SEMA_WAIT b;

ENDWHILE;

...

.

{ wait for position }

SEMA_WAIT a;

{ move to position }

MOVE LIN p;

{ we are there }

SEMA_SIGNAL b;

.

.

ENDWHILE;

...





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

Switching between the groups is done by the R_ACT_ROB variable or the ACT_ROB clause.

{ Task A: Welding } { Task B: Loading and Unloading 1 }

...

{ use the robot together with the 2 axis positioner 1 }

R_ACT_ROB := GROUP_1;

{ wait for workpiece on positioner 1 }

SEMA_WAIT positioner_1_loaded;

weld(1); { do welding }

SEMA_SIGNAL positioner_1_done;

{ use robot with 3 axis positioner 2 }

R_ACT_ROB := GROUP_2;

{ wait for workpiece on positioner 2 }

SEMA_WAIT positioner_2_loaded;

weld(2); { do welding }

SEMA_SIGNAL positioner_2_done;

...

...

R_ACT_ROB := POSITIONER_1;

WHILE TRUE

{ load positioner 1 }

load_positioner(1);

SEMA_SIGNAL positioner_1_loaded;

{ wait for welding on 1 done }

SEMA_WAIT positioner_1_done;

unload_positioner(1);

ENDWHILE;



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;

...

ENDRECORD = R_SPEC_TYPE;

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_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 = Expression { "," Expression }.

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 ©·2000·IRF·EFR·Dortmund

