Exporting V.E. variables in PLC structures (C22)

1.1 IntroductionPAGEREF _Toc307387626 \h3

1.2 Description of the V.E. variable list 4

1.2.1 use_extended_string_var parameter (BOOLEAN) 4

1.2.2 Declaring V.E. variables 5

1.2.3 SCOPE: memory area of the V.E. variable 5

1.2.4 INDEX: addressing the memory 6

1.2.5 ARRAY_ELEMENTS: arrays 9

1.2.5.1 Arrays and index method 9

1.2.5.1.1 Special case: STRING arrays 9

1.2.5.2 Arrays and AutoMem method 9

1.3 Generating the PLC structure out of a V.E. variable list 10

1.3.1 Generating the output file 10

1.3.1.1 CNC command #EXPORT VE 10

1.3.2 Output file structure 11

1.3.2.1 Section 1: static type definition 11

1.3.2.2 Section 2: type declaration from the V.E. variable list 12

1.3.2.3 Section 3: channel-specific PLC parameters 13

1.3.2.4 Section 4: global PLC parameters 14

1.3.3 Remarks 15

1.3.3.1 Alignment in the case of channel-specific and global data types 15

1.3.3.2 Output of the index value in the output file 15

1.4 Check of the V.E. variable declarations by the program 16

1.4.1 General error check: mixed memory organisation 16

1.4.1.1 "CHANNEL" 16

1.4.1.2 "GLOBAL" 16

1.4.2 Error check when using the index method 17

1.4.2.1 Check of index values 17

1.4.2.2 V.E. array variables: incorrect specification of the memory area 17

1.4.2.3 Overlapping of memory areas 17

1.4.3 Error check when using the AutoMem method 18

1.4.3.1 Index values must not be programmed 18

1.4.3.2 Memory requirement check 18

1.5 Restrictions in the case of a multiple-channel controller structure 21

1.6 CNC  PLC type table 22

1.7 Example 23

1.7.1 VE variable list 23

1.7.2 PLC structure generated out of the V.E. variable list 24

1.7.3 PLC example 25

1.8 Short-form instructions 26

More:

button Introduction

button Description of the V.E. variable list

button Generating the PLC structure out of a V.E. variable list

button Check of the V.E. variable declarations by the program

button Restrictions in the case of a multiple-channel controller structure

button CNC - PLC type table

button Example

button Short-form instructions


Introduction

Data exchange via V.E.

Simulation in PLC

Support by
#EXPORT VE

V.E variables allow you to exchange data in any direction between an NC program and the PLC. From the CNC perspective, as a minimum one channel-indendepent 'global' and, for each NC channel, one further 'channel-specific' V.E. memory area exist. Internal access in the controller to the memory created by the CNC (shared memory) belonging to the V.E. memory blocks or the variables contained therein takes place directly via address pointers and is therefore time-efficient, both from the PLC and the CNC.

Each of the V.E. variables corresponds to a "basic type" (REAL64, ...) or self-defined structures which, in turn, can consist of structures or "basic types". (One-dimensional) arrays are additionally addressable.

It was previously necessary for users to define the address and memory location for each V.E. variable themselves. This has no longer been necessary since V2.10.1025.00. Consequently, PLC programmers often fail in their attempts to achieve error-free simulation of the structures described in the CNC lists. Moreover, PLC programmers often end up confused if they use all possible combinations of basic types and/or variable structures as well as user-defined index-based and automated addressing. Auxiliary constructions to detect errors in memory allocation, addressing or overwriting only partly help. This results in delays during commissioning.

The following documentation describes application of the #EXPORT command. The command can be placed in an NC program or can be executed as a manual block. The command is used to generate files that (post-)declare all V.E. variables created in a CNC channel in congruent IEC 61131 variables or structures. The files generated are compatible with the CoDeSys (3S) and MULTIPROG (KW-Software) development environments and can be imported directly there.

All examples mentioned below are realised in Structured Text (ST) and are presented as 3S-compatible PLC code. The generation variant for KW-Software contains additional structure declarations because arrays within structure cannot be declared directly.

The [?] designations in the examples are placeholder parameters for indexes to be actually entered.


Description of the V.E. variable list

This section described only those key words of the V.E. variable list that are relevant to exporting. For all other key words, refer to the documentation entitled "External variables" [EXTV].

More:

button use_extended_string_var parameter (BOOLEAN)

button Declaring V.E. variables

button SCOPE: memory area of the V.E. variable

