Introduction

Global variables (GV) are areas of shared memory with semaphore access.

The purpose of these variables is to be used for data exchange. By taking advantage of them, one no longer has to define a variable as public in one task and then as extern in another task that uses it.

Bookmarks

Related arguments

Creating global variables

Creation via XML file

The creation of these variables is done, typically, by reading the configuration files in the /GV/ directory.

The file, in XML format, contains:

•Variable name

•Textual description of the variable type

•Size of the variable in bytes

•Attributes of the variable

•Representation of the data area (this can be omitted)

File names follow the following structs: GV_variable_name_size.CFG

Example

After the generation of GV from file, those of persistent type are linked to the retentive component.

At switch on, for persistent GV, the data in the configuration file are updated using the values read in retentive memory, if any.

Creation by instruction GV_CREATE

GVs can be created from instruction (GV_CREATE) by specifying:

•The name (reference key for subsequent links)

•Textual information of the data area type (e.g. "U32" or "Struct DOT" ...)

•Information of the size of the data area

•Possible password to enable write access

•Attributes (persistent, option to create the definition file, option to store the data in the file, ...)

•Any data to initialize the variable

GV creation is possible only if one with the same name (which is used as a key) does not already exist.

By creating a variable from instruction, the variable configuration file is created automatically.

NOTE: GV names are handled as case insensitive, so "foo" and "Foo" define the name of the same GV.

Linking to global variables

Linking memory areas (Instruction GV_LINK) of GV is done by name and size (which must match the defined GV) and a local copy of it.

The link function returns a reference to the connection interface between the local and global copy of the variable.

All operations on the GV are done using the interface reference only.

It is possible to have multiple interfaces to the same GV in different tasks or contexts.

NOTE: Each homogeneous entity of work (task, rule or OB) must have its own local copy connected to its own interface. It should be considered a mistake to use the same interface in different task contexts (e.g., RULE and TASK) or multiple interfaces using the same local data area.

Access to global variables

Access to GV is done indirectly through functions (GV_READ, GV_WRITE...).

Through functions it is then possible to update data from local to global area and vice versa. These operations are, of course, handled with semaphores to ensure that the operation (in either direction) is consistent (or atomic).

It is also possible to impose a restriction on access to each individual GV so only the interface that has taken rights to it can access it.

NOTE: Currently no nesting/release access rights are managed on the same interface.

In case that there is a write password only the links that provide the correct password can have write access.

It is also possible to specify that only the first one to connect to the variable with the correct password has write rights.

It is also possible to update only part of the variable with the appropriate instruction.

Persistent GV

In order to be able to handle persistent GV, it is essential to have set the retention memory area allocated to GV in the project configuration (RDE versions above version 3.51.1).

When creating a GV with the persistent attribute, the component in retentive memory is also created. The creation is aborted if there is no memory available at least equal to the size of the new GV added to the maximum size among the GV in retentive memory. Access to the area of persistent GV is managed by a semaphore. Only one persistent GV can be updated at a time.

Retentive area updating occurs when copying data from local area to global area.

Since the copy operation is not instantaneous, if the control is turned off during this operation, it is guaranteed that the retentive data is not lost, obviously the last ones written completely and not the ones being updated will be valid.

If, on the other hand, the persistent type GV is not already present in the retentive area, one is created initialized with the values in the file.

It is possible that there are global variables in retentive memory that are not connected to any defined global variable. In that case they remain in retentive memory without being usable until you reuse the descriptor file or recreate the variable with the same name and size.

GV Directives

GV Alarms