Slow Control System: Difference between revisions
No edit summary |
mNo edit summary |
||
(3 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
{{Pagelinks}} | |||
= Links = | |||
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3"> | <div style="column-count:3;-moz-column-count:3;-webkit-column-count:3"> | ||
* [[Frontend user code]] | * [[Frontend user code]] | ||
* [[Equipment List Parameters]] | * [[Equipment List Parameters]] | ||
* | |||
</div> | </div> | ||
= Introduction= | |||
Slow Control Systems are used for setup and monitoring of hardware that is not time-critical, and can be run at a low priority. Slow Control systems in a typical experiment are often used to setup and/or monitor components such as high voltage modules, temperature sensors, pressure gauges, leak detectors, RF generators, PID controllers etc. often from a large number of hardware vendors. | Slow Control Systems are used for setup and monitoring of hardware that is not time-critical, and can be run at a low priority. Slow Control systems in a typical experiment are often used to setup and/or monitor components such as high voltage modules, temperature sensors, pressure gauges, leak detectors, RF generators, PID controllers etc. often from a large number of hardware vendors. | ||
Examples of Device and Class Drivers can be found under [[Environment Variables#MIDASSYS|$MIDASSYS]]/drivers, and templates for slow control frontends are also available in the MIDAS package - see [[Frontend user code#Frontend Templates|Frontend templates]]. | |||
= MIDAS Slow Control System= | |||
In the Midas Slow Control System, instead of talking directly to each other, [[Frontend Operation#Frontend|Frontend]] and control programs exchange information through the ODB. If several types of hardware are to be included in a Slow Control System, they may be assigned to a separate Slow Control Equipments. Each Slow Control Equipment is assigned a corresponding ODB subtree under <span style="color: purple; font-style:italic;">/Equipment</span>. This tree contains variables needed to control the equipment as well as variables measured by the equipment. | In the Midas Slow Control System, instead of talking directly to each other, [[Frontend Operation#Frontend|Frontend]] and control programs exchange information through the ODB. If several types of hardware are to be included in a Slow Control System, they may be assigned to a separate Slow Control Equipments. Each Slow Control Equipment is assigned a corresponding ODB subtree under <span style="color: purple; font-style:italic;">/Equipment</span>. This tree contains variables needed to control the equipment as well as variables measured by the equipment. | ||
Line 16: | Line 21: | ||
* a Current array which contains the current drawn from each channel. | * a Current array which contains the current drawn from each channel. | ||
To change the voltage of a channel, a control program writes the desired value to the Demand array. This array is connected to the high voltage [[Frontend Operation#Frontend|Frontend]] via an ODB hot-link. Each time the Demand value is modified, the frontend receives a notification and sets the new value. In the other direction, the frontend continuously reads the voltage and current values from all channels and updates the appropriate ODB array(s) if there has been a significant change. | To change the voltage of a channel, a control program writes the desired value to the Demand array. This array is connected to the high voltage [[Frontend Operation#Frontend|Frontend]] via an ODB hot-link. Each time the Demand value is modified, the frontend receives a notification and sets the new value. In the other direction, the frontend continuously reads the voltage and current values from all channels and updates the appropriate ODB array(s) if there has been a significant change. | ||
This design has a possible drawback due to the fact that the ODB is the key element of that control. Any failure or corruption of the database can result in incorrect driver control. Therefore it is not recommended to use this system to control systems that need redundancy for safety purposes. On the other hand, this system has several advantages: | This design has a possible drawback due to the fact that the ODB is the key element of that control. Any failure or corruption of the database can result in incorrect driver control. Therefore it is not recommended to use this system to control systems that need redundancy for safety purposes. On the other hand, this system has several advantages: | ||
Line 27: | Line 32: | ||
Since all slow control values are contained in the ODB, they are automatically dumped to the logging channels. The slow control frontend uses the same framework as the normal frontend, and behaves similarly in many respects. They also create periodic events that contain the slow control variables and are logged together with trigger and scaler events. The only difference is that a routine is called periodically from the framework that has the task of reading channels and updating the ODB. | Since all slow control values are contained in the ODB, they are automatically dumped to the logging channels. The slow control frontend uses the same framework as the normal frontend, and behaves similarly in many respects. They also create periodic events that contain the slow control variables and are logged together with trigger and scaler events. The only difference is that a routine is called periodically from the framework that has the task of reading channels and updating the ODB. | ||
To access slow control hardware, a two-layer driver concept is used. The upper layer is a "class driver", which establishes the connection to the ODB variables and contains high level functionality like channel limits, ramping etc. It uses a "device driver" to access the channels. These drivers implement only very simple commands like "set channel" and "read channel". The device drivers themselves can use bus drivers like RS232 or GPIB to control the actual device. | To access slow control hardware, a two-layer driver concept is used. The upper layer is a "class driver", which establishes the connection to the ODB variables and contains high level functionality like channel limits, ramping etc. It uses a "device driver" to access the channels. These drivers implement only very simple commands like "set channel" and "read channel". The device drivers themselves can use bus drivers like RS232 or GPIB to control the actual device. See also [https://midas.psi.ch/mscb/ MIDAS Slow Control Bus (MSCB)]. | ||
[[File:classes2.jpg|Class driver, Device and Bus driver in the slow control system]] | [[File:classes2.jpg|Class driver, Device and Bus driver in the slow control system]] | ||
Line 33: | Line 39: | ||
The separation into class and device drivers has the advantage that it is very easy to add new devices, because only the simple device driver needs to be written. All higher functionality is inherited from the class driver. The device driver can implement richer functionality, depending on the hardware. For some high voltage devices there is a current read-back for example. This is usually reflected by additional variables in the ODB, i.e. a Current array. Frontend equipment uses exactly one class driver, but a class driver can use more than one device driver. This makes it possible to control several high voltage devices for example with one frontend in one equipment. The number of channels for each device driver is defined in the slow control frontend. Several equipments with different class drivers can be defined in a single frontend. | The separation into class and device drivers has the advantage that it is very easy to add new devices, because only the simple device driver needs to be written. All higher functionality is inherited from the class driver. The device driver can implement richer functionality, depending on the hardware. For some high voltage devices there is a current read-back for example. This is usually reflected by additional variables in the ODB, i.e. a Current array. Frontend equipment uses exactly one class driver, but a class driver can use more than one device driver. This makes it possible to control several high voltage devices for example with one frontend in one equipment. The number of channels for each device driver is defined in the slow control frontend. Several equipments with different class drivers can be defined in a single frontend. | ||
The Slow Control variables can be accessed through the web using the [[mhttpd]] web server [[Status Page#Equipment Information]] or [[MSCB Page]] if using MIDAS Slow Control Bus. | |||
Slow Control variables may also be sent to the [[History System]] (see [[History System#Frontend History Event]]). History tags for each variable are derived from the name of the variable in {{Odbpath|path=/Equipment/<equipment name>/Settings/Names}} array if present. See [[/History ODB tree#Tags subtree]] for details. | |||
The [[mhttpd]] (MIDAS Web Server) [[History Page]] will also be automatically activated if [[mlogger]] is running. | |||
== Example of a Slow Control Equipment in ODB == | |||
The following example shows the ODB keys of a slow control equipment called "Epics" | |||
Key name Type #Val Size Last Opn Mode Value | Key name Type #Val Size Last Opn Mode Value | ||
Line 91: | Line 100: | ||
== Slow Control Frontend == | |||
A [[Frontend user code|Frontend]] for Slow Control is similar to a regular frontend, except the Equipment List contain the | |||
[[Equipment List Parameters#Class Driver|Class Driver]] and [[Equipment List Parameters#Device Driver List|Device Driver List]], | |||
which are normally left blank in non-Slow Control Frontends. | |||
=== Example of [[Equipment List Parameters|Equipment Declaration]] === | |||
EQUIPMENT equipment[] = { | EQUIPMENT equipment[] = { | ||
Line 106: | Line 121: | ||
... | ... | ||
Example of [[Equipment List Parameters#Readout Routine|readout routine]] | === Example of [[Equipment List Parameters#Readout Routine|readout routine]] === | ||
INT cd_hv_read(char *pevent, int offset) | INT cd_hv_read(char *pevent, int offset) | ||
Line 132: | Line 147: | ||
.... | .... | ||
} | } | ||
== Multithreaded Slow Control Frontends == | |||
The Midas slow control system was modified in 2006 to support multi-threaded slow control frontends. Each device gets its own thread in the front-end, which has several advantages: | |||
* the communication of all devices runs in parallel and therefore is much faster | |||
* slow devices can no longer block the frontend. Response times to run transitions etc. therefore become much faster. | |||
This modification required some minor modifications to existing class and device drivers (see [https://daq00.triumf.ca/elog-midas/Midas/289] for details). | |||
To enable multithread support in a [[Frontend user code#Frontend Templates|Slow Control Frontend]], see [[Equipment List Parameters#Device Driver List|Device Driver List]]. | |||
[[Category:Slow Control]] [[Category:Frontend]] |
Latest revision as of 03:44, 1 May 2024
Links
Introduction
Slow Control Systems are used for setup and monitoring of hardware that is not time-critical, and can be run at a low priority. Slow Control systems in a typical experiment are often used to setup and/or monitor components such as high voltage modules, temperature sensors, pressure gauges, leak detectors, RF generators, PID controllers etc. often from a large number of hardware vendors.
Examples of Device and Class Drivers can be found under $MIDASSYS/drivers, and templates for slow control frontends are also available in the MIDAS package - see Frontend templates.
MIDAS Slow Control System
In the Midas Slow Control System, instead of talking directly to each other, Frontend and control programs exchange information through the ODB. If several types of hardware are to be included in a Slow Control System, they may be assigned to a separate Slow Control Equipments. Each Slow Control Equipment is assigned a corresponding ODB subtree under /Equipment. This tree contains variables needed to control the equipment as well as variables measured by the equipment.
In the case of a high voltage equipment this is
- a Demand array which contains voltages to be set,
- a Measured array which contains read back voltages and
- a Current array which contains the current drawn from each channel.
To change the voltage of a channel, a control program writes the desired value to the Demand array. This array is connected to the high voltage Frontend via an ODB hot-link. Each time the Demand value is modified, the frontend receives a notification and sets the new value. In the other direction, the frontend continuously reads the voltage and current values from all channels and updates the appropriate ODB array(s) if there has been a significant change.
This design has a possible drawback due to the fact that the ODB is the key element of that control. Any failure or corruption of the database can result in incorrect driver control. Therefore it is not recommended to use this system to control systems that need redundancy for safety purposes. On the other hand, this system has several advantages:
- The control program does not need any knowledge of the frontend, it only talks to the ODB.
- The control variables only exist at one place that guarantees consistency among all clients.
- Basic control can be done through the mhttpd web interface (or odbedit )without the need of a special control program.
- A special control program can be tested without having a frontend running.
- In case of n frontend and m control programs, only n+m network connections are needed instead of n*m connection for point-to-point connections.
Since all slow control values are contained in the ODB, they are automatically dumped to the logging channels. The slow control frontend uses the same framework as the normal frontend, and behaves similarly in many respects. They also create periodic events that contain the slow control variables and are logged together with trigger and scaler events. The only difference is that a routine is called periodically from the framework that has the task of reading channels and updating the ODB. To access slow control hardware, a two-layer driver concept is used. The upper layer is a "class driver", which establishes the connection to the ODB variables and contains high level functionality like channel limits, ramping etc. It uses a "device driver" to access the channels. These drivers implement only very simple commands like "set channel" and "read channel". The device drivers themselves can use bus drivers like RS232 or GPIB to control the actual device. See also MIDAS Slow Control Bus (MSCB).
The separation into class and device drivers has the advantage that it is very easy to add new devices, because only the simple device driver needs to be written. All higher functionality is inherited from the class driver. The device driver can implement richer functionality, depending on the hardware. For some high voltage devices there is a current read-back for example. This is usually reflected by additional variables in the ODB, i.e. a Current array. Frontend equipment uses exactly one class driver, but a class driver can use more than one device driver. This makes it possible to control several high voltage devices for example with one frontend in one equipment. The number of channels for each device driver is defined in the slow control frontend. Several equipments with different class drivers can be defined in a single frontend.
The Slow Control variables can be accessed through the web using the mhttpd web server Status Page#Equipment Information or MSCB Page if using MIDAS Slow Control Bus.
Slow Control variables may also be sent to the History System (see History System#Frontend History Event). History tags for each variable are derived from the name of the variable in /Equipment/<equipment name>/Settings/Names array if present. See /History ODB tree#Tags subtree for details.
The mhttpd (MIDAS Web Server) History Page will also be automatically activated if mlogger is running.
Example of a Slow Control Equipment in ODB
The following example shows the ODB keys of a slow control equipment called "Epics"
Key name Type #Val Size Last Opn Mode Value --------------------------------------------------------------------------- Epics DIR Settings DIR Channels DIR Epics INT 1 4 25h 0 RWD 3 Devices DIR Epics DIR Channel name STRING 10 32 25h 0 RWD [0] GPS:VAR1 [1] GPS:VAR2 [2] GPS:VAR3 Names STRING 10 32 17h 1 RWD [0] Current [1] Voltage [2] Watchdog Update Threshold MeasureFLOAT 10 4 17h 0 RWD [0] 2 [1] 2 [2] 2 Common DIR Event ID WORD 1 2 17h 0 RWD 3 Trigger mask WORD 1 2 17h 0 RWD 0 Buffer STRING 1 32 17h 0 RWD SYSTEM Type INT 1 4 17h 0 RWD 4 Source INT 1 4 17h 0 RWD 0 Format STRING 1 8 17h 0 RWD FIXED Enabled BOOL 1 4 17h 0 RWD y Read on INT 1 4 17h 0 RWD 121 Period INT 1 4 17h 0 RWD 60000 Event limit DOUBLE 1 8 17h 0 RWD 0 Num subevents DWORD 1 4 17h 0 RWD 0 Log history INT 1 4 17h 0 RWD 1 Frontend host STRING 1 32 17h 0 RWD hostname Frontend name STRING 1 32 17h 0 RWD Epics Frontend file name STRING 1 256 17h 0 RWD feepic.c Variables DIR Demand FLOAT 10 4 0s 1 RWD [0] 1.56 [1] 120 [2] 87 Measured FLOAT 10 4 2s 0 RWD [0] 1.56 [1] 120 [2] 87 Statistics DIR Events sent DOUBLE 1 8 17h 0 RWDE 26 Events per sec. DOUBLE 1 8 17h 0 RWDE 0 kBytes per sec. DOUBLE 1 8 17h 0 RWDE 0
Slow Control Frontend
A Frontend for Slow Control is similar to a regular frontend, except the Equipment List contain the Class Driver and Device Driver List, which are normally left blank in non-Slow Control Frontends.
Example of Equipment Declaration
EQUIPMENT equipment[] = { { "HV", // equipment name { ... "FIXED", /* format */ ... cd_hv_read, /* readout routine */ cd_hv, /* class driver main routine */ hv_driver, /* device driver list */ NULL, /* init string */ }, ...
Example of readout routine
INT cd_hv_read(char *pevent, int offset) { float *pdata; DWORD *pdw; HV_INFO *hv_info; EQUIPMENT *pequipment; // pequipment = *((EQUIPMENT **) pevent); hv_info = (HV_INFO *) pequipment->cd_info; // if (hv_info->format == FORMAT_FIXED) { memcpy(pevent, hv_info->demand, sizeof(float) * hv_info->num_channels); pevent += sizeof(float) * hv_info->num_channels; // memcpy(pevent, hv_info->measured, sizeof(float) * hv_info->num_channels); pevent += sizeof(float) * hv_info->num_channels; // memcpy(pevent, hv_info->current, sizeof(float) * hv_info->num_channels); pevent += sizeof(float) * hv_info->num_channels; // return 3 * sizeof(float) * hv_info->num_channels; } .... }
Multithreaded Slow Control Frontends
The Midas slow control system was modified in 2006 to support multi-threaded slow control frontends. Each device gets its own thread in the front-end, which has several advantages:
- the communication of all devices runs in parallel and therefore is much faster
- slow devices can no longer block the frontend. Response times to run transitions etc. therefore become much faster.
This modification required some minor modifications to existing class and device drivers (see [1] for details).
To enable multithread support in a Slow Control Frontend, see Device Driver List.