button INDEX: addressing the memory

button ARRAY_ELEMENTS: arrays


use_extended_string_var parameter (BOOLEAN)

The use_extended_string_var list parameter defines how many ASCII characters of a V.E. variable of the STRING type may be assigned as a maximum. At the same time, it (implicitly) defines the memory needed for each string variable.

Parameter setting of use_extended _string_var | Maximum string length | Implicitly reserved memory | Implicit alignment
0 | 20 ASCII characters | 24 bytes | 4 bytes
1 | 127 ASCII characters | 128 bytes | 0 bytes

Section 1.3.3.1 describes the alignment stated in the table.


Declaring V.E. variables

An individual V.E. variable is declared by way of the var[?] convention. The following figure shows the attributes relevant to export. These are discussed in the following sections.


SCOPE: memory area of the V.E. variable

Depending on the purpose, V.E. variables are assigned either to the channel-specific (var[?].scope = CHANNEL) or the global memory area (var[?].scope = GLOBAL). The two memory areas are of the same size and are set in the case of TwinCAT, for example, via the SystemManager: CNC configuration, CNC task GEO, HLI tab, VE box (enter the number) or in the start-up list via the ext_var_max parameter.

The channel-specific memory area is assigned exclusively to an NC channel, while the global memory area can be read or written by any NC channel of the controller.

This separation does not exist from the PLC's perspective and, as far as it is concerned, all memory areas are equivalent. It has read and write access to each of the memories via several address pointers. 1+channel quantity exists from the PLC's perspective, i.e. a minimum of two memory areas.


INDEX: addressing the memory

Two methods are available as alternatives for addressing each variable:

1) Index method

Addressing is realised by specifying an index value (var[?].index). Each index comprises a memory of 24 bytes. If the chosen index "distance" between two successive variables is too small, memory overlapping occurs. Consequence: the memory of the following variable is overwritten. The CNC does not issue an error message because it assumes that this addressing was chosen deliberately.

2) AutoMem method

With this method, the CNC assumes memory management. The V.E. variables are entered in the memory successively in a non-overlapping fashion. When using this method, users do not need to both about correct memory assignment. An identifying feature of the AutoMem method is that declaration of the var[?].index attribute is not used in any of the variables!

The user decides according to which the methods the two memories for CHANNEL and GLOBAL are each organised.

+ Both memories need not be organised with the same method - although both memories are declared in one V.E. list!

+ A multiple-channel structure complicates the decision. This above all applies to GLOBAL variables. You will find pertinent remarks in Section 1.5.

When the index method is used, it is imperative when using the EXPORT method described here for all index values to be entered in ascending order. According to the documentation entitled "External variables", this restriction does not otherwise exist!


ARRAY_ELEMENTS: arrays

Basically, only one-dimensional arrays are possible. Multi-dimensional arrays can, however, be simulated by defining a separate type for each dimension. See the following example.

struct[?].name Array160

struct[?].element[0].name a

struct[?].element[0].type REAL64

struct[?].element[0].array_elements 160

var[?].name Array10x160

var[?].type Array160

var[?].array_elements 10

In the NC program:

V.E.Array10x160[i].a[j] (* where i:0..9, j:0..159 *)

In the case of arrays, special aspects have to be considered depending on the chosen addressing mode, i.e. index method or AutoMem method. These are described in the following sections.

More:

button Arrays and index method

button Arrays and AutoMem method


Arrays and index method

The definition of a V.E. variable by means of the index method contains the following attributes. They define the memory layout and size: INDEX, SIZE and ARRAY_ELEMENTS.

Example:

var[4].name Auto

var[4].index 2 (Identifier of the index method)

var[4].type UNS16

var[4].size 2

var[4].array_elements 3

The number of elements in an array variable is set via the array_elements parameter. If the variable is not an array, the value must be array_elements=0 or can be dropped entirely. Each array element's memory requirement (in bytes) is specified via the .size parameter. For single elements the .size parameter is not relevant, but it must be specified in the case of arrays.

Example

Example: the V.E. variable "Auto" is of the UNS16 type. If it is to be used in an array, the attribute var[4].size must be set to 2. If it is not used in an array, the ".size" attribute is superfluous.

Contrary to the description of functions entitled "External variables in the NC, Rev. 8, Page 13", the export algorithm described here does not allow you to set any values in var[?].size.

The number of index values (corresponding to assigned index blocks) needed for a variable is calculated in accordance with the specified formula:

