Tracking of RT-Actions

experimental (proposition)

Background

Synchronized control of the accelerator equipment is achieved by reaction to timing-events, distributed by the timing-master. In FAIR controls, such synchronized activities will be spread over many separate units, in area and in time:

• The pieces of equipment belong to (listen to timing-events from) a number of timing-areas, fed with specific timing-events
• Timing-events are grouped in time-slots, the beam-processes. Equipment in general for each beam process provides a separate set of setting data.

Tracking of control actions to identify the reason of erroneous operation of a piece of equipment therefor can be laborious. This can be even trickier when a piece of equipment is not reacting immediately to a control action: E.g. a magnet power supply takes some time to reach a modified setting value. In such cases the momentary state of the equipment (e.g. the deliverd current) may depend on the setting value not oly on the setting value of the momentary beam-process but also on the value of the previous beam-process, or even on values of several beam-processes before. Analysis of errors in the performance of equipment, especially when they occur only from time to time in special circumstances, may therefor often require to analyse the history of actions with the eqquipment.

General Activity Tracking

To keep track on the history of controls activities with the equipment, a history buffer is proposed. It should hold, e.g. in a ring-buffer, at least the following information:

• Type of command to the equipment, e.g. sending a new setting value, in combination with the data assigned with the command (e.g. the new setting value).
• Occurance of a timing-event which triggers actions directly by interfacing hardware (e.g. generating an output-pulse, triggered by a tag on the SCU-bus). Real-time actions have to be provided to track receptions of such timing-events.

Each entry in the history buffer has to be marked by

• Time when the action is performed, or when (in case of hardware-triggers) the timing-event is monitored. In general, the time can be taken from the acquisition context provided in the real-time action.
• Timing-event pattern, as provided in the real-time action acquisition context. This timing-event pattern especially contains the number of the present beam process.

The history buffer should be big enough to cover some seconds of history, or at least one complete series of repetitive activities (as described by the pattern in the sequencing).

To gain Access to this history buffer, each device should

• provide a property to read the contents of the buffer
• the FESA monitoring mechanism may be used to provide the buffer

As an idea: It may make sense to provide the setting-history in the context of acquisition data

• for each acquisition data which is taken synchronized (triggered by a timing-event) provide the most recent history-entries in additional value-items.

Specific Activity Tracking

Some devices may require even more care, e.g. magnet power converters in the fragment separators.

To not depend on hystersis effects, in the fragment seperators magnets are set by several times setting alternatively to maximum and to minimum current, and then to the desired current. Then, for the Duration of the experiment, this setting must not be changed: When the current is changed once, and then set back to the desired current, the field of the magnet will be changed. Such modification of the field will change the experimental conditions which cannot be tolerated. So, even if the power converters are operated timing-driven multiplexed, the setting of the power converter must not be changed during an experiment.

Tracking for cases when equipment settings are modified accidentally should be implemented in the front-ends, e.g. like:

• Store the value whis is send to the power converter.
• Whenever setting data are sent to the powerr converter, compare the value of the new setting with the stored last setting.
• When both values differ, store last and present value in a ring-buffer, and add multiplexing context (especially beam process and timestamp)

The contents of the ring-buffer has to be provided by a property. The depth of the ringbuffer can be very small: Main interest is whether data has changed since last hysteresis-cleaning cycle.

in a special sequence,