Device Access in the GSI Control System

GSI Equipment Modeling

GSI handles the accelerator equipment according of a device/property model.

In the accelerator control system equipment is modelled in an object oriented way as self-contained units, the devices. A device represents a functional unit in the accelerator, like a magnet with its power supply, a RF acceleration device, or a beam diagnostig element like a current transformer or a position monitor.

A device is referenced via its name, the nomenclature. Nomenclatures in the control system are unique, so any device can be identified uniquely by its nomenclature. Nomenclatures consists of up to 8 alphanumerical upercase characters and underscores.

Devices itself are modelled by properties. Reading or modifying a devices's states, is by executing an assigned property. Control system properties correspond to methods in the object oriented paradigm. However, all properties are constructed to a common scheme. Access to a device is via the device's properties only, no other access to device's characteristics or device's parameters is possible.

Properties may set or read back data of the device and / or may execute some action in the device (like a device's reset). Accordingly, properties are classified as

• read: read data from the device (read the device's state)
• write: write data to the device (modify the device's state)
• call: no data exchange, only execute a device's action

Properties are identified by a name, the property name. For each device the name of the properties, for a given property class, is unique.

Properties are identified by their names. Property names consist of up to 8 alphanumerical characters. A property, like setting a power supplies current, is executed by passing the property name and the data to an execute-method of the device for which the property is to be called. A triple of device's execute methods exists, specific for read, write and call properties.

Devices are grouped to types. Devices of the same type are modeled by the same properties.

Read and write (as well as call) access to a decvice's characteristic is handled by different properties. Setting the current of a power supply (write) and reading it back (read) is handled by two independend properties, one of class write and one of class read. Generally, both properties then hace the same name, representing the physical quantity which is accessed by the properties.

The basic concepts of how to access devices in the GSI control system can be seen in a hopefully self-explaining example, written in Python (see here).

>>> import devacc                  # load remote device access interface
>>> d = devacc.Device("GUA5QD72")  # create device proxy object for nomenclature GUA5QD72
>>> value = d.read("CURRENTS")     # execute read-Property CURRENTS, store returned data in value
>>> value *= 0.75                  # calculate a new value
>>> d.write("CURRENTS", value)     # and set it in the device

Devices in the control system, at a first approach, correspond to physical pieces of equipment. However, a device is only a logical entity: It corresponds to some self contained unit, which can be operated independently from other devices.

This means, a physical piece of equipment can host several units, each represented as a device which then can be operated independently. As an example, one control unit can handle several pressurized air actuators. Then each of these actuators is modelled as an independent device. On the other hand, several pieces of equipment can be combined to one device which then is accessible as a whole.

However, control system applicitions dealing with devices generally don't have to take care of the physical implementation: They only work with the logical model "device".

Property Data

To provide sufficient flexibility to handle data in a device access, data is exchanged in a data container, objects of class AccData .

An AccData object can hold elements of the following basic types

• integer elements
  • 1, 2, 4, 8 bytes in size
  • signed and unsigned
• float elements
  • 32- and 64-bit size
• strings

An AccData object can hold mixed data types, it can hold any sequence of the basic types.

The content is stored combined with type information which is accessible for data extraction. Data can be extracted either typesafe (requesting a specific type) or converted. For converted extraction, data is converted to the requested type, as long as possible (e.g. from integer to float or vice versa).

Device access supports, besides the property-data to be exchanged, additional data called property-parameter. Depending on the specific property, such property-parameter may specify the execution of the property call. Property-parameter and property-data both use objects of the AccData container class.

Property-parameters must provided in all device access calls. However, most properties don't request property-paramter. Then an empty AccData object may be used.

Multiplexing: Virtual Accelerator

The GSI accelerators can, from pulse to pulse, handle different beams. Such pulse-to-pulse multiplexing between different beams is widely used in routine machine operation.

For each of the beams devices have to be set to different set values, with different actual values. The front end controller can handle up to 16 different beams. For each of the possible beams seperate sets of data, reference as well as actual values, can be hold on the front-end controller. Each of the data sets is indicated by a number in the range of 0 to 15, the virtual accelerator number.

The virtual accelerator number has to be provided as a parameter in remote device access.

Access Modes

For all three property classes (read/write/call) three access modes are supported:

• synchronous
• asynchronous
• connected (subscribed)