Required number
of index values =

( [image] ) (rounded up to an integer)

More:

button Special case: STRING arrays


Special case: STRING arrays

In the case of STRING arrays, the var[?].size parameter must be assigned the following values:

Parameter setting | Value of the size parameter in the case of STRING field variables
use_extended_string_var = 0 | var[?].size = 24
use_extended_string_var = 1 | var[?}.size = 128

Example

There are three variables, TEXT_1, TEXT_2 and TEXT_3 that (partly) correspond to arrays. If use_extended_string_var = 0 applies, the following results for the respectively required index attribute:

Identifier | Array_ elements | size | Index | Note
V.E. TEXT_1 | 3 | 24 | 0 | Required number = 3*24/24 = 3
V.E. TEXT_2 | 4 | 24 | 3 | Required number = 4*24/24 = 4
V.E. TEXT_3 | 0 | 24 | 7 | Required number = 1*24/24 = 1

Example

If use_extended_string_var = 1 is chosen, this results in the following picture:

Identifier | Array_ elements | size | Index | Note
V.E. TEXT_1 | 3 | 128 | 0 | Required number = 3*128/24 = 16
V.E. TEXT_2 | 4 | 128 | 16 | Required number = 4*128/24 = 22 (21,3)
V.E. TEXT_3 | 0 | 128 | 38 | Required number = 1*128/24 = 6 (5.3)


Arrays and AutoMem method

The declaration of a V.E. variable is as follows:

Example:

var[4].name Auto

var[4].type UNS16

var[4].array_elements 0

When the AutoMem method is used, the parameters

var[?].index

var[?].size

are dropped, but above all the absence of the var[?].index parameter is the significant identifying feature of the AutoMem method.

The var[?].size parameter must also be dropped as otherwise exporting to PLC structures is not possible! Otherwise, this restriction does not apply because the description of functions entitled "External variables in the NC, Rev. 8, Page 13" still allows the parameter.


Generating the PLC structure out of a V.E. variable list

More:

button Generating the output file

button Output file structure

button Remarks


Generating the output file

The NC command #EXPORT VE generates an output file, which can be loaded into the PLC programming environment by "importing". At present, variable declarations can be generated for TwinCAT (3S Version 2.x) and KW-Software. The command acts on the currently selected channel.

More:

button CNC command #EXPORT VE


CNC command #EXPORT VE

The call of the CNC command #EXPORT VE imperatively requires specification of the PLC destination system as a parameter. The result is named accordingly.

NC command #EXPORT VE | Name of output file | Output directory
[TWINCAT] | plc_3s_ve_types_ch_?.exp | See TwinCAT SystemManager : CNC configuration à CNC task GEO à HLI tab HLI à entry box: NC file path
[KW] | plc_kw_ve_types_ch_?.exp | Application-specific

The question mark ? in the output file's name is a placeholder parameter for the CNC channel number.


Output file structure

More:

button Section 1: static type definition

button Section 2: type declaration from the V.E. variable list

button Section 3: channel-specific PLC parameters

button Section 4: global PLC parameters


Section 1: static type definition

Static type declarations are generated depending on the "use_extended_string_var" setting. The structure element [variable_name]".token", which ultimately corresponds to the string read or written by the NC, is of significance for the PLC programmer. The structure element f1_st serves to fill up unused bytes (see Section: 1.4.1).

Programming example

TYPE STRING_20:

STRUCT

token:STRING(20);

f1_st: ARRAY[0..2] OF BYTE;

END_STRUCT

END_TYPE

TYPE STRING_20_2:

STRUCT

token:STRING(20);

f1_st: ARRAY[0..106] OF BYTE;

END_STRUCT

END_TYPE


Section 2: type declaration from the V.E. variable list

All separate data types declared in a V.E. variable list are entered in Section 2 of the export file. The write operation itself is controlled via a sort algorithm to avoid "forward declarations".

Programming example

The "Position_and_Index" type contains an element of the "Position_in_Space" type.

VE declaration:

struct[1].name Position_in_Space

struct[1].element[0].name POffsX

struct[1].element[0].type REAL64

struct[1].element[1].name POffsY

struct[1].element[1].type REAL64

struct[1].element[2].name POffsZ

struct[1].element[2].type REAL64

struct[2].name Position_and_Index

struct[2].element[0].name Index

struct[?].element[0].type SGN32

struct[2].element[1].name Pos

struct[?].element[1].type Position_in_Space;

