The six lives of the process variables

The OPC specification describes the item object as a representation of a process value in the OPC server: This value can be read or written via the item object; optional parameters enable limit value monitoring, for example. Additional information can be used to determine transmission errors and the time of data exchange. This specification is fully supported in VisiWin, but the following additional extensions are possible due to the system structure:

  • Operation of VisiWin drivers as part of the process variable definitions
  • Parallel operation of several communication components (VisiWin(.NET) driver and OPC server), which only represent a single data pool from the application's point of view
  • Optimisation procedure for block-oriented data access via data type extensions
  • Optimisation procedure for multiple clients (exclusion of multiple requests)
  • Conversion of process variable values depending on the current language of a client or the value of a control variable

These options require an extension of the process variable definition in VisiWin. The most important properties for accessing a process variable in the components of the process connection are described below.

In the SPS

In the PLC, a process variable represents a process value that can be exchanged via the interface protocol. To be able to read or write values from the PLC, the start address and the byte length must be known.

In a PLC that supports symbolic addressing, the start address can be an identifier that makes a statement about the use of the process value. The PLC uses an identifier table to determine the corresponding cell in the memory. If symbolic addressing is not supported, the PLC can access the addressed memory cell by directly specifying a specific address identifier.

The length determines the number of bytes required for the complete transfer of the value from the PLC memory.

In the communication component

Communication components are the links between the variable server and the PLC interface. The task of the communication component is to fulfil the data requirements of the variable server. On the PLC side, the process values must be addressed via the address/length definition that is understandable for the PLC. On the variable server side, the OPC server and VisiWin(.NET) driver exhibit fundamentally different behaviour:

VisiWin drivers expect exactly the PLC-understandable information "start address" and "length" from the variable server to access a process value. The variable server must therefore prepare the information contained in a process variable definition appropriately.

In OPC servers, a process value is addressed via the so-called ItemID. The ItemID uniquely identifies the object that represents the process value in the OPC server. It can either be the start address (symbolic or not) or a new and therefore more comprehensible identifier for the process value. The length of the process value to be exchanged is determined by the data type. OPC servers can process the specification of a data type. However, in order to be able to instantiate the object, this information must be known before the actual data exchange. The information about items is made available to the OPC server either in the form of a definition list during initialisation (own definition file/OPC server project file) or at runtime (CallR server).

Items are assigned to groups at runtime, which are used to control data exchange. For example, deactivating a group can stop access to all the items it contains.

Both VisiWin(.NET) drivers and OPC servers create a memory image of the PLC. They have their own cycle times in which the requested process variables are read from the PLC. However, this cycle time has nothing to do with the return to the variable server. While VisiWin drivers are read out in the cycle of the variable server, OPC servers have the ability to return the requested data asynchronously with an adjustable sampling time for each group.

In the project file

The project file contains all data relevant to the project. In the development environment, definitions are configured in the editors. Control elements that are to create a reference to a definition at runtime can list the definitions contained in the project file for selection. At runtime, the definitions are interpreted by the responsible server component.

In the variable server

The variable server is the link between the communication components, the visualisation applications and other systems (alarm management, trends, etc.). During initialisation, it uses the definitions in the project file to create a memory image of all process variables, the so-called process file. If read or write access to a process value is requested, the variable server activates access to the corresponding variable in the communication component. After this initialisation, the data is exchanged cyclically or triggered.

A process value is requested via the process variable identifier from the project file and the specification of the communication component. A process value can therefore have a total of three different identifiers:

  1. The address information in the PLC,
  2. The ItemID in the communication component and
  3. The identifier in the visualisation.

However, this does not make sense. The assignment of an identifier in the project file definition should only be used if the PLC does not support symbolic addressing and the communication component does not provide a way of naming the process value. This is the case with VisiWin(.NET) drivers, for example.

The definitions in the VisiWin project file contain the option of configuring extended data types (fields and structures). Access to a process variable with data type extension enables a considerable increase in system performance. Process values can thus be transferred in blocks.

In the variable client

The variable client manages the data exchange of a visualisation application. Loaded control elements log on to the variable client. This forwards the request for process values to the variable server. After logging in, the data exchange is executed cyclically or event-driven as required. The variable client also creates a process image, but only for the process values it requires.

In the control element

The following information is required for a control element to gain access to a process value in the PLC:

  • To which server component must the request be directed (multiserver project, network path)?
  • Which communication component can be used to reach the process value (communication channel, network path)?
  • How must the process variable be addressed in the communication component (ItemID)?
  • What is the index of the field element if the process variable is defined as a field?
  • What is the name of a structure element if the process variable has been defined as a structure?

At development time, the definitions of the project file are listed in the variable selection dialogue. If a process variable is of the data type of a structure or a field, the structure and field elements are listed under the process variable definition. The name and the display on the properties page suggest the selection of a process variable. In reality, however, a unique identifier is selected for the process value in the system. If an entry is selected, an identifier appears as a result which, in addition to the ItemID, also contains the name of the communication channel and possibly also the selected structure/field element. The handling in the control elements is therefore fully OPC-compliant. However, the resolution of the selected identifier must be carried out in the various components of the process connection.

See also