Variables are entities whose value is not known during the writing of a program and normally varies during its execution.
The data types used by the R3 language are:
Type |
Description |
---|---|
8-bit signed integer variable |
|
16-bit signed integer variable |
|
32-bit signed integer variable |
|
8-bit unsigned integer variable |
|
16-bit unsigned integer variable |
|
32-bit unsigned integer variable |
|
32-bit integer variable (it is like I32) |
|
Floating point variable 4 Byte |
|
Floating point variable 8 Byte (double) |
|
Boolean variable |
|
Char type variable (it is like I8) |
|
Structure type variable |
|
Packed structure type variable (data is contiguous, takes up less space) |
|
String type variable (127 char + terminator) |
|
Tables of string constants |
|
Variable of type counter |
|
Variable of type timer |
|
Variable for power handling |
|
Support structure for functions bcc_send(), bcc_receive(), ... |
|
Support structure for functions bcc_get_tcp_clients_info() and getTcpClientsInfo() |
|
Support structure for functions planar_comp_ip() and planar_comp_cp() |
|
Support structure for functions axio_robj() and axio_wobj() |
|
Support structure for function co_rerr() |
|
Support structure for function statistics() |
|
Support structure for function f_dir() |
|
Support structure for movement function mva_to_n() |
|
Support structure for movement function mv_cam() |
|
Support structure for communication functions modbus/tcp |
|
Support structure for movement function mv_table() |
|
Support structure for movement function mv_to() |
|
Support structure for movement function mv_to_cj() |
|
Support structure for movement function mv_to_cjv() |
|
Support structure for function mv_to_cjv_info() |
|
Support structure for movement function mv_to_cjv() |
|
Support structure for movement function mva_zc() |
|
Support structure for movement function mva_to_n_v() |
|
Support structure for movement function mva_to_n_cj() |
|
Support structure for function ah_get_d() |
|
Support structure for function ah_info() |
|
Support structure for function as_get_d() |
|
Support structure for functions int_after(), int_inp() e int_timer() |
|
Support structure for movement function mv_crimper() |
|
Support structure for function ecat_probe() |
|
Support structure for movement function mv_follow() |
|
Support structure for movement function mv_follow2() |
|
Support structure for movement function mva_follow2() |
|
Support structure for movement function mva_follow2_m() |
|
Support structure for movement function mv_follow2() |
|
Support structure for function get_hw_info() |
|
Support structure for movement function mv_phase_adj() |
|
Support structure for movement function mv_phase_adj2() |
|
Support structure for function axio_pm_r() |
|
Support structure for movement function mv_reach_target() |
|
Support structure for function safe_prj_info() |
|
Support structure for functions soe_ridn() e soe_widn() |
|
Support structure for movement function mv_synchro() |
|
Support structure for movement function tracking() |
|
Support structure for function master_filter() |
NOTE: Nesting of structures (structures of structures) is allowed.
Variables can have the following levels of visibility:
Visibility |
Description |
|
---|---|---|
Global |
These are the R3 language's predefined variables or locales declared as public (see below). They are accessible from all tasks and usable on all debugging tools |
|
Local |
Accessible variables (R/W) from the task in which they are declared only. They must be defined at the beginning of the source file before the instructions.
|
|
Public |
Variables accessible (R/W) by the task to which they are declared and normally readable by other tasks. (see external) They must be defined at the beginning of the source file, before instructions, prefixed with "PUBLIC".
|
|
External |
Variables from a different task. They are normally read-only unless the task that includes them has the metacommand "$WRITE_ON_EXTERN" at its beginning. They must be defined at the beginning of the source file with the prefix "EXTERN" to which the equivalent PUBLIC must necessarily correspond in another task. (see Public)
|
|
Retentive |
User structure of which retentiveness is desired at shutdown.(retentive memory) It has the following special features: •Maximum size of the structure is smaller than that of the user area of retentive memory (see report) •Cannot be an array of structure (but nothing prohibits it from being inside it) •Maximum size of structure name of 31 characters •Maximum variable name size of 31 characters •The metacommand $ WRITE_ON_EXTERN must be present in order to write this structure. •The association of the user structure to the retentive structure occurs only at load time if and only if NO previous associations exist •If a retentive structure already exists then, at task startup, the structure name, instance name, and size are checked to match those previously recorded •This structure is saved, as are the registers, when the control is turned off Example:
NOTE: To delete the association of the user structure to the retentive structure use the device command (ascii directive) REMOVE NV_USERSTRUCT. NOTE: To initialize the structure in case of memory loss use the device command (ascii directive) RESTORE NV_USERSTRUCT. NOTE: To automatically enlarge the size of the structure, provided the structure and instance names are the same, use bit 10 of the default variable SYS_CFG. |
|
Local to functions |
Variables that are defined within function() and are usable only within it. These variables lose their contents each time the function exits. NOTE: It is possible to redefine the name of local variables, that means, internal variables can have the same name as local variables. However, it is recommended to use different names to avoid confusion. WARNING: These are different locations, that means, internal and local variables with the same name occupy different physical memory locations. Changing an internal variable has no effect on a local variable that has the same name. Several variables with the same name can be declared in functions. They are NOT usable by debugging tools. They can also be placed in motion fields within rules. They behave similarly to those declared in functions. |
It is possible to declare local variables in rules, as long as they are within the REF / MOTION / AUX blocks. Variables in the REF block are visible only in the block itself; those in MOTION and AUX are in common with each other.
You can declare local variables within the task main code (visibility is limited between the point of declaration and the end of main).
Various examples of data declaration:
|