The following is created in the export file

TYPE Position_in_Space:

STRUCT

POffsX: LREAL;

POffsY: LREAL;

POffsZ: LREAL;

END_STRUCT

END_TYPE

TYPE Position_and_Index:

STRUCT

Index: INT;

Pos: Position_in_Space;

END_STRUCT

END_TYPE


Section 3: channel-specific PLC parameters

All V.E. variables that are assigned to the channel-specific data via var[?].scope = CHANNEL are entered in an additional PLC structure VE_CHANNEL_DATA_CH_?. The question mark in the name of VE_CHANNEL_DATA_CH_? is a placeholder parameter for the channel number.

Programming example (see also Section 1.3.2.2 )

Declared in the V.E. list

var[1].name Index_Element

var[1].type Position_and_Index

var[1].scope CHANNEL

The following is created in the export file

TYPE VE_CHANNEL_DATA_CH_1:

STRUCT

Index_Element: Position_and_Index;

END_STRUCT

END_TYPE


Section 4: global PLC parameters

As in the case of the channel-specific V.E. variables with the var[?].scope = GLOBAL attribute, a separate structure is generated for VE_GLOBAL_DATA_FROM_CH_?. Here also, the question mark in the type identifier is a placeholder parameter for the channel number.

Programming example

Declared in the V.E. list

var[2].name AX

var[2].type REAL64

var[2].scope GLOBAL

var[3].name AY

var[3].type REAL64

var[3].array_elements 3

var[3].scope GLOBAL

The following is then created in the export file

TYPE VE_GLOBAL_DATA_FROM_CH_1:

STRUCT

AX: LREAL;

AY: ARRAY[0..2] OF LREAL;

END_STRUCT

END_TYPE


Remarks

More:

button Alignment in the case of channel-specific and global data types

button Output of the index value in the output file


Alignment in the case of channel-specific and global data types

In terms of their structure, channel-specific and global PLC types correspond to the mapping of the CNC transfer memory. As the V.E. variable description basically permits memory gaps, so-called filling structures (alignment) are needed in the PLC type declaration. The filling structures are generated automatically during the export. Their identifiers begin with an "f" followed by a serial number, e.g. f1 : ARRAY[0..17] OF BYTE. An additional comment identifies the filling elements.

Programming example

TYPE VE_GLOBAL_DATA_FROM_CH_1:

STRUCT

Kopf_SP: ARRAY[0..2] OF INT;

f1:ARRAY[0..17] OF BYTE; (* Alignment *)

Kopf_AL: ARRAY[0..2] OF INT;

f2:ARRAY[0..17] OF BYTE; (* Alignment *)

Kopf_MPB_N: ARRAY[0..2] OF INT;

f3:ARRAY[0..17] OF BYTE; (* Alignment *)

Kopf_MPB_S: ARRAY[0..2] OF INT;

END_STRUCT

END_TYPE


Output of the index value in the output file

If the index method has been chosen for the memory organisation, the index value of the V.E. variable (var[?]=index) appears as a comment in the PLC structure.

Programming example

TYPE VE_GLOBAL_DATA_FROM_CH_1:

STRUCT

STR: STRING(20); (* index = 8 *)

f2:ARRAY[0..2] OF BYTE;

TEIL_1: UDINT;(* index = 9 *)

END_STRUCT

END_TYPE


Check of the V.E. variable declarations by the program

The declaration of the V.E. variables is checked before the PLC structure is generated by the program. Occurring error messages are logged in the (EXPORT) output file! Users must rectify these errors first before useful PLC code can be generated.

More:

button General error check: mixed memory organisation

button Error check when using the index method

button Error check when using the AutoMem method


General error check: mixed memory organisation

More:

button "CHANNEL"

button "GLOBAL"


"CHANNEL"

All V.E. variables of the "CHANNEL" memory must be declared within one channel with the same storage method. Either the index or the AutoMem method must be used to organise the memory. Mixed operation is not possible.

Error message | ERROR: CHANNEL: Mix up of memory organisation method is not permitted
Remedy | Use Index method or AutoMem method for memory organisation.


"GLOBAL"

The V.E. variables of the "GLOBAL" memory must be declared with the same storage method. Either the index or the AutoMem method must be used to organise the memory.

Error message | ERROR: CHANNEL: Mix up of memory organisation method is not permitted
Remedy | Use Index method or AutoMem method for memory organisation.


Error check when using the index method

More:

button Check of index values

