Professional Documents
Culture Documents
CONTENTS
Page
1 Introduction ..................................................................................................................... 15
1.1 Design Objectives................................................................................................... 15
1.2 Language Summary................................................................................................ 15
1.3 Syntax Notation ...................................................................................................... 19
1.4 Error Classification................................................................................................. 20
2 Lexical Elements.............................................................................................................. 21
2.1 Character Set........................................................................................................... 21
2.2 Lexical Units........................................................................................................... 21
2.3 Identifiers................................................................................................................ 22
2.4 Reserved Words ...................................................................................................... 22
2.5 Num Literals ........................................................................................................... 23
2.6 Bool Literals ........................................................................................................... 23
2.7 String Literals ......................................................................................................... 23
2.8 Delimiters ............................................................................................................... 23
2.9 Placeholders............................................................................................................ 24
2.10 Comments............................................................................................................. 24
2.11 Data Types ............................................................................................................ 25
2.12 Scope Rules .......................................................................................................... 26
2.13 Atomic Types........................................................................................................ 26
2.14 Record Types ........................................................................................................ 27
2.15 Alias Types ........................................................................................................... 29
2.16 Data Type Value Classes....................................................................................... 30
2.17 Equal Types .......................................................................................................... 33
2.18 Data Declarations ................................................................................................. 33
2.19 Predefined Data Objects ....................................................................................... 34
2.20 Scope Rules .......................................................................................................... 34
2.21 Storage Class ........................................................................................................ 35
2.22 Variable Declarations............................................................................................ 35
2.23 Persistent Declarations ......................................................................................... 36
2.24 Constant Declarations........................................................................................... 37
3 Expressions ...................................................................................................................... 39
3.1 Constant Expressions.............................................................................................. 40
3.2 Literal Expressions ................................................................................................. 40
3.3 Conditional Expressions ......................................................................................... 40
3.4 Literals .................................................................................................................... 41
1 Introduction
This manual contains a formal description of the ABB Robotics robot programming
language RAPID.
Task - Modules
RAPID distinguishes between task modules and system modules. A task module is con-
sidered to be a part of the task/application while a system module is considered to be
a part of the “system”. System modules are automatically loaded to the task buffer dur-
ing system start-up and are aimed to (pre)define common, system specific data objects
(tools, weld data, move data ..), interfaces (printer, logfile ..) etc.
While small applications usually are contained in a single task module (besides the sys-
tem module/s), larger applications may have a "main" task module that in turn refer-
ences routines and/or data contained in one or more other, "library" task modules.
One task module contains the entry procedure of the task. Running the task really
means that the entry routine is executed. Entry routines must be parameterless.
Routines
There are three types of routines - functions, procedures and traps. A function returns
a value of a specific type and is used in expression context. A procedure does not return
any value and is used in statement context. Trap routines provide a means to respond
to interrupts. A trap routine can be associated with a particular interrupt and is then later
automatically executed if that interrupt occurs.
User (defined) routines are defined using RAPID declarations while predefined rou-
tines are supplied by the system and always available.
User Routines
An RAPID routine declaration specifies the routine name, routine parameters, data dec-
larations, statements and possibly a backward handler or/and error handler.
Predefined Routines
There are two types of predefined routines - built-in routines and installed routines.
Built-in routines (like arithmetic functions) are a part of the RAPID language while in-
stalled routines are application/equipment dependent routines used for the control of
the robot arm, grippers, sensors etc. Note that from the users point of view there is no
difference between built-in routines and installed routines.
Data Objects
There are four types of data objects - constants, variables, persistents and parameters.
A persistent (data object) can be described as a "persistent" variable. While a variable
value is lost (re-initialized) at the beginning of each new session - at module load (mod-
ule variable) or routine call (routine variable) - a persistent keeps its value between ses-
sions. Data objects can be structured (record) and dimensioned (array, matrix etc.).
Statements
A procedure call invokes the execution of a procedure after associating any arguments
with corresponding parameters of the procedure. RAPID supports late binding of pro-
cedure names.
The goto statement causes the execution to continue at a position specified by a label.
The connect statement is used to allocate an interrupt number and associate it with a
trap (interrupt service) routine.
The retry and trynext statements are used to resume evaluation after an error.
The if and test statements are used for selection. The if statement allows the selection
of a statement list based on the value of a condition. The test statement selects one (or
none) of a set of statement lists, depending on the value of an expression.
The for and while statements are used for iteration. The for statement repeats the eval-
uation of a statement list as long as the value of a loop variable is within a specified
value range. The loop variable is updated (with selectable increment) at the end of each
iteration. The while statement repeats the evaluation of a statement list as long as a con-
dition is met. The condition is evaluated and checked at the beginning of each iteration.
Backward Execution
Error Recovery
The occurrence of a runtime detected error causes suspension of normal program exe-
cution. The control may instead be passed to a user provided error handler. An error
handler may be included in any routine declaration. The handler can obtain informa-
tion about the error and possibly take some actions in response to it. If desirable, the
error handler can return the control to the statement that caused the error (retry) or to
the statement after the statement that caused the error (trynext) or to the point of the
call of the routine. If further execution is not possible, at least the error handler can as-
sure that the task is given a graceful abortion.
Interrupts
Data Types
Any RAPID object (value, expression, variable, function etc.) has a data type. A data
type can either be a built-in type or an installed type (compare installed routines) or a
user-defined (defined in RAPID) type. Built-in types are a part of the RAPID language
while the set of installed or user-defined types may differ from site to site. From the
users point of view there is no difference between built-in, installed and user-defined
types. There are three different kinds of types - atomic types, record types and alias
types. The definition of an atomic type must be built-in or installed, but a record or alias
type could also be user-defined.
Atomic types are "atomic" in the sense that they are not defined upon any other type
and they cannot be divided into parts or components. Record types are built up by a set
of named, ordered components. An alias type is by definition equal to another type. Ali-
as types make it possible to classify data objects.
In addition to the atomic, record or alias classification of types, each type has a value
class. There are three value classes of types - value types, nonvalue types and semivalue
types. An object of value type is simply considered to represent some form of "value"
(e.g, 3.55 or "John Smith"). A nonvalue (type) object instead represents a hidden/en-
capsulated description of some physical or logical object, e.g. a file. Semivalue objects
are somewhat special. They really have two types, one "basic" nonvalue type and one
associated value type that may be used to represent some property of the nonvalue type.
The built-in atomic types are bool, num and string. Bool is an enumerated type with the
value domain {TRUE, FALSE} and provides a means of performing logical and rela-
tional computations. The num type supports exact and approximate arithmetic compu-
tations. The string type represents character sequences.
The built-in record types are pos, orient and pose. The pos type represents a position in
space (vector). The orient type represents an orientation in space. The pose type repre-
sents a coordinate system (position/orientation combination).
The built-in alias types are errnum and intnum. Errnum and intnum are both aliases for
num and are used to represent error and interrupt numbers.
The concept of installed types supports the use of installed routines by making it pos-
sible to use appropriate parameter types. An installed type can be either an Atomic,
Record or Alias type.
The user-defined types make it easier to customise an application program. They also
make it possible to write a RAPID program which is more readable.
Placeholders
- Static errors
- Execution errors
Static errors are detected either when a module is loaded into the task buffer (see 9) or
prior to program execution after program modification.
The error handler concept of RAPID makes it possible to recover from nonfatal execu-
tion errors. Refer to 7.
2 Lexical Elements
This chapter defines the lexical elements of RAPID.
- identifiers
- reserved words
- literals
- delimiters
- placeholders
- comments
Tokens are indivisible. Except for string literals and comments, space must not occur
within tokens.
An identifier, reserved word or numeric literal must be separated from a trailing, adja-
cent identifier, reserved word or numeric literal by one or more space, tab, formfeed or
newline characters. Other combinations of tokens may by separated by one or more
space, tab, formfeed or newline characters.
2.3 Identifiers
Identifiers are used for naming objects.
<identifier> ::=
<ident>
| <ID>
<ident> ::= <letter> {<letter> | <digit> | ’_’}
A num literal must be in the range specified by the ANSI IEEE 754-1985 standard (sin-
gle precision) float format.
The possibility to use character codes provides a means to include non printable char-
acters (binary data) in string literals. If a back slash or double quote character should
be included in a string literal it must be written twice.
2.8 Delimiters
A delimiter is one of the following characters:
{ } ( ) [ ] , . = < > + - * / : ; ! \ ?
2.9 Placeholders
Placeholders can be used by Offline and Online programming tools to temporarily rep-
resent "not yet defined" parts of an RAPID program. A program that contains place-
holders is syntactically correct and may be loaded to (and saved) from the task buffer.
If the placeholders in an RAPID program do not cause any semantic errors (see 1.4),
such a program can even be executed, but any placeholder encountered causes an exe-
cution error (see 1.4). RAPID recognizes the following 13 placeholders:
2.10 Comments
A comment starts with an exclamation point and is terminated by a newline character.
A comment can never include a newline character.
Comments have no effect on the meaning of an RAPID code sequence, their sole pur-
pose is the enlightenment of the reader.
Each RAPID comment occupies an entire source line and may occur either as:
Comments located between the last data declaration (see 2.18) and the first routine dec-
laration (see 5) of a module are regarded to be a part of the routine declaration list.
Comments located between the last data declaration and the first statement of a routine
are regarded to be a part of the statement list (see 4.2).
Built-in types are part of the RAPID language while the set of installed or user-defined
types may differ from site to site. Please refer to site specific documentation. The con-
cept of installed types supports the use of installed routines by making it possible to
use appropriate parameter types. The user-defined types make it possible to prepare
understandable and easy programmable application packets for the application engi-
neer. From the users point of view there is no difference between built-in, installed and
user-defined types.
There are three different kinds of types - atomic types, record types and alias types.
Type definitions can occur in the heading section of modules (see 9).
The optional local directive classifies the data object being local, otherwise global (see
2.20).
A user-defined type is always defined inside a module. The following scope rules are
valid for module type definitions:
- The scope of a local module type definition comprises the module in which it is
contained.
- The scope of a global module type definition in addition comprises any other
module in the task buffer.
- Within its scope a module type definition hides any predefined type with the
same name.
- Within its scope a local module type definition hides any global module type
with the same name.
- Two module objects declared in the same module may not have the same name.
- Two global objects declared in two different modules in the task buffer may not
have the same name.
Num Type
A num object represents a numeric value. The num type denotes the domain specified
by the ANSI IEEE 754-1985 standard (single precision) float format.
Within the subdomain -8388607 to (+)8388608, num objects may be used to represent
integer (exact) values. The arithmetic operators +, -, and * (see 3.11) preserves integer
representation as long as operands and result are kept within the integer subdomain of
num.
Bool Type
The bool type denotes the domain of twovalued logic - { TRUE, FALSE }.
String Type
The string type denotes the domain of all sequences of graphical characters (ISO 8859-
1) and control characters (non ISO 8859-1 characters in the numeric code range 0 ..
255). A string may consist of 0 to 80 characters (fixed 80 characters storage format).
A specific component of a record data object can be accessed by using the name of the
component.
Unless otherwise stated the domain of a record type is the cartesian product of the do-
mains of its components.
Pos Type
A pos object represents a vector (position) in 3D space. The pos type has three compo-
nents:
[ x, y, z ]
Orient Type
An orient object represents an orientation (rotation) in 3D space. The orient type has
four components:
Pose Type
A pose object represents a 3D frame (coordinate system) in 3D-space. The pose type
has two components:
[ trans, rot ]
Note that one alias type cannot be defined upon another alias type.
The built-in alias types are errnum and intnum - both aliases for num.
Errnum Type
The errnum type is an alias for num and is used for the representation of error numbers.
Intnum Type
The intnum type is an alias for num and is used for the representation of interrupt num-
bers.
An object of value type is simply considered to represent some form of "value" (e.g. 5,
[10, 7, 3.25], "John Smith", TRUE). A nonvalue (type) object instead represents a hid-
den/encapsulated description (descriptor) of some physical or logical object, e.g. the
iodev (file) type.
The content ("value") of nonvalue objects can only be manipulated using installed rou-
tines ("methods"). Nonvalue objects may in RAPID programs only be used as argu-
ments to var or ref parameters.
Semivalue objects are somewhat special. They really have two types, one "basic" non-
value type and one associated (value) type that may be used to represent some property
of the nonvalue type. RAPID views a semivalue object as a value object when used in
value context (se table below) and a nonvalue object otherwise. The semantics (mean-
ing/result) of a read or update (value) operation performed upon a semivalue type is
defined by the type itself.
Note that a semivalue object (type) can reject either reading or updating "by value".
The table below shows which combinations of object usage and type value class that
are possibly legal and which are impossible/illegal:
X Legal/Possible
--- Illegal/Impossible Data type Value class
Object Declarations value nonvalue semivalue
Constant X ---
Persistent X ---
Routine Parameter
in X --- ---
var X X X
pers X --- ---
ref (only installed routines) X X X
inout:
var X --- ---
pers X --- ---
Assignment X X3 X3)
The basic value types are the built-in atomic types num, bool and string. A record type
with all components being value types is itself a value type, e.g the built-in types pos,
orient and pose. An alias type defined upon a value type is itself a value type, e.g. the
built-in types errnum and intnum.
A record type having at least one semivalue component and all other components have
value type is itself a semivalue type. An alias type defined upon a semivalue type is it-
self a semivalue type.
All other types are nonvalue types, e.g record types with at least one nonvalue compo-
nent and alias types defined upon nonvalue types.
Arrays have the same value class as the element value class.
- Both objects have the same type name (any alias type name included is first
replaced by its definition type).
- One of the objects is an aggregate (array or record) and the types of (all) corre-
sponding elements/components are equal.
- One of the objects has a value type, the other object has a semivalue type and
the type of the first object and the associated type of the semivalue object are
equal. Note that this is only valid in value context.
Data declarations can occur in the heading section of modules (see 9) and routines (see
5).
The optional local directive classifies the data object being local, otherwise global (see
2.20). Note that the local directive only may be used at module level (not inside a rou-
tine).
A data object declared outside any routine is called a module data object (module var-
iable, module constant or persistent). The following scope rules are valid for module
data objects:
- The scope of a local module data object comprises the module in which it is con-
tained.
- The scope of a global module data object in addition comprises any other mod-
ule in the task buffer.
- Within its scope a module data object hides any predefined object with the same
name.
- Within its scope a local module data object hides any global module object with
the same name.
- Two module objects declared in the same module may not have the same name.
- Two global objects declared in two different modules in the task buffer may not
have the same name.
- A global data object and a module may not share the same name.
A data object declared inside a routine is called a routine data object (routine variable
or routine constant). Note that the concept of routine data objects in this context also
comprises routine parameters (see 5.1).
The following scope rules are valid for routine data objects:
- The scope of a routine data object comprises the routine in which it is con-
tained.
- Within its scope a routine data object hides any predefined or user defined
object with the same name.
- Two routine data objects declared in the same routine may not have the same
name.
- A routine data object may not have the same name as a label declared in the
same routine.
- Refer to 5 and 9 for information on routines and task modules.
Constants, persistents and module variables are static. The memory needed to store the
value of a static data object is allocated when the module that declares the object is
loaded (see 9). This means that any value assigned to a persistent or a module variable
always remains unchanged until the next assignment.
Routine variables (and in parameters, see 5.1) are volatile. The memory needed to store
the value of a volatile object is allocated first upon the call of the routine in which the
declaration of the variable is contained. The memory is later deallocated at the point of
the return to the caller of the routine. This means that the value of a routine variable is
always undefined before the call of the routine and is always lost (becomes undefined)
at the end of the execution of the routine.
In a chain of recursive routine calls (a routine calling itself directly or indirectly) each
instance of the routine receives its own memory location for the "same" routine varia-
ble - a number of instances of the same variable are created.
Variables of any type (including installed types) can be given an array (of degree 1, 2
or 3) format by adding dimension information to the declaration. The dimension ex-
pression must represent an integer value (see ) greater than 0.
Variables with value types (see 2.16) may be initialized (given an initial value). The
data type of the constant expression used to initialize a variable must be equal to the
variable type.
Persistents of any type (including installed types) can be given an array (of degree 1, 2
or 3) format by adding dimension information to the declaration. The dimension ex-
pression must represent an integer value (see ) greater than 0.
e.g. ! 2 x 2 matrix
PERS num grid{2, 2} := [[0, 0], [0, 0]];
Persistents must be initialized (given an initial value). The data type of the literal ex-
pression used to initialize a persistent must be equal to the persistent type. Note that an
update of the value of a persistent automatically leads to an update of the initialization
expression of the persistent declaration.
MODULE ...
PERS pos refpnt := [100.23, 778.55, 1183.98];
...
refpnt := [x, y, z];
...
ENDMODULE
A constant of any type (including installed types) can be given an array (of degree 1,
2 or 3) format by adding dimensioning information to the declaration. The dimension
expression must represent an integer value (see ) greater than 0. The data type of the
constant value must be equal to the constant type.
3 Expressions
An expression specifies the evaluation of a value. An expression can be represented by
the placeholder <EXP>.
<expression> ::=
<expr>
| <EXP>
<expr> ::= [ NOT ] <logical term> { ( OR | XOR ) <logical term> }
<logical term> ::= <relation> { AND <relation> }
<relation> ::= <simple expr> [ <relop> <simple expr> ]
<simple expr> ::= [ <addop> ] <term> { <addop> <term> }
<term> ::= <primary> { <mulop> <primary> }
<primary> ::=
<literal>
| <variable>
| <persistent>
| <constant>
| <parameter>
| <function call>
| <aggregate>
| ’(’ <expr> ’)’
<relop> ::= ’<’ | ’<=’ | ’=’ | ’>’ | ’>=’ | ’<>’
<addop> ::= ’+’ | ’-’
<mulop> ::= ’*’ | ’/’ | DIV | MOD
The relative priority of the operators determines the order in which they are evaluated.
Parentheses provide a means to override operator priority. The rules above imply the
following operator priority:
An operator with high priority is evaluated prior to an operator with low priority. Op-
erators of the same priority are evaluated from left to right.
The left operand of a binary operator 1) is evaluated prior to the right operand. Note that
the evaluation of expressions involving AND and OR operators is optimised so that the
right operand of the expression will not be evaluated if the result of the operation can
be determined after the evaluation of the left operand.
- Variables, Persistents
- Function calls
3.4 Literals
A literal is a lexical element (indivisible) that represents a constant value of a specific
data type.
3.5 Variables
Depending on the type and dimension of a variable it may be referenced in up to three
different ways. A variable reference may mean the entire variable, an element of a var-
iable (array) or a component of a variable (record).
<variable> ::=
<entire variable>
| <variable element>
| <variable component>
A variable reference denotes, depending on the context, either the value or the location
of the variable.
Entire Variable
If the variable is an array the reference denotes all elements. If the variable is a record
the reference denotes all components. Note that the placeholder <ID> (see 2.3) cannot
be used to represent an entire variable.
Variable Element
An array variable element is referenced using the index number of the element.
An index expression must represent an integer value (see ) greater than 0. Index value
1 selects the first element of an array. An index value may not violate the declared di-
mension. The number of elements in the index list must fit the declared degree (1, 2 or
3) of the array.
Variable Component
Note that the placeholder <ID> (see 2.3) cannot be used to represent a component
name.
3.6 Persistents
A persistent reference may mean the entire persistent, an element of a persistent (array)
or a component of a persistent (record).
<persistent> ::=
<entire persistent>
| <persistent element>
| <persistent component>
The rules concerning persistent references comply with the rules concerning variable
references (see , and respectively).
3.7 Constants
A constant reference may mean the entire constant, an element of a constant (array) or
a component of a constant (record).
<constant> ::=
<entire constant>
| <constant element>
| <constant component>
The rules concerning constant references comply with the rules concerning variable
references (see , and respectively).
3.8 Parameters
A parameter reference may mean the entire parameter, an element of a parameter (ar-
ray) or a component of a parameter (record).
<parameter> ::=
<entire parameter>
| <parameter element>
| <parameter component>
The rules concerning parameter references comply with the rules concerning variable
references (see , and respectively).
3.9 Aggregates
An aggregate denotes a composite value, i.e. an array or record value. Each aggregate
member is specified by an expression.
The data type of an aggregate is (must be able to be) determined by the context. The
data type of each aggregate member must be equal to the type of the corresponding
member of the determined type.
The arguments of a function call is used to transfer data to (and possibly from) the
called function. Arguments are evaluated from left to right. The data type of an argu-
ment must be equal to the type of the corresponding parameter (see 5.1) of the function.
An argument may be either required, optional or conditional. Optional arguments may
be omitted but the order of the (present) arguments must be the same as the order of the
parameters. Two or more parameters may be declared to mutually exclude each other,
in which case at most one of them may be present in the argument list. Conditional ar-
guments are used to support smooth propagation of optional arguments through chains
of routine calls.
A required argument is separated from a preceding (if any) argument by ",". The param-
eter name may be included, or left out.
An optional or conditional argument is preceded by ’\’ and the parameter name. The
specification of the parameter name is mandatory. Switch (See 5.1) type arguments are
somewhat special; they are used only to signal presence (of an argument). Switch ar-
guments do therefore not include any argument expression. Switch arguments may be
propagated using the conditional syntax.
.. is interpreted as
The concept of conditional arguments thus eliminates the need for multiple "versions"
of routine calls when dealing with propagation of optional parameters.
More than one conditional argument may be used to match more than one alternative
of mutually excluding parameters (see 5.1). In that case at most one of them may be
"present" (may refer a present optional parameter).
The parameter list (see 5.1) of a function assigns each parameter an access mode. The
access mode of a parameter puts restrictions on a corresponding argument and speci-
fies how RAPID transfers the argument. Please refer to 5 for the full description on
routine parameters, access modes and argument restrictions.
3.11 Operators
The tables below view the available operators divided into 4 classes:
- Multiplying operators
- Adding operators
- Relational operators
- Logical operators
The tables specify the legal operand types and the result type of each operator. Note
that the relational operators = and <> are the only operators valid for arrays. The use of
operators in combination with operands of types not equal to (see 2.17) the types spec-
ified below will cause a type error (see 1.4).
Multiplication Operators
1) Preserves integer (exact) representation (see ) as long as operands and result are kept within the integer subdomain of the num type.
2) Must represent an integer (see ) value.
3) Must represent a positive (≥ 0) integer value.
Addition Operators
1) The result receives the same data type as the operand. If the operand has an alias data type (see 2.15) the result receives the alias "base"
type (num or pos).
2) Preserves integer (exact) representation (see ) as long as operands and result are kept within the integer subdomain of the num type.
Relational Operators
1) Only value and semivalue data types (see 2.16). Operands must have equal types.
Logical Operators
4 Statements
The concept of using installed routines (and types) to support the specific needs of the
IRB application programmer has made it possible to limit the number of RAPID state-
ments to a minimum. The RAPID statements support general programming needs and
there are really no IRB specific RAPID statements. Statements may only occur inside
a routine definition.
<statement> ::=
<simple statement>
| <compound statement>
| <label>
| <comment>
| <SMT>
Both routines and compound statements contain statement lists. There are no specific
statement list separators. The beginning and end of a statement list is determined by the
context.
e.g. next:
..
GOTO next;
The procedure (name) may either be statically specified by using an identifier (early
binding) or evaluated during runtime from a (string type) expression (late binding).
Even though early binding should be considered to be the "normal" procedure call
form, late binding sometimes provides very efficient and compact code.
Note that late binding is available for procedure calls only, not for function calls.
The general rules concerning the argument list of the procedure call are exactly the
same as those of the function call. Please refer to 3.10 and 5 for more details.
Normally the procedure reference is solved (bind) according to the normal scope
rules, but late binding provide a way to do a deviation from that rule.
The string expression in the statement %<expression>% is in the normal case a string
with the name of a procedure found according to the scope rules, but the string could
also have an enclosing description prefix that specify the location of the routine.
"name1:name2" specify the procedure "name2" inside the module "name1" (note that
the procedure "name2" could be declared local in that module). ":name2" specify the
global procedure "name2" in one of the task modules, this is very useful when a down-
wards call must be done from the system level (installed built in object).
e.g. next:
i := i + 1;
..
GOTO next;
The expression type must be equal to the type of the function. Return statements in pro-
cedures and traps must not include the return expression.
A raise statement that includes an explicit error number raises an error with that
number. The error number (see 7) expression must represent an integer value (see ) in
the range from 1 to 90. A raise statement including an error number must not appear in
the error handler of a routine.
A raise statement with no error number may only occur in the error handler of a routine
and raises again (reraises) the same (current) error at the point of the call of the routine,
i.e. propagates the error. Since a trap routine can only be called by the system (as a re-
sponse to an interrupt), any propagation of an error from a trap routine is made to the
system error handler (see 7).
Task termination using the exit statement, unlike returning from the entry routine of the
task, in addition prohibits any attempt from the system to automatically restart the task.
The retry statement can only appear in the error handler of a routine.
e.g. ...
! open logfile
open \append, logfile, "temp.log";
...
ERROR
IF ERRNO = ERR_FILEACC THEN
! create missing file
create "temp.log";
! resume execution
RETRY;
ENDIF
! propagate "unexpected" error
RAISE;
ENDFUNC
The trynext statement can only appear in the error handler of a routine.
e.g. ...
! Remove the logfile
delete logfile;
...
ERROR
IF ERRNO = ERR_FILEACC THEN
! Logfile already removed - Ignore
TRYNEXT;
ENDIF
! propagate "unexpected" error
RAISE;
ENDFUNC
The connect target must have num (or alias for num) type and must be (or represent) a
module variable (not a routine variable). If a parameter is used as connect target it must
be a VAR or INOUT/VAR parameter - see 5.1). An allocated interrupt number cannot
be "disconnected" or connected with another trap routine. The same connect target may
not be associated with the same trap routine more than once. This means that the same
connect statement may not be executed more than once and that only one of two iden-
tical connect statements (same connect target and same trap routine) may be executed
during a session. Note though, that more than one interrupt number may be connected
with the same trap routine.
TRAP high_pressure
close_valve\fast;
RETURN;
ENDTRAP
4.13 If Statement
The if statement evaluates one or none of a number of statement lists, depending on the
value of one or more conditional expressions.
The conditional expressions are evaluated in succession until one of them evaluates to
true. The corresponding statement list is then executed. If none of them evaluates to
true the (optional) else clause is executed. The placeholder <EIT> can be used to rep-
resent an undefined elseif clause.
Initially the from, to and step expressions are evaluated and their values are kept. They
are evaluated only once. The loop variable is initiated with the from value. If no step
value is specified it defaults to 1 (or -1 if the range is descending).
Before each new (not the first) loop, the loop variable is updated and the new value is
checked against the range. As soon as the value of the loop variable violates (is outside)
the range the execution continues with the subsequent statement.
The from, to and step expressions must all have num (numeric) type.
The conditional expression is evaluated and checked before each new loop. As soon as
it evaluates to false the execution continues with the subsequent statement.
Each statement list is preceded by a list of test values, specifying the values for which
that particular alternative is to be selected. The test expression can have any value or
semivalue data type (see 2.16). The type of a test value must be equal to the type of the
test expression. The execution of a test statement will choose one or no alternative. In
case more than one test value fits the test expression only the first is recognized. The
placeholder <CSE> can be used to represent an undefined case clause.
The optional default clause is evaluated if no case clause fits the expression.
5 Routine Declarations
A routine is a named carrier of executable code. A user routine is defined by an RAPID
routine declaration. A predefined routine is supplied by the system and is always avail-
able. There are three types of routines - procedures, functions and traps. A function re-
turns a value of a specific type and is used in expression context (see 3.10). A procedure
does not return any value and is used in statement context (see 4.5). Trap routines pro-
vide a means to respond to interrupts (see 8). A trap routine can be associated with a
specific interrupt (using the connect statement - see 4.12) and is then later automatically
executed if that particular interrupt occurs. A trap routine can never be explicitly called
from RAPID code. A routine declaration can be represented by the placeholder
<RDN>.
- Name
- Data Type (only valid for functions)
- Parameters (not for traps)
- Data Declarations and Statements (body)
- Backward Handler (only valid for procedures)
- Error Handler
Routine declarations may only occur in the last section of a module (see 9). Routine
declarations cannot be nested, i.e. it is not possible to declare a routine inside a routine
declaration.
The optional local directive of a routine declaration classifies a routine to be local, oth-
erwise it is global (see 5.2).
The data type of an argument must be equal to the data type of the corresponding pa-
rameter.
Each parameter has an access mode. Available access modes are in (default), var, pers,
inout and ref 1).The access mode specifies how RAPID transfers a corresponding argu-
ment to a parameter:
1. RAPID routines cannot have ref parameters, only predefined routines can.
X Legal argument
--- Illegal argument Access mode
in var pers inout ref
constant X X
readonly variable 1 X X
variable X X X X
Argument
persistent X X X X
parameter:
in X X --- X X
var X X --- X X
pers X --- X X X
inout:
var X X --- 2 X X
pers X ---2 X X X
1. e.g. FOR loop variables (see 6.15), errno, intno (see C Appendix:).
2. Execution error (see 1.4).
The built-in routines ’IsPers’ and ’IsVar’ can be used to test if an inout parameter is an
alias for a variable or persistent argument.
The special type ’switch’ may (only) be assigned to optional parameters and provides
a means to use "switch arguments", i.e. arguments given only by their names (no val-
ues). The domain of the switch type is empty and no value can be transferred to a
switch parameter. The only way to use a switch parameter is to check its presence using
the predefined function Present, or to pass it as an argument in a routine call.
Arrays may be passed as arguments. The degree of an array argument must comply
with the degree of the corresponding parameter. The dimension of an array parameter
is "conformant" (marked by ’*’). The actual dimension is later bound by the dimension
of the corresponding argument of a routine call. A routine can determine the actual di-
mension of a parameter using the predefined function ’Dim’.
- The scope of a local user routine comprises the module in which it is contained.
- The scope of a global user routine in addition comprises any other module in
the task buffer.
- Within its scope a user routine hides any predefined object with the same name.
- Within its scope a local user routine hides any global module object with the
same name.
- Two module objects declared in the same module may not have the same name.
- Two global objects declared in two different modules in the task buffer may not
have the same name.
- A global user routine and a module may not share the same name.
The scope rules concerning parameters comply with the scope rules concerning routine
variables. Refer to 2.20 for information on routine variable scope.
Note that a data declaration list can include comments (see 2.10).
Procedures which are going to be used in late binding calls are treated as a special case.
I.e. the parameters for the procedures, which are called from the same late binding
statement, should be matching as regards optional/required parameters and mode, and
should also be of the same basic type. E.g. if the second parameter of one procedure is
required and declared as VAR num then the second parameter of other procedures,
which are called by the same late binding statement, should have a second parameter
which is a required VAR with basic type num. The procedures should also have the
same number of parameters. If there are mutually exclusive optional parameters, they
also have to be matching in the same sense.
Functions can have (return) any value data type (including any available installed
type). A function cannot be dimensioned, i.e. a function cannot return an array value.
The evaluation of the trap routine is explicitly terminated using the return statement
(see 4.7) or implicitly terminated by reaching the end (endtrap or error) of the trap rou-
tine. The execution continues at the point of the interrupt.
TRAP low_pressure
open_valve\slow;
! return to point of interrupt
RETURN;
ENDTRAP
TRAP high_pressure
close_valve\fast;
! return to point of interrupt
RETURN;
ENDTRAP
6 Backward Execution
RAPID supports stepwise, backward execution of statements. Backward execution is
very useful for debugging, test and adjustment purposes during RAPID program de-
velopment. RAPID procedures may contain a backward handler (statement list) that
defines the backward execution "behaviour" of the procedure (call).
The statements of the backward handler are executed (forwards) when the procedure
call is executed backwards:
Statements in the backward or error handler of a routine may not be executed back-
wards. Function calls (and indeed trap "calls") are never executed backwards (and can-
not have a backward handler). Backward execution cannot be "nested", i.e. two state-
ments in a call chain may not simultaneously be executed backwards.
The following rules are valid for the backward execution of RAPID procedures:
7 Error Recovery
An execution error (see 1.4) is an abnormal situation, related to the execution of a spe-
cific piece of RAPID program code. An error makes further execution impossible (or
at least hazardous). "Overflow" and "division by zero" are examples of errors. Errors
are identified by their unique error number and are always recognized by the system.
The occurrence of an error causes suspension of the normal program execution and the
control is passed to an error handler. The concept of error handlers makes it possible
to respond to, and possibly recover from errors that arise during program execution. If
further execution is not possible, at least the error handler can assure that the task is giv-
en a graceful abortion.
The predefined (readonly) variable ERRNO contains the error number of the (most re-
cent) error and can be used by the error handler to identify the error. After necessary
actions have been taken the error handler can:
- Resume execution starting with the statement in which the error occurred. This
is made using the retry statement (see 4.10).
- Resume execution starting with the statement after the statement in which the
error occurred. This is made using the trynext statement (see 4.11).
- Return control to the caller of the routine by using the return statement (see 4.7).
If the routine is a function the return statement must specify an appropriate
return value.
- Propagate the error to the caller of the routine by using the raise statement (see
4.8) - "Since I‘m not familiar with this error it’s up to my caller to deal with it".
If an error occurs in a routine that does not contain an error handler or reaching the end
of the error handler (ENDFUNC, ENDPROC or ENDTRAP), the system error han-
dler is called. The system error handler just reports the error and stops the execution.
In a chain of routine calls, each routine may have its own error handler. If an error oc-
curs in a routine with an error handler, and the error is explicitly propagated using the
raise statement, the same error is raised again at the point of the call of the routine - the
error is propagated. If the top of the call chain (the entry routine of the task) is reached
without any error handler found or if reaching the end of any error handler within the
call chain, the system error handler is called. The system error handler just reports the
error and stops the execution. Since a trap routine can only be called by the system (as
a response to an interrupt), any propagation of an error from a trap routine is made to
the system error handler.
In addition to errors detected and raised by the system, a program can explicitly raise
errors using the raise statement (see 4.8). The facility can be used to recover from com-
plex situations. For example it can be used to escape from deeply nested code positions.
Error numbers in the range from 1 to 90 may be used.
Note that it is not possible to recover from or respond to errors that occur within an error
handler or backward handler. Such errors are always propagated to the system error
handler.
8 Interrupts
Interrupts are program defined events identified by interrupt numbers. An interrupt oc-
curs as a consequence of an interrupt condition turning true. Unlike errors, the occur-
rence of an interrupt is not directly related to (synchronous with) a specific code posi-
tion. The occurrence of an interrupt causes suspension of the normal program execu-
tion and the control is passed to a trap routine. Interrupt numbers are allocated and
connected (associated) with a trap routine using the connect statement (see 4.12). In-
terrupt conditions are defined and manipulated using predefined routines. A task may
define an arbitrary number of interrupts.
- at the entry of next (after interrupt recognition) statement (of any type).
- after the last statement of a statement list.
- any time during the execution of a waiting routine (e.g. WaitTime).
This means that, after the recognition of an interrupt, the normal program execution
always continues until one of these positions are reached. This normally results in a
delay of 5-120 ms between interrupt recognition and response, depending on what type
of movement is being performed at the time of the interrupt.
Interrupts are defined and manipulated using predefined routines. The definition of an
interrupt specifies an interrupt condition and associates it with an interrupt number.
An interrupt condition must be active to be watched by the system. Normally the def-
inition routine (e.g. ISignalDI) activates the interrupt but that is not always the case.
An active interrupt may in turn be deactivated again (and vice versa).
The deletion of an interrupt deallocates the interrupt number and removes the interrupt
condition. It is not necessary to explicitly delete interrupts. Interrupts are automatically
deleted when the evaluation of a task is terminated.
The raising of interrupts may be disabled and enabled. If interrupts are disabled any
interrupt that occurs is queued and raised first when interrupts are enabled again. Note
that the interrupt queue may contain more than one waiting interrupt. Queued interrupts
are raised in fifo order. Interrupts are always disabled during the evaluation of a trap
routine (see 8.3 below).
! disable interrupts
IDisable;
PROC main()
...
! Connect feeder interrupts
CONNECT empty WITH ftrap;
CONNECT full WITH ftrap;
! define feeder interrupts
ISignalDI sig1, high, empty;
ISignalDI sig3, high, full;
...
ENDPROC
TRAP ftrap
TEST INTNO
CASE empty:
open_valve
CASE full:
close_valve;
ENDTEST
RETURN;
ENDTRAP
70 RAPID Developer’s Manual
RAPID Kernel Reference Manual Interrupts
More than one interrupt may be connected with the same trap routine. The predefined
(readonly) variable INTNO contains the interrupt number and can be used by a trap
routine to identify the interrupt. After necessary actions have been taken a trap routine
can be terminated using the return statement (see 4.7) or by reaching the end (endtrap
or error) of the trap routine. The execution continues at the point of the interrupt. Note
that interrupts are always disabled (see 8.2) during the evaluation of a trap routine.
Since a trap routine can only be called by the system (as a response to an interrupt),
any propagation of an error from a trap routine is made to the system error handler (see
7).
9 Task Modules
An RAPID application is called a task. A task is composed of a set of modules. A mod-
ule contains a set of type definitions, data and routine declarations. The task buffer is
used to host modules currently in use (execution, development) on a system. RAPID
program code in the task buffer may be loaded/stored from/to file oriented external de-
vices (normally disk files) either as separate modules or as a group of modules - a Task.
RAPID distinguishes between task modules and system modules. A task module is con-
sidered to be a part of the task/application while a system module is considered to be
a part of the “system”. System modules are automatically loaded to the task buffer dur-
ing system start-up and are aimed to (pre)define common, system specific data objects
(tools, weld data, move data ..), interfaces (printer, logfile ..) etc. System modules are
not included when a task is saved on a file. This means that any update made to a sys-
tem module will have impact on all existing (old) tasks currently in, or later loaded to
the task buffer. In any other sense there is no difference between task and system mod-
ules; they can have any content.
While small applications usually are contained in a single task module (besides the sys-
tem module/s), larger applications may have a "main" task module that in turn refer-
ences routines and/or data contained in one or more other, "library" task modules.
Task Buffer
Disk (ram, hard, floppy)
System Modules
system module
system module
system module
system module
task load/store
"Library" module
"Library" module
"Library" module
"Library" module
A "library" module may for example define the interface of a physical or logical object
(gripper, feeder, counter etc.) or contain geometry data generated from a CAD-system
or created on-line by digitizing (teach in).
One task module contains the entry procedure of the task. Running the task really
means that the entry routine is executed. Entry routines must be parameterless.
An attribute may not be specified more than once. If present, attributes must be specified
in table order (see above). The specification of noview excludes nostepin, viewonly and
readonly (and vice versa). The specification of viewonly excludes readonly (and vice
versa).
MODULE weldlib
LOCAL VAR welddata w1 := sysw1;
! weldlib init procedure
PROC initweld()
! override speed
w1.speed := 100;
ENDPROC
PROC arcweld(pose position \ num speed | num time)
...
ENDPROC
ENDMODULE
10 Syntax Summary
Each rule or group of rules are prefixed by a reference to the section where the rule is
introduced.
<digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<letter> ::=
<upper case letter>
| <lower case letters>
3: <expression> ::=
<expr>
| <EXP>
<primary> ::=
<literal>
| <variable>
| <persistent>
| <constant>
| <parameter>
| <function call>
| <aggregate>
| ’(’ <expr> ’)’
| <variable element>
| <variable component>
3.10: <function call> ::= <function> ’(’ [ <function argument list> ] ’)’
4: <statement> ::=
<simple statement>
| <compound statement>
| <label>
| <comment>
| <SMT>
<procedure> ::=
<identifier>
| ’%’ <expression> ’%’
11 Built-in Routines
Dim
The dim function is used to get the size of an array (datobj). It returns the number of array
elements of the specified dimension.
Present
The present function is used to test if the argument (datobj) is present (see 5.1). It returns
FALSE if datobj is a not present optional parameter, TRUE otherwise.
Break
The break (breakpoint) procedure causes a temporary stop of program execution. Break is
used for RAPID program code debugging purposes.
PROC Break ()
IWatch
The iwatch procedure activates the specified interrupt (ino). The interrupt can later be deac-
tivated again using the isleep procedure.
ISleep
The isleep procedure deactivates the specified interrupt (ino). The interrupt can later be ac-
tivated again using the iwatch procedure.
IsPers
The ispers function is used to test if a data object (datobj) is (or is an alias for) a persistent
(see 5.1). It returns TRUE in that case, FALSE otherwise.
IsVar
The isvar function is used to test if a data object (datobj) is (or is an alias for) a variable (see
5.1). It returns TRUE in that case, FALSE otherwise.
2) The argument can have any data type. Note that anytype is just a marker for this property and should not be confused with a “real”
data type. Also note that RAPID routines cannot be given anytype parameters.
ERR_CALLPROC constant errnum "procedure call error (syntax, not procedure) at run time
(late binding)"
ERR_REFUNKPRC constant errnum "reference to unknown procedure at linking time or at run time
(late binding)"
*) Read only - can only be updated by the system - not by a RAPID program.
13 Built in objects
There are three groups of “Built in objects”: Language kernel reserved objects,
Installed objects and User installed objects.
- Language kernel reserved objects are part of the system and can’t be removed
(or lived out in the configuration). Objects in this group are the instruction
Present, the variables intno, errno and much more. The set of objects in this
group is the same for all tasks (multitasking) and installations.
- Most of the Installed objects are installed at the first system start (or each P-
start) by the internal system configuration and cant be removed (e.g. the
instructions MoveL, MoveJ ...). Data objects corresponding to iosignals and
mecunits are installed according to the user configuration at each system start.
- The last group user installed objects are objects that are defined in RAPID
modules and installed according to the user configuration at the first system
start or each P-start.
The objects could be any RAPID object, that is procedure, function, record, record
component, alias, const, var or pers. Object values of pers and var could be changed,
but not the code it self, because of that a modpos of a built in constant declared robtar-
get is not allowed.
The table below show the order of scope levels lookup, for a object referred from dif-
ferent places:
There are ways to bind a reference in runtime to objects (not functions) outside its
scope. For data object see the “RAPID Reference Manual” SetDataSearch and for pro-
cedures use late binding with lookup, described in the “RAPID Kernel Reference Man-
ual” chapter “Procedure call”.
Note that a built in PERS object is not replacing its init value with its latest as a normal
PERS object do.
Note that all used references in a Built in module must be known to the system at the
time for that module installation.
14 Intertask objects
There are two groups of Intertask objects : Normal persistent data object and Built in
shared object.
- A persistent data object is shared by all task where it is declared with the same
name and type. All declaration must specify an init value to the persistent
object, but only the first module installed or loaded with the declaration will use
it. The object will still exist even if one module where it is declared is removed
as long as that module isn’t the last declaration for that object. A persistent
object could only be of value type.
- A built in object could be configurated as shared for all tasks. This make it pos-
sible to save memory by reusing RAPID code for more than one task. Its also
the only way to share non-value and semi-value data object. (see Built in
objects in this manual). The object could be any RAPID object, that is proce-
dure, function, const ,var or pers.
The system level is departed into two part, a shared part and a task part. Objects in the
task part are local to that task, but objects in the shared part is global to all task.
The shared part is only existing physical ones, and are a part of task 0 (the main task),
but existing logical in each task. A Built in shared object should be installed shared in
task 0.
Shared part
system level system level system level
Task part
The symbol search will start from that position (level) where the object is referred and
then, if not found in nearest level above and so on. See the “Symbol lookup direction”
- arrow in Figure 1.
If the object has an atomic type (num, bool ,,,) there are no problem. But if not, make
sure that the total object are read/manipulated without any interfering from another
task. E.g. if the object is of a record type and each component are assign one by one, a
reading (between the setting of two record component ) from another task will get an
inconsistent record.
Also remember that a routine could be called from more than one task at the same time
and therefore should be reentrant, that is use local stack allocated object (parameters
and data object declared in the routine).
15 Text files
This is a most effective tool that should be used when the demand for the application
includes:
In a Text file you can use ASCII strings, with the help of an off-line editor, and fetch
them from the RAPID code. The RAPID code should not be changed in any way even
if the result from the execution may look totally different.
<text_resource>::
# <comment>
<index1>:
“<text_string>”
# <comment>
<index2>:
“<text_string>”
...
The parameters
<text_resource>
This name identifies the text resource. The name must end with “::”. If
the name does not exist in the system, the system will create a new text
resource, otherwise the indexes in the file will be added to a resource
that already exists. The application developer is responsible for ensur-
ing that one’s own resources do not crash with another application. A
good rule is to use the application name as a prefix to the resource name,
e.g. MYAPP_TXRES. The name of the resource must not exceed 80
characters. Do not use exclusively alphanumeric as the name to avoid a
collision with system resources.
<index>
<text_string>
The text string starts on a new line and ends at the end of the line or, if
the text string must be formatted on several lines, the new line character
string “\n” must be inserted.
<comment>
A comment always starts on a new line and goes to the end of the line.
A comment is always preceded by “#”. The comment will not be loaded
into the system.
The RAPID identifier in the code should be defined as: <name>#<text index>#, where
the <name> is a hard coded name that could be used for references to the object as well
as the name found at the text index.
The text resource should be defined under system parameters for the module containing
the symbols that should be “Built in”.
The example below describes a complete site with configuration, text file, and a “Built
in” module. The example is a shell routine that handles a gripper with analog pressure.
The alternative name for the routine gripper in the example will be Claw. An example
of use could look like “Claw CLAWMAX;”.
The configuration
CAB_TASK_MODULES:
-File ram1disk:gripper.sys -Task MAIN -Storage BUILTIN -Txres GRIPP_TXRES
For memory optimize of RAPID programs, the storage allocation in program memory
(internal format in bytes) for some common instructions, datas etc. are specified below.
For other instructions or datas the storage allocation can be read from the operating
message 10040 after loading of a program or program module.
Storage in
Instruction or data
bytes
Storage in
Instruction or data
bytes
Storage in
Instruction or data
bytes
Byte is used for decimal values (0 - 255) according to the range of a byte.
This data type is used in conjunction with instructions and functions that handle the bit
manipulations and convert features.
Description
Data of the type byte represents a decimal byte value.
Examples
CONST num parity_bit := 8;
Bit number 8 (parity_bit) in the variable data1 will be set to 0, e.g. the content
of the variable data1 will be changed from 130 to 2 (decimal representation).
Error handling
If an argument of the type byte has a value that is not in the range between 0 and 255,
an error is returned on program execution.
Characteristics
Byte is an alias data type for num and consequently inherits its characteristics.
Related information
Described in:
Alias data types Basic Characteristics- Data Types
Bit functions RAPID Summary - Bit Functions
Examples
CONST num parity_bit := 8;
VAR byte data1 := 2;
Bit number 8 (parity_bit) in the variable data1 will be set to 1, e.g. the content
of the variable data1 will be changed from 2 to 130 (decimal representation).
BitPos 8
BitPos 1
BitPos 8
BitPos 1
0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0
Arguments
BitSet BitData BitPos
BitData Data type: byte
Limitations
The range for a data type byte is 0 - 255 decimal.
Syntax
BitSet
[ BitData’:=’ ] < var or pers (INOUT) of byte > ’,’
[ BitPos’:=’ ] < expression (IN) of num > ’;’
Related information
Described in:
Clear a specified bit in a byte data Instructions - BitClear
Check if a specified bit in a byte data is set Functions - BitCheck
Other bit functions RAPID Summary - Bit Functions
Examples
CONST num parity_bit := 8;
VAR byte data1 := 130;
Bit number 8 (parity_bit) in the variable data1 will be set to 0, e.g. the content
of the variable data1 will be changed from 130 to 2 (decimal representation).
BitPos 8
BitPos 1
BitPos 8
BitPos 1
1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0
Arguments
BitClear BitData BitPos
BitData Data type: byte
Limitations
The range for a data type byte is 0 - 255 decimal.
Syntax
BitClear
[ BitData’:=’ ] < var or pers (INOUT) of byte > ’,’
[ BitPos’:=’ ] < expression (IN) of num > ’;’
Related information
Described in:
Set a specified bit in a byte data Instructions - BitSet
Check if a specified bit in a byte data is set Functions - BitCheck
Other bit functions RAPID Summary - Bit Functions
Example
CONST num parity_bit := 8;
VAR byte data1 := 130;
Bit number 8 (parity_bit) in the variable data1 will be checked, e.g. if the spec-
ified bit is set to 1 in the variable data1, this function will return TRUE.
BitPos 8
BitPos 1
1 0 0 0 0 0 1 0
TRUE if the specified bit is set to 1, FALSE if the specified bit is set to 0.
Arguments
BitCheck (BitData BitPos)
BitData Data type: byte
Limitations
The range for a data type byte is 0 - 255 decimal.
Syntax
BitCheck’(’
[BitData ’:=’] <expression (IN) of byte> ’,’
[BitPos ’:=’] <expression (IN) of num>
’)’ ’;’
Related information
Described in:
Set a specified bit in a byte data Instructions - BitSet
Clear a specified bit in a byte data Instructions - BitClear
Other bit functions RAPID Summary - Bit Functions
Example
VAR byte data1 := 38;
VAR byte data2 := 34;
VAR byte data3;
The logical bitwise AND - operation will be executed on the data1 and data2,
the result will be returned to data3 (decimal representation).
BitPos 8
BitPos 1
0 0 1 0 0 1 1 0 data1 : 38 dec.
AND
0 0 1 0 0 0 1 0 data2 : 34 dec.
0 0 1 0 0 0 1 0 data3 : 34 dec.
Arguments
BitAnd (BitData1 BitData2)
BitData1 Data type: byte
Limitations
The range for a data type byte is 0 - 255 decimal.
Syntax
BitAnd’(’
[BitData1 ’:=’] <expression (IN) of byte> ’,’
[BitData2 ’:=’] <expression (IN) of byte>
’)’ ’;’
Related information
Described in:
Logical bitwise OR - operation on byte data Functions - BitOr
Logical bitwise XOR - operation on byte data Functions - BitXOr
Logical bitwise NEGATION - operation on Functions - BitNeg
byte data
Other bit functions RAPID Summary - Bit Functions
Example
VAR byte data1 := 39;
VAR byte data2 := 162;
VAR byte data3;
The logical bitwise OR - operation will be executed on the data1 and data2, the
result will be returned to data3 (decimal representation).
BitPos 8
BitPos 1
0 0 1 0 0 1 1 1 data1 : 39 dec.
OR
Arguments
BitOr (BitData1 BitData2)
BitData1 Data type: byte
Limitations
The range for a data type byte is 0 - 255 decimal.
Syntax
BitOr’(’
[BitData1 ’:=’] <expression (IN) of byte> ’,’
[BitData2 ’:=’] <expression (IN) of byte>
’)’ ’;’
Related information
Described in:
Logical bitwise AND - operation on byte data Functions - BitAnd
Logical bitwise XOR - operation on byte data Functions - BitXOr
Logical bitwise NEGATION - operation on Functions - BitNeg
byte data
Other bit functions RAPID Summary - Bit Functions
Example
VAR byte data1 := 39;
VAR byte data2 := 162;
VAR byte data3;
The logical bitwise XOR - operation will be executed on the data1 and data2,
the result will be returned to data3 (decimal representation).
BitPos 8
BitPos 1
0 0 1 0 0 1 1 1 data1 : 39 dec.
XOR
Arguments
BitXOr (BitData1 BitData2)
BitData1 Data type: byte
Limitations
The range for a data type byte is 0 - 255 decimal.
Syntax
BitXOr’(’
[BitData1 ’:=’] <expression (IN) of byte> ’,’
[BitData2 ’:=’] <expression (IN) of byte>
’)’ ’;’
Related information
Described in:
Logical bitwise AND - operation on byte data Functions - BitAnd
Logical bitwise OR - operation on byte data Functions - BitOr
Logical bitwise NEGATION - operation on Functions - BitNeg
byte data
Other bit functions RAPID Summary - Bit Functions
Example
VAR byte data1 := 38;
VAR byte data2;
data2 := BitNeg(data1);
The logical bitwise NEGATION - operation will be executed on the data1 and
the result will be returned to data2 (decimal representation).
BitPos 8
BitPos 1
BitPos 8
BitPos 1
BitNeg
0 0 1 0 0 1 1 0 1 1 0 1 1 0 0 1
Arguments
BitNeg (BitData)
BitData Data type: byte
Limitations
The range for a data type byte is 0 - 255 decimal.
Syntax
BitNeg’(’
[BitData ’:=’] <expression (IN) of byte>
’)’ ’;’
Related information
Described in:
Logical bitwise AND - operation on byte data Functions - BitAnd
Logical bitwise OR - operation on byte data Functions - BitOr
Logical bitwise XOR - operation on byte data Functions - BitXOr
Other bit functions RAPID Summary - Bit Functions
Example
VAR num left_shift := 3;
VAR byte data1 := 38;
VAR byte data2;
The logical bitwise LEFT SHIFT- operation will be executed on the data1 with 3
(left_shift) steps of left shift and the result will be returned to data2 (decimal rep-
resentation).
BitPos 8
BitPos 1
BitPos 8
BitPos 1
BitLSh
0 0 1 0 0 1 1 0 0 0 1 1 0 0 0 0
The result of the logical bitwise LEFT SHIFT- operation in decimal representation.
Arguments
BitLSh (BitData ShiftSteps)
BitData Data type: byte
Limitations
The range for a data type byte is 0 - 255 decimal.
Syntax
BitLSh’(’
[BitData ’:=’] <expression (IN) of byte> ’,’
[ShiftSteps ’:=’] <expression (IN) of num>
’)’ ’;’
Related information
Described in:
Logical bitwise RIGHT SHIFT - operation Functions - BitRSh
on byte data
Other bit functions RAPID Summary - Bit Functions
Example
VAR num right_shift := 3;
VAR byte data1 := 38;
VAR byte data2;
The logical bitwise RIGHT SHIFT- operation will be executed on the data1 with
3 (right_shift) steps of right shift and the result will be returned to data2 (decimal
representation).
BitPos 8
BitPos 1
BitPos 8
BitPos 1
BitRSh
0 0 1 0 0 1 1 0 0 0 0 0 0 1 0 0
The result of the logical bitwise RIGHT SHIFT- operation in decimal representation.
Arguments
BitRSh (BitData ShiftSteps)
BitData Data type: byte
Limitations
The range for a data type byte is 0 - 255 decimal.
Syntax
BitRSh’(’
[BitData ’:=’] <expression (IN) of byte> ’,’
[ShiftSteps ’:=’] <expression (IN) of num>
’)’ ’;’
Related information
Described in:
Logical bitwise LEFT SHIFT - operation Functions - BitLSh
on byte data
Other bit functions RAPID Summary - Bit Functions
datapos is the enclosing block to a data object (internal system data) retrieved with the
function GetNextSym.
Description
Data of the type datapos contains information of where a certain object is defined in
the system. It is used for instructions GetDataVal and SetDataVal.
Example
VAR datapos block;
VAR string name;
VAR bool truevar:=TRUE;
...
SetDataSearch “bool” \Object:=”^my” \InMod:=”mymod”\LocalSym;
WHILE GetNextSym(name,block) DO
SetDataVal name\Block:=block,truevar;
ENDWHILE
This session will set all local bool data object that begin with my in the module
mymod to TRUE.
Characteristics
datapos is a non-value data type.
Related information
Described in:
Define a symbol set in a search session Instructions - SetDataSearch
Get next matching symbol Functions - GetNextSym
Get the value of a data object Instructions - GetDataVal
Set the value of a data object Instructions - SetDataVal
Set the value of many object Instructions - SetAllDataVal
Example
VAR datapos block;
VAR string name;
...
SetDataSearch “robtarget”\InTask;
WHILE GetNextSym(name,block \Recursive) DO
Arguments
SetDataSearch Type [\TypeMod] [\Object] [\PersSym] [\VarSym]
[\ConstSym] [\InTask] | [\InMod] [\InRout]
[\GlobalSym] | [\LocalSym]
Type Data type: string
The module name where the data type is defined, if using user defined data types.
The default behaviour is to set all data object of the data type above, but this
option make it possible to name one or serval data objects with a regular expres-
sion.
Most other characters also match themselves, but a small set are known as the
metacharacters. These are:
Expression Meaning
The default behaviour is to accept any symbols, but if one or several of following
PersSym, VarSym or ConstSym is specified, only symbols that match the specification
is accepted:
If no one of the flags \InTask or \InMod are specified, the search is started at system
level. The system level is the root to all other symbol definitions in the symbol tree. At
the system level all buildin symbols are located plus the handle to the task level. At the
task level all loaded global symbols are located plus the handle to the modules level.
If the \Recursive flag is set in GetNextSym, the search session will enter all loaded mod-
ules and routines below the system level.
Start the search at the task level. At the task level all loaded global symbols are
located plus the handle to the modules level.
If the \Recursive flag is set in GetNextSym, the search session will enter all loaded
modules and routines below the task level.
Start the search at the specified module level. At the module level all loaded glo-
bal and local symbols declared in the specified module are located plus the handle
to the routines level.
If the \Recursive flag is set in GetNextSym, the search session will enter all
loaded routines below the specified module level (declared in the specified mod-
ule).
The module name for the routine must be specified in the argument \InMod.
The default behaviour is to match both local and global module symbols, but if one of
following \GlobalSym or \LocalSym is specified, only symbols that match the specifi-
cation is accepted:
Program Running
The instruction will fail if the specification for one of Type, TypeMod, InMod or InRout
is wrong.
If the system don’t have any matching objects the instruction will accept it and return
successfully, but the first GetNextSym will return FALSE.
Limitations
Array data objects can not be defined in the symbol search set and can not be find in a
search sequence.
For a semivalue data type, it is not possible to search for the associated value data
type. E.g. if searching for dionum no serach hit for signals signaldi and if searching for
num no search hit for signal signalgi or signalai.
Syntax
SetDataSearch
[ Type ’:=’ ] < expression (IN) of string >
[’\’TypeMod ’:=’<expression (IN) of string>]
[’\’Object ’:=’<expression (IN) of string>]
[’\’PersSym ]
[’\’VarSym ]
[’\’ConstSym ]
[’\’InTask ] | [’\’InMod ’:=’<expression (IN) of string>]
[’\’InRout ’:=’<expression (IN) of string>]
[’\’GlobalSym ] | [’\’LocalSym] ’;’
Related information
Described in:
Get next matching symbol Functions - GetNextSym
Get the value of a data object Instructions - GetDataVal
Set the value of a data object Instructions - SetDataVal
Set the value of many data objects Instructions - SetAllDataVal
The related data type datapos Data Types - datapos
Example
VAR datapos block;
VAR string name;
VAR bool truevar:=TRUE;
...
SetDataSearch “bool” \Object:=”^my” \InMod:=”mymod”\LocalSym;
WHILE GetNextSym(name,block) DO
SetDataVal name\Block:=block,truevar;
ENDWHILE
This session will set all local bool data objects that begin with my in the module
mymod to TRUE.
TRUE if a new object has been retrived, the object name and its enclosed block is then
returned in its arguments.
Arguments
GetNextSym Object Block [\Recursive]
Object Data type: string
Variable (VAR or PERS) to store the name of the data object that will be retrived.
This will force the search to enter block below, eg if the serch session has begin
on the task level it will also search modules and routines below the task.
Syntax
GetNextSym
[ Object ’:=’ ] < variable or persistent (INOUT) of string > ’,’
[ Block ’:=’] <variable (VAR) of datapos>
[’\’Recursive ] ’;’
Related information
Described in:
Define a symbol set in a search session Instructions - SetDataSearch
Get the value of a data object Instructions - GetDataVal
Set the value of a data object Instructions - SetDataVal
Set the value of many data objects Instructions - SetAllDataVal
The related data type datapos Data Types - datapos
Example
VAR num value;
...
GetDataVal “reg”+ValToStr(ReadNum(mycom)),value;
This will get the value of a register, the number of which is received from the
serial channel mycom. The value will be stored in the variable value.
This session will print out all num variables that begin with my in the module
mymod with its value to the teach-pendant.
Arguments
GetDataVal Object [\Block] Value
Object Data type: string
The enclosed block to the data object. This can only be fetched with the
GetNextSym function.
If this argument is omitted, the value of the visible data object in the current pro-
gram execution scope will be fetched. No array data objects will be found.
Variable for storage of the get value. The data type must be the same as the data
type for the data object to find. The get value can be fetched from a constant, var-
iable or persistent, but must be stored in a variable.
Error handling
The system variable ERRNO is set to ERR_SYM_ACCESS if:
Limitations
Array data objects cannot be defined in the symbol search set and cannot be found in a
search sequence.
For a semivalue data type, it is not possible to search for the associated value data
type. E.g. if searching for dionum, no search hit for signals signaldi will be obtained
and if searching for num, no search hit for signals signalgi or signalai will be obtained.
Syntax
GetDataVal
[ Object ’:=’ ] < expression (IN) of string >
[’\’Block ’:=’<variable (VAR) of datapos>] ’,’
[ Value ’:=’ ] <variable (VAR) of anytype>]’;’
Related information
Described in:
Define a symbol set in a search session Instructions - SetDataSearch
Get next matching symbol Functions - GetNextSym
Set the value of a data object Instructions - SetDataVal
Set the value of many data objects Instructions - SetAllDataVal
The related data type datapos Data Types - datapos
Example
VAR num value:=3;
...
SetDataVal “reg”+ValToStr(ReadNum(mycom)),value;
This will set the value 3 to a register, the number of which is received from the
serial channel mycom.
This session will set all local bool that begin with my in the module
mymod to TRUE.
Arguments
SetDataVal Object [\Block] Value
Object Data type: string
The enclosed block to the data object. This can only be fetched with the
GetNextSym function.
If this argument is omitted, the value of the visible data object in the current pro-
gram execution scope will be set. No array data objects will be found.
Variable which holds the new value to be set. The data type must be the same as
the data type for the data object to be set. The set value must be fetched from a
variable, but can be stored in a constant, variable or persistent.
Error handling
The system variable ERRNO is set to ERR_SYM_ACCESS if:
Limitations
Array data objects cannot be defined in the symbol search set and cannot be found in a
search sequence.
For a semivalue data type, it is not possible to search for the associated value data
type. E.g. if searching for dionum, no search hit for signals signaldi will be obtained
and if searching for num, no search hit for signals signalgi or signalai will be obtained.
Syntax
SetDataVal
[ Object ’:=’ ] < expression (IN) of string >
[’\’Block ’:=’<variable (VAR) of datapos>] ’,’
[ Value ’:=’ ] <variable (VAR) of anytype>]’;’
Related information
Described in:
Define a symbol set in a search session Instructions - SetDataSearch
Get next matching symbol Functions - GetNextSym
Get the value of a data object Instructions - GetDataVal
Set the value of many data objects Instructions - SetAllDataVal
The related data type datapos Data Types - datapos
Example
VAR mydata mydata0:=0;
...
SetAllDataVal "mydata"\TypeMod:="mytypes"\Hidden,mydata0;
This will set all data objects of data type mydata in the system to the same value
as the variable mydata0 has (in the example to 0). The user defined data type
mydata is defined in the module mytypes.
Arguments
SetAllDataVal Type [\TypeMod] [\Object] [\Hidden] Value
Type Data type: string
The module name where the data type is defined, if using user defined data types.
The default behaviour is to set all data object of the data type above, but this
option make it possible to name one or serval objects with a regular expression.
(see also SetDataSearch)
This match also data objects that are in routines (routine data or parameters) hid-
den by some routine in the call chain.
Variable which holds the new value to be set. The data type must be same as the
data type for the object to be set.
Program Running
The instruction will fail if the specification for Type or TypeMod is wrong.
If the matching data object is an array, all elements of the array will be set to the spec-
ified value.
If the matching data object is read-only data, the value will not be changed.
If the system don’t have any matching data objects the instruction will accept it and
return successfully.
Limitations
For a semivalue data type, it is not possible to search for the associated value data
type. E.g. if searching for dionum no serach hit for signals signaldi and if searching for
num no search hit for signal signalgi or signalai.
Syntax
SetAllDataVal
[ Type ’:=’ ] < expression (IN) of string >
[’\’TypeMod ’:=’<expression (IN) of string>]
[’\’Object ’:=’<expression (IN) of string>]
[’\’Hidden ] ’,’
[’\’Value ’:=’] <variable (VAR) of anytype>’;’
Related information
Described in:
Define a symbol set in a search session Instructions - SetDataSearch
Get next matching symbol Functions - GetNextSym
Get the value of a data object Instructions - GetDataVal
Set the value of a data object Instructions - SetDataVal
The related data type datapos Data Types - datapos
Signals with alias names can be used for predefined generic programs, without any
modification of the program before running in different robot installations.
The instruction AliasIO must be run before any use of the actual signal. See example 1
below for loaded modules and example 2 below for builtin modules.
Example 1
VAR signaldo alias_do;
PROC prog_start()
AliasIO config_do, alias_do;
ENDPROC
Arguments
AliasIO FromSignal ToSignal
FromSignal Data type: signalxx or
string
Loaded modules:
The signal identifier named according to the configuration (data type signalxx)
from which the signal descriptor is copied. The signal must be defined in the IO
configuration.
Built-in modules:
The signal identifier according to the program (data type signalxx) to which the
signal descriptor is copied. The signal must be declared in the RAPID program.
The same data type must be used (or find) for the arguments FromSignal and ToSignal
and must be one of type signalxx (signalai, signalao, signaldi, signaldo, signalgi or sig-
nalgo).
Program execution
The signal descriptor value is copied from the signal given in argument FromSignal to
the signal given in argument ToSignal.
Example 2
VAR signaldi alias_di;
PROC prog_start()
CONST string config_string := "config_di";
AliasIO config_string, alias_di;
ENDPROC
Limitation
When starting the program, the alias signal cannot be used until the AliasIO instruction
is executed.
Instruction AliasIO is not available for programming from the Teach Pendant (only
from Program Maker). Option Developer’s Functions is required.
Syntax
AliasIO
[ FromSignal ’:=’ ] < reference (REF) of anytype> ’,’
[ ToSignal ’:=’ ] < variable (VAR) of anytype> ’;’
Related information
Described in:
Input/Output instructions RAPID Summary -
Input and Output Signals
Input/Output functionality in general Motion and I/O Principles -
I/O Principles
Configuration of I/O User’s Guide - System Parameters
Defining event routines User’s Guide - System Parameters
Loaded/Built-in task modules User’s Guide - System Parameters
Example
VAR num chales :=5;
...
proc1 chales;
The variable name is assigned the string value "chales" and on TP the following
string is written: "Argument name charles with value 5".
Arguments
ArgName (Parameter)
Parameter Data type: anytype
The formal parameter identifier (for the routine in which ArgName is located) or
the data identity.
Program execution
The function returns the original data object name for an entire object of the type con-
stant, variable or persistent. The original data object can be global, local in the program
module or local in a routine (normal RAPID scope rules).
If it is a part of a data object, the name of the whole data object is returned.
Example
This function can also be used to convert from identifier to string, by stating the iden-
tifier in the argument Parameter for any data object with global, local in module or
local in routine scope:
PROC proc1 ()
VAR string name;
...
name:=ArgName(chales);
TPWrite "Global data object "+name+" has value "\Num:=chales;
ENDPROC
The variable name is assigned the string value "chales" and on TP the following
string is written: "Global data object chales has value 5".
Note that the function returns the original data object name:
The variable name is assigned the string value "chales" and on TP the following
string is written: "Original data object name charles with value 5".
Error handling
If one of the following errors occurs, the system variable ERRNO is set to
ERR_ARGNAME:
Syntax
ArgName ’(’
[ Parameter’:=’ ] < reference (REF) of any type> ’)’
Related information
Described in:
String functions RAPID Summary - String Functions
Definition of string Data Types - string
String values Basic Characteristics -
Basic Elements
Examples
! Introduce a new error number in a glue system
! Note: The new error variable must be declared with the initial value -1
VAR errnum ERR_GLUEFLOW := -1;
! Error handling
ERROR
IF ERRNO = ERR_GLUEFLOW THEN
...
ELSE
...
ENDIF
If the digital input di1 is 0 the new booked error number will be raised and the
system error number ERRNO will be set to the new booked error number. The
error handling of those user generated errors can then be handled in the error han-
dler as usual.
Arguments
BookErrNo ErrorName
ErrorName Data type: errnum
Limitations
The new error variable must be declared as a global one in the system.
The new error variable must be declared with an initial value of -1, that gives the
information that this error should be a RAPID system error.
Syntax
BookErrNo
[ ErrorName’:=’ ] < variable (VAR) of errnum > ’;’
Related information
Described in:
Example
A new text table named deburr_part1 for user defined texts. The new text table has the
file name deburr.eng.
deburr.eng
RAPID - Code
The variable text_res_no is assigned the text table number for the definded text
table deburr_part1.
A message is stored in the robot log. The message is also shown on the teach pen-
dant display. The messages will be taken from the text table deburr_part1 :
1: Part 1 is not in pos
2: Identity of worked part: XYZ
Arguments
TextTabGet ( TableName )
TableName Data type: string
Syntax
TextTabGet ’(’
[ TableName ’:=’ ] < expression (IN) of string > ’;’
Related information
Described in:
Get text from system text tables Functions - TextGet
String functions RAPID Summary - String Functions
Definition of string Data Types - string
String values Basic Characteristics -
Basic Elements
Example
VAR string text1;
...
text1 := TextGet(14, 5);
The variable text1 is assigned the text stored in text resource 14 and index 5.
Arguments
TextGet ( Table Index )
Table Data type: num
Syntax
TextGet ’(’
[ Table ’:=’ ] < expression (IN) of num > ’,’
[ Index ’:=’ ] < expression (IN) of num > ’)’
Related information
Described in:
Get text table number Functions - TextTabGet
String functions RAPID Summary - String Functions
Definition of string Data Types - string
String values Basic Characteristics -
Basic Elements
Example
IF NOT IsSysId("6400-1234") THEN
ErrWrite "System identity fault","Faulty system identity for this program";
EXIT;
ENDIF
The program is made for a special robot system and can’t be used of another one.
FALSE = The system identity is not the same as specified in the test.
Arguments
IsSysId ( SystemId)
SystemId Data type: string
Syntax
IsSysId ’(’
[ SystemId’:=’ ] < expression (IN) of string> ’)’
Related information
Described in:
With this instruction it is possible to change the current active Tool or Work Object.
Example
SetSysData tool5;
Arguments
SetSysData SourceObject [\ ObjectName ]
SourceObject Data type: anytype
The data type of this argument also specifies the type of system data (Tool or
Work Object) to be activated.
If this optional argument is specified, it specifies the name of the data object to
be active (overrides name specified in argument SourceObject). The data type of
the data object to be active is always fetched from the argument SourceObject.
Program execution
The current active system data object for the Tool or Work Object is set according to
the arguments.
Note that this instruction only activates a new data object (or the same as before) and
never changes the value of any data object.
Syntax
SetSysData
[ SourceObject’:=’] < persistent(PERS) of anytype>
[’\’ObjectName’:=’ < expression(IN) of string> ] ’;’
Related information
Described in:
Definition of tools Data Types - tooldata
Definition of work objects Data Types - wobjdata
Get system data Instructions - GetSysData
Example
IF IsStopStateEvent (\PPMoved) = TRUE THEN
! PP has been moved during the last program stop
ELSE
! PP has not been moved during the last program stop
ENDIF
Status if and how PP has been moved during the last stop state.
If PP has been moved to the main routine, both \PPMoved and \PPToMain will return
TRUE.
If PP has been moved to a routine, both \PPMoved and \PPToMain will return TRUE.
When calling a routine or a service routine (keep execution context in main program
sequence) \PPMove will return TRUE and \PPToMain will return FALSE.
Arguments
IsStopStateEvent ( [\PPMoved] | [\PPToMain] )
[\PPMoved] Data type: switch
Limitations
This function can in most cases not be used at forward or backward execution, because
the system is in stop state between every single step.
Syntax
IsStopStateEvent’(’
[’\’ PPMoved] | [’\’ PPToMain] ’)’
Related information
Described in:
Making own instructions RAPID Reference Manual
- Programming off-line
Examples
ReadCfgData “/MOC/MOTOR_CALIB/irb_1”,”cal_offset”,offset1;
Reads the value of the calibration offset for axis irb_1 into the num variable
offset1.
ReadCfgData “/EIO/EIO_USER_SIGNAL/process_error”,”Unit”,io_unit;
Reads the name of the I/O unit where the signal process_error is defined, into
the string variable io_unit.
Arguments
ReadCfgData InstancePath Attribute CfgData
InstancePath Data type: string
Specifies a path to the named parameter to be accessed. The format of this string
is /DOMAIN/TYPE/InstanceName
The variable where the attribute will be stored. Depending on the attribute type,
the valid types are bool, num, or string.
Program execution
The value of the attribute specified by the Attribute argument is stored in the variable
specified by the CfgData argument.
Limitations
Only named parameters can be accessed, i.e. parameters where the first attribute is
‘name’, ‘Name’, or ‘NAME’.
RAPID strings are limited to 80 characters. In some cases, this can be in theory too
small for the definition InstancePath, Attribute, or CfgData.
Error handling
If it is not possible to find the data specified with “InstancePath + Attribute” in the con-
figuration database, the system variable ERRNO is set to ERR_CFG_NOTFND.
If the data type for parameter CfgData is not equal to the real data type for the found
data specified with “InstancePath + Attribute” in the configuration database, the sys-
tem variable ERRNO is set to ERR_CFG_ILLTYPE.
Syntax
ReadCfgData
[ InstancePath ’:=’ ] < expression (IN) of string >’,’
[ Attribute ’:=’ ] < expression (IN) of string > ’,’
[ CfgData ’:=’ ] < variable (VAR) of anytype > ’;’
Related information
Described in:
Definition of string Data types- string
Write attribute of a system parameter Instructions - WriteCfgData
Configuration User’s Guide - System Parameters
Examples
WriteCfgData “/MOC/MOTOR_CALIB/irb_1”,”cal_offset”,offset1;
Writes the value of the num variable offset1 as calibration offset for axis irb_1.
WriteCfgData “/EIO/EIO_USER_SIGNAL/process_error”,”Unit”,io_unit;
Writes the value of the string variable io_unit as the name of the I/O unit where
the signal process_error is defined.
Arguments
WriteCfgData InstancePath Attribute CfgData
InstancePath Data type: string
Specifies a path to the named parameter to be modified. The format of this string
is /DOMAIN/TYPE/InstanceName
The variable where the attribute is read. Depending on the attribute type, valid
types are bool, num, or string.
Program execution
The value of the attribute specified by the Attribute argument is set according to the
value of the variable specified by the CfgData argument.
Limitations
You must manual restart the controller in order for the change to have effect.
Only named parameters can be accessed, i.e. parameters where the first attribute is
‘name’, ‘Name’, or ‘NAME’.
RAPID strings are limited to 80 characters. In some cases, this can be in theory too
small for the definition of InstancePath, Attribute, or CfgData.
Error handling
If it is not possible to find the data specified with “InstancePath + Attribute” in the con-
figuration database, the system variable ERRNO is set to ERR_CFG_NOTFND.
If the data type for parameter CfgData is not equal to the real data type for the found
data specified with “InstancePath + Attribute” in the configuration database, the sys-
tem variable ERRNO is set to ERR_CFG_ILLTYPE.
If the data for parameter CfgData is outside limits (max./min. value), the system vari-
able ERRNO is set to ERR_CFG_LIMIT.
Syntax
WriteCfgData
[ InstancePath ’:=’ ] < expression (IN) of string >’,’
[ Attribute ’:=’ ] < expression (IN) of string > ’,’
[ CfgData ’:=’ ] < variable (VAR) of anytype > ’;’
Related information
Described in:
Definition of string Data types- string
Read attribute of a system parameter Instructions - ReadCfgData
Configuration User’s Guide - System Parameters
Example
PFIOResto;
All digital output signals are restored to the values before power failure.
Program execution
All digital output signals are restored to the values before power failure. If a digital out-
put signal has been affected after the power failure and after the restart of the system,
e.g. from the RAPID program or from the TP, then this output will not be changed.
Syntax
PFIOResto’;’
Related information
Described in:
Input/Output instructions RAPID Summary -
Input and Output Signals
Input/Output functionality in general Motion and I/O Principles -
I/O Principles
Configuration of I/O System Parameters
Power Failure ...
Example
SetDO do15, PFDOVal(do15);
First the function PFDOVal(do15) gets the value of do15 at the time of power
failure, then do15 is set to this value.
The value of the specified digital output signal at the time for power failure.
Arguments
PFDOVal (Signal)
Syntax
PFDOVal’(’
[ Signal ':=' ] < variable (VAR) of signaldo >’)’
Related information
Described in:
Input/Output instructions RAPID Summary -
Input and Output Signals
Input/Output functionality in general Motion and I/O Principles -
I/O Principles
Configuration of I/O System Parameters
Power Failure ...
Example
SetGO go2, PFGOVal(go2);
First the function PFGOVal(go2) gets the value of go2 at the time for power fail-
ure, then go2 is reset to this value.
The value of the specified group of digital output signals at the time for power failure.
Arguments
PFGOVal (Signal)
Syntax
PFGOVal’(’
[ Signal ':=' ] < variable (VAR) of signalgo > ’)’
Related information
Described in:
Input/Output instructions RAPID Summary -
Input and Output Signals
Input/Output functionality in general Motion and I/O Principles -
I/O Principles
Configuration of I/O System Parameters
Power Failure ...
Example
IF PFRestart() = TRUE THEN
TRUE if an interrupted path exists on the specified path level, otherwise FALSE.
Arguments
PFRestart ([\Base] | [\Irpt])
[\Base] (Base Level) Data type: switch
Syntax
PFRestart’(’
[’\’Base] | [’\’Irpt]’)’
Related information
Described in:
Power Failure ...
The data defined is used in one or more subsequent TriggL, TriggC, or TriggJ instruc-
tions.
(Only if the robot is equipped with the option “Advanced functions”.)
Examples
VAR triggdata glueflow;
p1 p2
p3
Glue flow ends
The glue flow (analog output glue_ao) with scale value 0.8 start when TCP is 0.05 s
before point p1, new glue flow scale value 1 when TCP is 10 mm plus 0.05 s before
point p2 and the glue flow ends (scale value 0) when TCP is 0.05 s before point p3.
Any speed dip by the robot is time compensated in such a way that the analog output
signal glue_ao is affected 0.04 s before the TCP speed dip occurs.
If overflow of the calculated logical analog output value in glue_ao, the digital output
signal glue_err is set. If no overflow any more, glue_err is reset.
Arguments
TriggSpeed TriggData Distance [ \Start ] ScaleLag
AOp ScaleValue [ \DipLag ] [ \ErrDO ]
TriggData Data type: triggdata
Variable for storing the triggdata returned from this instruction. These triggdata
are then used in the subsequent TriggL, TriggC or TriggJ instructions.
Defines the position on the path for change of the analog output value.
Specified as the distance in mm (positive value) from the end point of the move-
ment path (applicable if the argument \ Start is not set).
Used when the distance for the argument Distance starts at the movement start
point instead of the end point.
Specify the lag as time in s (positive value) in the external equipment for change
of the analog output value (starting, scaling and ending).
For compensation of external equipment lag, this argument value means that the
analog output signal is set by the robot at specified time before the TCP physi-
cally reaches the specified distance in relation to the movement start or end point.
The argument can also be used to extend the analog output beyond the end point.
Set the time in seconds that the robot shall keep the analog output. Set the time
with a negative sign. The limit is -0.10 seconds.
Distance Distance
\Start
+ - + -
ScaleLag
The physical output value for the analog signal is calculated by the robot:
Specify the lag as time in s (positive value) for the external equipment when
changing of the analog output value due to robot speed dips.
For compensation of external equipment lag, this argument value means that the
analog output signal is set by the robot at a specified time before the TCP speed
dip occurs.
This argument can only be used by the robot for the first TriggSpeed (in combi-
nation with one of TriggL, TriggC, or TriggJ) in a sequence of several Trigg-
Speed instructions. The first specified argument value is valid for all the
following TriggSpeed in the sequence.
The name of the digital output signal for reporting analog value overflow.
If during movement the calculation of the logical analog output value for signal
in argument AOp result in overflow due to overspeed, this signal is set and the
physical analog output value is reduced to the maximum value. If no overflow
any more, the signal is reset.
This argument can only be used by the robot for the 1:st TriggSpeed (in combi-
Program execution
When running the instruction TriggSpeed, the trigger condition is stored in the speci-
fied variable for the argument TriggData.
Afterwards, when one of the instructions TriggL, TriggC or TriggJ is executed, the fol-
lowing are applicable, with regard to the definitions in TriggSpeed:
The position-time related scale value event will be generated when the start point (end
point) is passed, if the specified distance from the end point (start point) is not within
the length of movement of the current instruction (Trigg...).
The 1:st TriggSpeed used by one of TriggL, TriggC or TriggJ instruction will internally
in the system create a process with the same name as the analog output signal. The same
process will be used by all succeeding Trigg..., which refer to same signal name and
setup by a TriggSpeed instruction.
The process will immediately set the analog output to 0, in the event of a program emer-
gency stop. In the event of a program stop, the analog output signal will stay TCP-speed
proportional until the robot stands still. The process keeps “alive” ready for a restart.
When the robot restarts, the signal is TCP-speed proportional directly from the start.
Program stop
TCP Speed
Emergency stop
TCP Speed
The process will “die” after handling a scale event with value 0, if no succeeding
Trigg... is in the queue at the time.
Examples
VAR triggdata flow;
The analog output signal flowsignal is set to a logical value = (0.5 * actual TCP
speed in mm/s) 0.05 s before the TCP passes a point located 10 mm after the start
point p. The output value is adjusted to be proportional to the actual TCP speed
during the movement to p2.
...
TriggL p3, v500, flow, z10, tool1;
The robot moves from p2 to p3 still with the analog output value proportional to
the actual TCP speed. The analog output value will be decreased at time 0.03 s
before the robot reduce the TCP speed during the passage of the corner path z10.
Limitations
Typical absolute accuracy values for scale value events +/- 5 ms.
Typical repeat accuracy values for scale value events +/- 2 ms.
Typical absolute accuracy values for TCP speed dips adaptation +/- 5 ms.
Typical repeat accuracy values for TCP speed dips adaptation +/- 2ms
(the value depends of the configured Path resolution).
Negative ScaleLag
If a negative value on parameter ScaleLag is used to move the zero scaling over to the
next segment, the analog output signal will not be reset if a program stop occurs. An
emergency stop will always reset the analog signal.
The analog signal is no longer TCP-speed proportional after the end point on the seg-
ment.
Start segment TCP movements End segment
AO active
Not TCP-speed
proportial
Error handling
Given two consecutive segments with TriggL/TriggSpeed instructions. A negative
value in parameter ScaleLag makes it possible to move the scale event from the first
segment to the beginning of the second segment. If the second segment scales at the
beginning, there is no control if the two scalings interfere.
V
Wanted analog output signal
V
Possible results in the event
of interferences
ScaleLag > DipLag Always DipLag, if DipLag > Servo Lag ScaleLag in s plus 0.090 s
ScaleLag < DipLag DipLag < Servo Lag ----------------- “ -------------- 0.090 s
---------- “ --------- DipLag > Servo Lag ---------------- “ --------------- DipLag in s plus 0.030 s
Syntax
TriggSpeed
[ TriggData ’:=’ ] < variable (VAR) of triggdata> ‘,’
[ Distance ’:=’ ] < expression (IN) of num>
[ ’\’ Start ] ‘,’
[ ScaleLag ’:=’ ] < expression (IN) of num> ‘,’
[ AOp ’:=’] < variable (VAR) of signalao> ‘,’
[ ScaleValue ’:=’ ] < expression (IN) of num>
[ ’\’ DipLag ’:=’ < expression (IN) of num> ]
[ ’\’ ErrDO ’:=’ < variable (VAR ) of signaldo> ] ‘;’
Related information
Described in:
Use of triggers Instructions - TriggL, TriggC, TriggJ
Definition of other triggs Instruction - TriggIO, TriggInt,
TriggEquip
More examples Data Types - triggdata
Configuration of Event preset time System Parameters - Manipulator
It’s up to the user, to introduce a restart process flag, so StepBwdPath in the RESTART
event routine is only executed at process restart and not at all program restart.
Example
StepBwdPath 30, 1;
Arguments
StepBwdPath StepLength StepTime
StepLength Data type: num
Specifies the distance, in millimetres, to move backwards during this step. This
argument must be a positive value.
Specifies the time, in seconds, the movement will take. This argument must have
a positive value.
Program execution
The robot moves back on its path, for the specified distance. The path is exactly the
same, in the reverse way, as it was before the stop occurred. In the case of a quick stop
or emergency stop, the RESTART event routine is called after the regain phase has
completed, so the robot will already be back on its path when this instruction is exe-
cuted.
Limitations
After the program has been stopped, it is possible to step backwards on the path with
the following limits:
- The 1st step backward will be reduced to the current segment for the robot
- Further backward steps will be limited to the previous segment
If an attempt is made to move beyond these limit, the error handler will be called with
ERRNO set to ERR_BWDLIMIT.
Syntax
StepBwdPath
[ StepLength ’:=’ ] < expression (IN) of num >’,’
[ StepTime ’:=’ ] < expression (IN) of num > ’;’
Related information
Described in:
Motion in general Motion and I/O Principles
Positioning instructions RAPID Summary- Motion
restartdata mirrors the pre- and postvalues of specified I/O signals (process signals) at
the stop sequence of the robot movements.
The I/O signals to supervise are specified in the instruction TriggStopProc.
TriggStopProc and restartdata are intended to be used for restart after program stop
(STOP) or emergency stop (QSTOP) of own process instructions defined in RAPID
(NOSTEPIN routines).
Definition
Table 7 Definition of the time point for reading the pre- and postvalues for the I/O signals
Read time for I/O signal prevalue Read time for I/O signal postvalue
Type of stop
(pretime) (postvalue)
STOP on path When all robot axes are standing About 400 ms after the pretime
still
QSTOP off path As soon as possible About 400 ms after the pretime
Description
restartdata mirrors the following data after program execution is stopped:
Components
restartstop (valid restartdata after stop) Data type: bool
The prevalue of the digital signal “do1” specified in the argument DO1 in instruc-
tion TriggStopProc.
The postvalue of the digital signal “do1” specified in the argument DO1 in
instruction TriggStopProc.
The prevalue of the digital group signal “go1” specified in the argument GO1 in
instruction TriggStopProc.
The postvalue of the digital group signal “go1” specified in the argument GO1 in
instruction TriggStopProc.
The prevalue of the digital group signal “go2” specified in the argument GO2 in
instruction TriggStopProc.
The postvalue of the digital group signal “go2” specified in the argument GO2 in
instruction TriggStopProc.
The prevalue of the digital group signal “go3” specified in the argument GO3 in
instruction TriggStopProc.
The postvalue of the digital group signal “go3” specified in the argument GO3 in
instruction TriggStopProc.
The prevalue of the digital group signal “go4” specified in the argument GO4 in
instruction TriggStopProc.
The postvalue of the digital group signal “go4” specified in the argument GO4 in
instruction TriggStopProc.
The number of value transitions (flanks) of the digital signal “shadow” between
the pretime and the posttime.
The signal “shadow” is specified in the argument ShadowDO in instruction
TriggStopProc.
Structure
< dataobject of restartdata>
< restartstop of bool>
< stoponpath of bool>
< predo1val of dionum>
< postdo1val of dionum>
< prego1val of num>
< postgo1val of num>
< prego2val of num>
< postgo2val of num>
< prego3val of num>
< postgo3val of num>
< prego4val of num>
< postgo4val of num>
< preshadowval of dionum>
< shadowflanks of dionum>
< postshadowval of dionum>
Related information
Described in:
Predefined process instructions Instructions - TriggL, TriggC
Setup mirror of restart data Instructions - TriggStopProc
Move backwards on path Instructions - StepBwdPath
TriggStopProc and the data type restartdata are intended to be used for restart after
program stop (STOP) or emergency stop (QSTOP) of own process instructions defined
in RAPID (NOSTEPIN routines).
It is possible in a user defined RESTART event routine, to analyse the current restart
data, step backwards on the path with instruction StepBwdPath and activate suitable
process signals before the movement restarts.
Arguments
TriggStopProc RestartRef [\DO1] [\GO1] [\GO2] [\GO3] [\GO4]
ShadowDO
RestartRef (Restart Reference) Data type: restartdata
The persistent variable in which restart data will be available after every stop of
program execution.
The signal variable for a digital process signal to be zero set and supervised in
restart data when program execution is stopped.
The signal variable for a digital group process signal to be zero set and super-
vised in restart data when program execution is stopped.
The signal variable for a digital group process signal to be zero set and super-
vised in restart data when program execution is stopped.
The signal variable for a digital group process signal to be zero set and super-
vised in restart data when program execution is stopped.
The signal variable for a digital group process signal to be zero set and super-
At least one of the option parameters DO1, GO1 ... GO4 must be used.
The signal variable for the digital signal, which must mirror whether or not the
process is active along the robot path.
This signal will not be zero set by the process TriggStopProc at STOP or QSTOP,
but its values will be mirrored in restartdata.
Program execution
The internal name of the process for TriggStopProc is the same as the signal name in
the argument ShadowDO. If TriggStopProc, with same the signal name in argument
ShadowDO, is executed twice, only the last executed TriggStopProc will be active.
Execution of TriggStopProc only starts the supervision of I/O signals at STOP and
QSTOP.
Both the robot servo and the external equipment have some lags. All the instructions
in the Trigg family are designed so that all signals will be set at suitable places on the
robot path, independently of different lags in external equipment, to obtain process
results that are as good as possible. Because of this, the settings of I/O signals can be
delayed between 0 - 80 ms internally in the system, after the robot stands still at pro-
gram stop (STOP) or after registration of an emergency stop (QSTOP). Because of this
disadvantage for the restart functionality, both the prevalue and postvalue and also the
shadow flanks are introduced in restart data.
Figure 22 Process phases at STOP or QSTOP within critical time slot 0-80 ms
Performing a restart
A restart of own process instructions (NOSTEPIN routines) along the robot path must
be done in a RESTART event routine.
Limitation
No support for restart of own process instructions after a power failure.
Syntax
TriggStopProc
[ RestartRef ’:=’ ] < persistent (PERS) of restartdata>
[ ’\’ DO1 ’:=’ < variable (VAR) of signaldo> ]
[ ’\’ GO1 ’:=’ < variable (VAR) of signalgo> ]
[ ’\’ GO2 ’:=’ < variable (VAR) of signalgo> ]
[ ’\’ GO3 ’:=’ < variable (VAR) of signalgo> ]
[ ’\’ GO4 ’:=’ < variable (VAR) of signalgo> ] ’,’
[ ShadowDO ’:=’ ] < variable (VAR) of signaldo> ’;’
Related information
Described in:
Predefined process instructions Instructions - TriggL, TriggC
Restart data Data Types - restartdata
Step backward on path Instructions - StepBwdPath
Description
Data of the type dir contains a reference to a directory on disk or network. It can be
linked to the physical directory by means of the instruction OpenDir and then used for
reading.
Example
PROC lsdir(string dirname)
VAR dir directory;
VAR string filename;
OpenDir directory, dirname;
WHILE ReadDir(directory, filename) DO
TPWrite filename;
ENDWHILE
CloseDir directory;
ENDPROC
This example prints out the names of all files or subdirectories under the speci-
fied directory.
Characteristics
dir is a non-value data type and cannot be used in value-oriented operations.
Related information
Described in:
Open a directory OpenDir
Read a directory ReadDir
Close a directory CloseDir
Check file type IsFile
Examples
MakeDir “HOME:/newdir”;
Arguments
MakeDir Path
Path Data type: string
The name of the new directory, specified with full or relative path.
Error handling
If the directory cannot be created, the system variable ERRNO is set to
ERR_FILEACC. This error can then be handled in the error handler.
Syntax
MakeDir
[ Path’:=’ ] < expression (IN) of string>’;’
Related information
Described in:
Remove a directory RemoveDir
Remove a file RemoveFile
Example
PROC lsdir(string dirname)
VAR dir directory;
VAR string filename;
OpenDir directory, dirname;
WHILE ReadDir(directory, filename) DO
TPWrite filename;
ENDWHILE
CloseDir directory;
ENDPROC
This example prints out the names of all files or subdirectories under the speci-
fied directory.
Arguments
OpenDir Dev Path
Dev Data type: dir
Limitations
Open directories should always be closed by the user after reading (instruction
CloseDir).
Error handling
If the path points to a not existing directory or if there are too many directories open at
the same time, the system variable ERRNO is set to ERR_FILEACC. This error can
then be handled in the error handler.
Syntax
OpenDir
[ Dev’:=’ ] < variable (VAR) of dir>’,’
[ Path’:=’ ] < expression (IN) of string>’;’
Related information
Described in:
Directory dir
Read a directory ReadDir
Close a directory CloseDir
Check file type IsFile
Example
PROC lsdir(string dirname)
VAR dir directory;
VAR string filename;
OpenDir directory, dirname;
WHILE ReadDir(directory, filename) DO
TPWrite filename;
ENDWHILE
CloseDir directory;
ENDPROC
This example prints out the names of all files or subdirectories under the speci-
fied directory.
Arguments
CloseDir Dev
Dev Data type: dir
Syntax
CloseDir
[ Dev’:=’ ] < variable (VAR) of dir>’;’
Related information
Described in:
Directory dir
Open a directory OpenDir
Read a directory ReadDir
Check file type IsFile
The user must have write and execute permission for the directory and the directory
must be empty.
Examples
RemoveDir “HOME:/mydir”;
Arguments
RemoveDir Path
Path Data type: string
The name of the directory to be removed, specified with full or relative path.
Error handling
If the directory does not exist or the directory is not empty, the system variable ERRNO
is set to ERR_FILEACC. This error can then be handled in the error handler.
Syntax
RemoveDir
[ Path’:=’ ] < expression (IN) of string>’;’
Related information
Described in:
Directory dir
Make a directory MakeDir
Open a directory OpenDir
Read a directory ReadDir
Close a directory CloseDir
As long as the function returns TRUE, there can be more files or subdirectories to
retrieve.
Example
This example prints out the names of all files or subdirectories under the speci-
fied directory.
The function will return TRUE if it has retrieved a name, otherwise FALSE.
Arguments
ReadDir ( Dev FileName )
Dev Data type: dir
Program execution
This function returns a bool that specifies success or not.
Example
This example implements a generic traverse of a directory structure function.
PROC main()
! Execute the listfile routine for all files found under the
! tree in ram1disk:
searchdir "ram1disk:","listfile";
ENDPROC
This program traverses the directory structure under the "ram1disk:", and for
each file found it calls the listfile procedure. The searchdir is the generic part that
knows nothing about the start of the search or which routine should be called for
each file. It uses IsFile to check whether it has found a subdirectory or a file and
it uses the late binding mechanism to call the procedure specified in actionproc
for all files found. The actionproc routine should be a procedure with one param-
eter of the type string.
Error handling
If the directory is not opened (see OpenDir), the system variable ERRNO is set to
ERR_FILEACC. This error can then be handled in the error handler.
Syntax
ReadDir ’(’
[ Dev’:=’ ] < variable (VAR) of dir>’,’
[ FileName’:=’ ] < var or pers (INOUT) of string>’)’
Related information
Described in:
Directory dir
Open a directory OpenDir
Close a directory CloseDir
Check file type IsFile
Example
PROC printFT(string filename)
IF IsFile(filename \Directory) THEN
TPWrite filename+" is a directory";
RETURN;
ENDIF
IF IsFile(filename \Fifo) THEN
TPWrite filename+" is a fifo file";
RETURN;
ENDIF
IF IsFile(filename \RegFile) THEN
TPWrite filename+" is a regular file";
RETURN;
ENDIF
IF IsFile(filename \BlockSpec) THEN
TPWrite filename+" is a block special file";
RETURN;
ENDIF
IF IsFile(filename \CharSpec) THEN
TPWrite filename+" is a character special file";
RETURN;
ENDIF
ENDPROC
This example prints out the type of the specified file on the teach pendant.
The function will return TRUE if the specified type and actual type match, otherwise
FALSE. When no type is specified, it returns TRUE if the file exists and otherwise
FALSE.
Arguments
IsFile ( Path [\Directory] [\Fifo] [\RegFile] [\BlockSpec]
[\CharSpec] )
Path Data type: string
Program execution
This function returns a bool that specifies match or not.
Example
This example implements a generic traverse of a directory structure function.
PROC main()
! Execute the listfile routine for all files found under the
! tree of HOME:
searchdir "HOME:","listfile";
ENDPROC
This program traverses the directory structure under the “HOME:” and for each
file found, it calls the listfile procedure. The searchdir is the generic part that
knows nothing about the start of the search or which routine should be called for
each file. It uses IsFile to check whether it has found a subdirectory or a file and
it uses the late binding mechanism to call the procedure specified in actionproc
for all files found. The actionproc routine should be a procedure with one param-
eter of the type string.
Error handling
If the file does not exist and there is a type specified, the system variable ERRNO is
set to ERR_FILEACC. This error can then be handled in the error handler.
Syntax
Isfile ’(’
[ Path’:=’ ] < expression (IN) of string>
[ [ '\'Directory ] | [ '\'Fifo ] | [ '\'RegFile ] | [ '\'BlockSpec ] | [ '\'CharSpec ] ]
’)’
Related information
Described in:
Directory dir
Open a directory OpenDir
Close a directory CloseDir
Read a directory ReadDir
Example
PROC listfile(string filename)
VAR num size;
size := FileSize(filename);
TPWrite filename+" size: "+NumToStr(size,0)+" Bytes";
ENDPROC
This procedure prints out the name of specified file together with a size
specification.
Arguments
FileSize ( Path )
Path Data type: string
Program execution
This function returns a numeric that specifies the size in bytes of the specified file.
Example
This example lists all files bigger than 1 KByte under the “HOME:” directory
structure, including all subdirectories.
PROC main()
! Execute the listfile routine for all files found under the
! tree of HOME:
searchdir "HOME:","listfile";
ENDPROC
This program traverses the directory structure under “HOME:” and for each file
found it calls the listfile procedure. The searchdir is a generic part that knows
nothing about the start of the search or which routine should be called for each
file. It uses IsFile to check whether it has found a subdirectory or a file and it uses
the late binding mechanism to call the procedure specified in actionproc for all
files found. The actionproc routine listfile checks whether the file is bigger than
1KBytes.
Error handling
If the file does not exist, the system variable ERRNO is set to ERR_FILEACC. This
error can then be handled in the error handler.
Syntax
FileSize ’(’
[ Path ’:=’ ] < expression (IN) of string> ’)’
Related information
Described in:
Directory dir
Open a directory OpenDir
Close a directory CloseDir
Read a directory ReadDir
Internt
Exekveringsmod: Beskrivning:
Kontinuerligt framåt Enligt ovan.
Stegvis framåt Enligt ovan.
Stegvis bakåt Exekverar aldrig bakåt
Simulering Enligt ovan
REVISION PAGE
Document Registration number: filesize.ard REVISION
REVIEWED BY DEP NAME DATE SIGNATURE
Others
User Documentation
Example
PROC main()
VAR num totalfsyssize;
VAR num freefsyssize;
freefsyssize := FSSize("HOME:/spy.log" \Free);
totalfsyssize := FSSize("HOME:/spy.log" \Total);
TPWrite NumToStr(((totalfsyssize - freefsyssize)/totalfsyssize)*100,0)
+" percent used";
ENDPROC
This procedure prints out the amount of disk space used on the HOME: file sys-
tem (flash disk /hd0a/ ) as a percentage.
Arguments
FSSize ( Name [\Total] | [\Free] )
Name Data type: string
The name of a file in the file system, specified with full or relative path.
Program execution
This function returns a numeric that specifies the size of the file system in which the
specified file resides.
Example
This is a complete example for implementing an alert service that prints a warning
on the TP when the remaining free space in the “HOME:” file system is less than
10%.
PROC alertFree()
IDelete timeint;
ENDPROC
Error handling
If the file system does not exist, the system variable ERRNO is set to ERR_FILEACC.
This error can then be handled in the error handler.
Syntax
FSSize’(’
[ Name ’:=’ ] < expression (IN) of string>
[ '\'Total ] | [ '\'Free ]’)’
Related information
Described in:
File size. FileSize
Examples
RemoveFile “HOME:/mydir/myfile.log”;
In this example, the file myfile.log in directory mydir on disk HOME: is deleted.
Arguments
RemoveFile Path
Path Data type: string
The name of the file to be deleted, specified with full or relative path.
Error handling
If the file does not exist, the system variable ERRNO is set to ERR_FILEACC. This
error can then be handled in the error handler.
Syntax
RemoveFile
[ Path’:=’ ] < expression (IN) of string>’;’ Related information
Related information
Described in:
Make a directory MakeDir
Remove a directory RemoveDir
The Elemetary I/O (EIO) system comprises such item as I/O units, analog signals, dig-
ital signals, groups of digital signal and cross connections of digital signals.
The EIO System is configured using a configuration file. This file may be created and
edited by use of the Teach Pendant or by use of a regular text editor.
The coniguration file is divided into sections. Each section recognizes a set of param-
eters defining characteristics of the IO system. The sections are related as shown in
Figure 16 below.
Each section contains a list of configuration items one on each line. The configuration
items are configured by specifying values for the parameters, recognized by each sec-
tion.
Example:
EIO_UNIT:
-Name UNIT_A -Type d328 -Address 4 \
-Digin 16 -Digout 16 <-- End of first item
-Name UNIT_B -Type d328 -Address 7 \
-Digin 8 -Digin 8 <-- End of second item
As shown in the example above, each configuration item may be split into several lines
by use of the backslash character.
Type_A par_A
EIO_UNIT_TYPE
EIO_PARAM
Unit_A Unit_B
EIO_UNIT EIO_UNIT val_B
EIO_PARAM_VALUE
Cross_A
EIO_CROSS
Figure 16 The different sections of the configuration file are hierarchically related.
The robot system is delivered with a set of predefined unit types1. If a unit does not fit
within these types, a new type may be defined in the EIO_UNIT_TYPE section. This
is done by giving appropriate values to the parameters.
Example:
This configuration item defines a DSQC-328 I/O Board. The board has 16 digital inputs
and 16 digital outputs.
EIO_UNIT_TYPE:
-Name d328 -VendorId 75 -VendorName “ABB Robotics” -DeviceType 7 \
-ProductId 0 -ProductName “24 Vdc IO” -MajorRev 0 -MinorRev 0
Parameters of EIO_UNIT_TYPE
-Name Mandatory
The name that will be used to refer to this type in the rest of the configuration file
-VendorId Mandatory
-VendorName Optional
-DeviceType Mandatory
-ProductId Mandatory
-ProductName Optional
-MajorRev Mandatory
-MinorRev Mandatory
-MaxDigin Optional
Specifies the maximum number of digital inputs available on the unit type.
For modules connected to the BASE bus, this parameter is not used, since it is possible
to obtain this information from the I/O module itself.
-MaxDigout Optional
Specifies the maximum number of digital outputs available on the unit type.
For some modules connected to the BASE bus, this parameter is not used, since it is
possible to obtain this information from the I/O module itself.
-MaxAnin Optional
Specifies the maximum number of analog inputs available on the unit type.
For some modules connected to the BASE bus, this parameter is not used, since it is
possible to obtain this information from the I/O module itself.
-MaxAnout Optional
Specifies the maximum number of analog outputs available on the unit type.
For some modules connected to the BASE bus, this parameter is not used, since it is
possible to obtain this information from the I/O module itself.
Name of the section that defines the parameters that is available on the unit type.
Some of the parameters must be given values, other may be left out and will then get
the default value. The table below defines the characteristics for each parameter in the
EIO_UNIT_TYPE section.
Default
Parameter Values Type
Value
Some I/O modules may have configurable parameters, that shall be down-loaded to the
unit by the robot controller at start-up. If so, these parameters are defined in the
EIO_PARAM section. The section is given a name as shown in this example.
Example:
D328_PARAM = EIO_PARAM:
-Name on_off_delay -Path “6, 20 0F 24 01 30 01,4,4” -Service 20 -DefValue 100
The name of this section is assigned to the -Param parameter of the EIO_UNIT_TYPE
section.
Example:
EIO_UNIT_TYPE:
-Name d328 -VendorId 75 -VendorName “ABB Robotics” -DeviceType 7 \
-ProductId 0 -ProductName “24 Vdc IO” -MajorRev 0 -MinorRev 0 \
-Param D328_PARAM
Each configuration item in the EIO_PARAM section describes one parameter by the
following parameters
Parameters of EIO_PARAM
-Name Mandatory
The name that will be used to refer to this parameter when giving it a specific value for
a specific unit as described in the EIO_PARAM_VALUE section below.
-Path Mandatory
The syntax of the value that shall be assigned to this parameter depends on what bus
the unit type is connected to.
For deviceNet compatible I/O modules, the value can be found in the EDS-file for the
I/O module.
-Service Mandatory
A numeric code that describes for the driver software how to set the parameter.
Valid values for this parameter depends on what bus the unit type is connected to.
For deviceNet compatible I/O modules, the value can be found in the EDS-file for the
I/O module.
-DefValue Mandatory
The value that will be assigned to the parameter if the parameter is omitted in the cor-
responding EIO_PARAM_VALUE section.
The EIO_UNIT section is used to define and configure a physical IO unit (module/
device) of some type. The unit type has to be one of the types previosly defined in the
EIO_UNIT_TYPE section. Each configuration item describes a single unit by use of
the following parameters.
Parameters of EIO_UNIT
-Name Mandatory
-Type Mandatory
Specifies the type of unit. The value of this parameter must be a name of an configura-
tion item defined in the EIO_UNIT_TYPE section.
-Bus Mandatory
Specifies what bus this unit is connected to. Available buses are listed in section .
-Address Mandatory
The syntax of the address depends on what bus the unit is connected to see below.
-Digin Optional
-Digout Optional
-Anin Optional
-Anout Optional
-PollRate Optional
Some units needs to be polled for update of input and output signals. The -PollRate
parameter specifies the time between two consecutive polls of a unit.
NOTE: The I/O modules produced by ABB Robotics Products that connects to the
BASE I/O Bus is event driven. With these modules the polling mechanism is used as
heart-beat only. It is recomended to use the default poll rate, 1 second, with these mod-
ules.
-TrustLevel Optional
Trust Level 0: The robot controller will not start until connection has been established
with all units with trust level 0.
Trust Level 1 (default if parameter omitted): If a unit with trust level equal to 1 is lost,
an error message will be generated. If signals that are located on the lost unit is
accessed, an error message will be reported and program execution will stop.
Trust Level 2: If a unit with trust level equal to 2 is lost, NO error message will be gen-
erated. If however signals, that are located on the lost unit, are accessed, an error mes-
sage will be reported and program execution will stop.
-Disabled Optional
Specifies that the I/O module will not be present on the bus at start-up.
-Signal Optional
-Param Optional
Name of the section that defines values for the configurable parameters of the unit.
Some of the parameters must be given values, other may be left out and will then get
the default value. The table below defines the characteristics for each parameter in the
EIO_UNIT section.
Address Syntax
Units connected to the BASE I/O Bus uses Addresses between 0 and 62. User defined
units may use addresses between 10 and 62. The address shall be specified in decimal
form.
The unit which is of a certain unit type may have a number of configurable parameters,
depending on whether that unit type has reference to a EIO_PARAM section as
described in the EIO_PARAM section above.
If a unit needs to give a parameter a value that differs from the default value of that
parameter, a EIO_PARAM_VALUE section needs to be defined. The section is given
a name, that is referred to by the -Param parameter in the EIO_UNIT section.
Example:
UNIT_A_VALUES = EIO_PARAM_VALUES:
-Name on_of_delay -Value 200
The section holds one configuration item for each parameter that is to be assigned a
value. The parameters are defined in the corresponding EIO_PARAM section.
Parameters of EIO_PARAM_VALUE
-Name Mandatory
The parameter name must match one of the configuration items in the EIO_PARAM
section.
-Value Mandatory
The EIO_SIGNAL sections defines all the I/O signals, digital as well as analog, in the
system. These logical signals are attached to physical channels located on previously
defined units.
224 RAPID Developer’s Manual
System Parameters Elementary IO Configuration File
Note that several signals can be connected to the same physical channel. The same sig-
nals cannot, however, be connected to different physical channels.
The I/O signals are divided into groups for easier handling. Each group are given a sep-
arate section name as shown below.
User Signals
EIO_USER_SIGNAL = EIO_SIGNAL:
Grouped Signals
EIO_GROUP_PHS = EIO_SIGNAL:
This section lists all the user defined signal groups. A signal group is a digital signal
with a length greater that one.
System Signals
EIO_SYSTEM_SIGNAL = EIO_SIGNAL:
These signals are defined by application software packages such as ArcWare, Spot-
Ware etc.
All the groups described above have the same parameters, listed below:
Parameters of EIO_SIGNAL
-Name Mandatory
-Type Mandatory
-Unit Mandatory
-Phsig Mandatory
Specifies number of the physical signal on the unit. Each signal type is numbered from
one(1) and up.
-Length Mandatory
A logical signal may consist of a group of digital physical signals. The value of such a
signal will thus be a positive integer that is binary coded using the individual digital
signals as a basis.
The -Length parameter specifies the number of physical signals that shall be grouped
into this logical signal. A maximum of 16 digital physical signals may be grouped
together. All signals must reside on the same I/O unit.
The Length parameter must be one(1) for the signal types; DI, DO, AI and AO.
-Disabled Optional
-LogMax Optional
Specifies the logical maximum value of the signal. This parameter together with Log-
Min, PhMax and PhMin is used for scaling. See description below.
This parameter can NOT be used with the signal types: DI, DO, GI, DO.
-LogMin Optional
Specifies the logical minimum value of the signal. This parameter together with Log-
Max, PhMax and PhMin is used for scaling. See description below.
This parameter can NOT be used with the signal types: DI, DO, GI, DO.
-PhMax Optional
Specifies the maximum value of the physical signal. This parameter together with Log-
Max, LogMin and PhMin is used for scaling. See description below.
This parameter can NOT be used with the signal types: DI, DO, GI, DO.
-PhMin Optional
Specifies the minimum value of the physical signal. This parameter together with Log-
Max, LogMin and PhMax is used for scaling. See description below.
This parameter can NOT be used with the signal types: DI, DO, GI, DO.
Scaling of analog signals
Physical value of the
output signal (V, mA, etc.)
Physical Max
Logical Max
Logical value in the
Logical Min program
Physical Min
Specifies the time (in millisecs) that a digital input signal has to be passive (logical 0)
for the system to detect it as passive (logical 0).
This parameter can NOT be used with the signal types; DO, GI, GO, AI and AO
-FiltAct Optional
Specifies the time (in millisecs) that a digital input signal has to be active (logical 1)
for the system to detect it as active (logical 1).
A maximum of 10 different filter times can be used. If two signals are connected to the
same physical channel, the filter time for these signals must be the same. The filter
parameters must be set to 0 for analog signal and digital outputs.
-Acthigh Optional
If specified, the logical input signal is active when the physical input is passive and vice
versa.
This parameter can NOT be used with the signal types; DO, GI, GO, AI, AO.
-Invert Optional
If specified, the physical output signal will be inverted in relation to the logical output
signal.
This parameter can NOT be used with the signal types; DI, GI, GO, AI, AO.
-Pfailout Optional
Specifies what value the output signal shall obtain after a power fail.
This parameter can NOT be used with the signal types: DI, AI and GI.
-Store Optional
If specified, the output signals value will be stored on power-fail and restored at restart.
This parameter can NOT be used with the signal types: DI, AI and GI.
-Default Optional
The default value is used for calculating cross connections when the actual signal state
is undefined. The signal state is undefined when the system has lost connection with
the unit to which the signal is connected.
-Set Optional
Some of the parameters must be given values, other may be left out and will then get
the default value. The table below defines the characteristics for each parameter in the
EIO_SIGNAL section.
Digital signals can be grouped together and handled as if they were one signal. The
value of such a signal will thus be a positive integer that is binary coded using the indi-
vidual digital signals as a basis.
A group is defined by specifying a signal length greater than one. A group may be up
to 16 signals wide.
Example:
EIO_GROUP_PHS = EIO_SIGNAL:
A digital input or output signal can be logically connected to one or several digital input
or output signals. This means that a cross-connected signal will automatically be
changed when the “activation” signal is changed.
Example:
EIO_CROSS:
-Lact di1 +di2 +do3 -Lres do1 + do2
A maximum of 20 signals can be cross connected. Make sure that the same signal is not
connected on both the ”Lact” and ”Lres” sides, in the same chain.
Parameters of EIO_CROSS
-Lact Mandatory
Lists the activation signals in this cross connection. A maximum of five signals is
allowed in the list.
As an option, boolean expressions maybe used together with the activators. The follow-
ing boolean functions maybe used:
AND &
OR !
NOT *
Example:
EIO_CROSS:
-Lact di1 & di2 ! *do3 -Lres do1 + do2
-Lres Mandatory
Lists the resultant signals in this cross connection. More that one signal may be the
resultant in a cross connection by putting a +-sign between the signals.
The robot controller is delivered with set of predefined elementary I/O buses that can
be used with the system. These are:
The robot controller is delivered with a set of predefined Elementary I/O Unit Types.
These are:
Topic: Communication
The following parameters are found under the Communication topic:
Parameters Description
Name Name of physical channel.
Type Type of physical channel (sio)
Channel Channel number (1 - 4).
Baud rate Baud rate for the serial channel (300 - 19200).
Parity Type of parity for serial channel. (Odd, Even, None).
No. of bits Number of data bits (7,8).
No. of stops bits Number of stop bits (1, 2).
Parameters Description
Name Name of the transmission protocol.
Type Type of transmission protocol (None, XON/XOFF, SLIP).
PhyChannel Name of the physical channel the protocol should use.
For Slip only:
Local Address Local address of the SLIP connection.
Remote Address Remote address of the SLIP connection.
PortNo The TCP protocol port number of the remote computer.
D
17 Index data 2-89, 2-93, 2-95
Data Declarations 33
A
Data Objects 16
Add 3-103 Data Types 18, 25
Aggregates 43 datapos 4-121
Alias types 29 declaration
AliasIO 5-135 persistent 2-91, 2-94, 2-97
AND 3-109 variable 2-94, 2-96
ArgName 5-139 Defining a IO 9-218
Assignment Statement 51 dir 8-187
Atomic Types 26
E
B
Elementary IO Configuration 9-217
Backward Execution 17 Error Classification 20
backward handler 17 error handler 17
Backward Handlers 65 Error Handlers 67
bit manipulation 3-101 Error Recovery 17, 67
BitAnd 3-109 Exit Statement 54
BitCheck 3-107
F
BitClear 3-105
BitLSh 3-117 For Statement 57
BitNeg 3-115 Function calls 44
BitRSh 3-119 Function Declarations 63
BitXOr 3-113 Functions 5-151
BookErrNo 5-143
Break 85 G
Built in objects 2-89
Built-in Data Objects 87 GetDataVal 4-121, 4-129
Built-in Data Types 18 GetNextSym 4-123, 4-127
Built-in Routines 85 Goto Statement 53
byte 3-101, 3-103, 3-105, 3-107 I
C If Statement 56
CloseDir 8-193 Installed Data Types 18
Communication 9-232 Interrupt Manipulation 69
compact if statemen 57 Interrupt Recognition and Response 69
Connect Statement 56 Interrupts 17, 69
constant 2-89, 2-93 IO Configuration 9-217
Constant Declarations 37 ISleep 85
Constants 43 IsPers 85, 5-153
IsSysId 5-149
IsVar 86