button V.E. array variables: incorrect specification of the memory area

button Overlapping of memory areas


Check of index values

The index values entered in the variable description must constitute an ascending numerical order. Identical or lower index numbers in the numerical order are inadmissible and are reported as errors.

Error message | Index value is not ascending
Remedy | Enter index numbers in ascending order.
Example | var[0].index = 0; var[1].index = 5; var[2].index = 6; etc.


V.E. array variables: incorrect specification of the memory area

In the case of V.E. variables with the "Array_elements" attribute, a check is made as to whether the "size" attribute corresponds to the variable type used.

Error message | Size not compatible to variable type.
Remedy | Enter the correct value for var[?].size.
Example | Var[3].type = UNS32; (d.h. 4 Byte); var[3].size = 4
Note | The method checks the basic data types only.


Overlapping of memory areas

If the chosen index area for accommodating a variable is too small, the following index area would be overwritten with data. The neighbouring memory areas overlap. A corresponding check is made.

Error message | Memory overlapping Needed memory: 130Byte
Remedy | Increase the intended number of indexing operations.
Example | The memory occupied by an index corresponds to 24 bytes
Note | The memory required for variables is specified in the error log.


Error check when using the AutoMem method

More:

button Index values must not be programmed

button Memory requirement check


Index values must not be programmed

If the V.E. variable memory (GLOBAL or CHANNEL) is organised in accordance with the AutoMem method, parameterisation with var[?].index is inadmissible.

Error message | Declaration of var[?].index not allowed. Delete var[?].index out of the list
Remedy | Remove the var[?].index parameter from the variable description.


Memory requirement check

The memory value calculated internally in the controller is checked against management data (possibly declared incorrectly by the parameterisation). Typically, this error occurs when the var[?].size attribute has been erroneously programmed.

Note: the configured value of var[?].size is no longer available at the time of exporting. An incorrect configuration can only be indirectly concluded.

Error message | Declaration of var[?].size not allowed. Delete var[?].size out of the list.
Remedy | Remove the var[?].size parameter from the variable description.


Restrictions in the case of a multiple-channel controller structure

When the CNC starts up, for each NC channel the "GLOBALLY" declared variables are added incrementally to any existing variables. The memory layout in its entirety is only defined after start-up has completed. The start address to the common memory is than made available to the PLC.

The #EXPORT function can only be started in one channel.

o It therefore only uses the "GLOBAL" variables declared in that channel. Variables from other channels that are assigned other index values, for example, are invisible. Therefore, they are also no entered in the VE_GLOBAL_DATA_FROM_CH_? structure.

o For each channel-specific V.E. list, an independent
VE_GLOBAL_-DATA_FROM_CH_? structure comes into being and

o the "mixed operation" of index-based addressing and the Auto_Mem method that is possible due to an 'unfavourable' "GLOBAL" declaration cannot be detected across several channels.

Only the PLC programmer can provide a solution to the problems or a solution must be worked out in close cooperation with the person who creates the V.E. lists. There is no "typical" approach, however.

Below, you will find a few suggestions on how to reach a decision on the approach ultimately chosen:

Scenario (A)

All "GLOBAL" variables are declared in each channel (as a copy) and (if necessary) are only distinguished by the access methods (var[?].access_rights). Below, all VE_GLOBAL_DATA_-FROM_CH_? structures generated for each channel are identical. For access on the part of the PLC, it suffices to use one of the structures as the basis for access to the "GLOBAL" memory.

Scenario (B)

The "GLOBAL" variables of the various channels differ partly or completely. Thus, the generated PLC structures are different.

A first approach is to mix the exported structures manually and to access the memory with a new user-defined structure. The disadvantage here is that responsibility for correct access once again lies with the PLC programmer. Moreover, the operation must be repeated if only one of the V.E. lists changes and a new #EXPORT operation is triggered.

A second possible approach leaves the distinction according to channels as it is and defines several independent channel-specific pointers (to the identical GLOBAL memory) in the PLC. Here, the PLC programmer must make sure that the required variable is accessed with the 'right' PLC variable.


CNC - PLC type table

TwinCAT CNC: Overview

CNC  PLC type table

Type
comparison

CNC TYPE | PLC TYPE
BOOLEAN | BOOL
UNS08 | USINT
UNS16 | UINT
UNS32 | UDINT
SGN08 | SINT
SGN16 | INT
SGN32 | DINT
REAL64 | LREAL
STRING | Automatic types with alignment assignment.


Example

In the subsections that follow, this example describes presentation of the V.E. variables based on the V.E. variable list through representation in the exported file to integration in an existing PLC project.

More:

button VE variable list

button PLC structure generated out of the V.E. variable list

button PLC example


VE variable list

Assignments in the V.E. variable list

#

use_extended_string_var 0

#

anzahl_belegt 4

#

var[0].name FARBE

var[0].index 0

var[0].type UNS16

var[0].scope CHANNEL

var[0].access_rights READ_WRITE

var[0].array_elements 3

var[0].size 2

#

var[1].name TEXT

var[1].index 1

var[1].type STRING

var[1].scope CHANNEL

var[1].access_rights READ_WRITE

var[1]. array_elements 2

var[1].size 24

#

var[2].name INFO_IN

var[2].type OFF

var[2].scope GLOBAL

var[2].access_rights READ_WRITE

var[2]. array_elements 2

#

var[3].name INFO_OUT

var[3].type OFF

var[3].scope GLOBAL

var[3].access_rights READ_WRITE

var[3]. array_elements 2

var[3].create_hmi_interface 0

#

struct[0].name OFF

struct[0].element[0].name X

struct[0].element[0].type UNS16

struct[0].element[1].name Y

struct[0].element[1].type UNS16

#


PLC structure generated out of the V.E. variable list

Representation in the exported file

TYPE STRING_20:

STRUCT

token:STRING(20);

f1_st: ARRAY[0..2] OF BYTE;

END_STRUCT

END_TYPE

TYPE STRING_20_2:

STRUCT

token:STRING(20);

f1_st: ARRAY[0..106] OF BYTE;

END_STRUCT

END_TYPE

TYPE OFF:

STRUCT

X: UINT;

Y: UINT;

END_STRUCT

END_TYPE

TYPE VE_CHANNEL_DATA_CH_1:

STRUCT

FARBE: ARRAY[0..2] OF UINT;(* index = 0 *)

f1:ARRAY[0..17] OF BYTE;

TEXT: ARRAY[0..1] OF STRING_20;(* index = 1 *)

END_STRUCT

END_TYPE

TYPE VE_GLOBAL_DATA_FROM_CH_1:

STRUCT

INFO_IN: ARRAY[0..1] OF OFF;

INFO_OUT: ARRAY[0..1] OF OFF;

END_STRUCT

END_TYPE


PLC example

Integration in running PLC

A PLC program for checking the generated PLC structure from Section 1.7.2

VAR

(* Use generated structure descriptions *)

p_ve_chan_1 : POINTER TO VE_CHANNEL_DATA_CH_1;

p_ve_globe : POINTER TO VE_GLOBAL_DATA_FROM_CH_1;

text : STRING(20);

END_VAR

(* Ensure that the internal management data is initialised *)

Hli(bStart := TRUE);

IF Hli.bInitialized = TRUE AND Hli.bError = FALSE THEN

(* Provide pointer to structure(s) *)

p_ve_chan_1 := ADR( pVE[1]^.addr^.AHLI_UNS32_Data);

p_ve_globe := ADR(pVEGlob^.addr^.AHLI_UNS32_Data);

(* Work with the variables (read, write) *)

text := p_ve_chan_1^.TEXT[0].token;

p_ve_chan_1^.FARBE[1] := 2;

END_IF


Short-form instructions

Short-form
instructions using the export functionality on V.E. variables

Procedure on the basis of TwinCAT

1. Export the V.E. variables from the CNC with the export command
#EXPORT VE[TWINCAT]

2. Open the export file with an editor and check for any warnings or errors. These are displayed in a text in the file.

3. Import the export file into the existing PLC project; this requires access to the HLI

4. Create pointers to structures
(* Use the generated structure descriptions *)
p_ve_chan_1 : POINTER TO VE_CHANNEL_DATA_CH_1;
p_ve_globe : POINTER TO VE_GLOBAL_DATA_FROM_CH_1;

5. Cyclically update the pointers to the structures
(* Provide pointers to structure(s) *)
p_ve_chan_1 := ADR( pVE[1]^.addr^.AHLI_UNS32_Data);
p_ve_globe := ADR(pVEGlob^.addr^.AHLI_UNS32_Data);

6. Integrate read and write access to variables
p_ve_globe^.VARIABLE_1 := 22; (*Write access*)
gl_ar_var_3 := p_ve_globe^.VARIABLE_1; (*Read access*)