Difference between revisions of "Slow Control System"

From MidasWiki
Jump to navigation Jump to search
 
Line 1: Line 1:
 
{{Pagelinks}}
 
{{Pagelinks}}
  
== Links ==
+
= 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==
+
= 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.  
  
==MIDAS Slow Control System==
+
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 18: 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 29: 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 35: 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 can be accessed through the web using the [[mhttpd]] web server  [[Equipment Page]] and [[MSCB Page]].
+
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.
  
This can be done by setting the variable names under the <span style="color: purple; font-style:italic;">Settings</span> subdirectory of the corresponding ODB <span style="color: purple; font-style:italic;">/Equipment</span> tree. The variable description is given under [[History_System]] .
+
The [[mhttpd]] (MIDAS Web Server) [[History Page]] will also be automatically activated if [[mlogger]] is running.
The [[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 93: Line 100:
  
  
Example of [[Equipment List Parameters|Equipment Declaration]]   (see also Equipment List parameters [[Equipment List Parameters#Class Driver|Class Driver]] and    [[Equipment List Parameters#Device Driver List|Device Driver List]]) : 
+
== 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 108: 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 135: Line 148:
 
  }
 
  }
  
Templates for slow control frontends are available in the MIDAS package - see [[Frontend Operation#Frontend Templates|Frontend templates]].
+
== Multithreaded Slow Control Frontends ==
 
 
 
 
= 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 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:
  
Line 146: Line 156:
 
This modification required some minor modifications to existing class and device drivers (see [https://midas.triumf.ca/elog/Midas/289] for details).  
 
This modification required some minor modifications to existing class and device drivers (see [https://midas.triumf.ca/elog/Midas/289] for details).  
  
To enable multithread support in a slow-control frontend, see [[Equipment List Parameters#Device Driver List|Device Driver List]].
+
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]]
 
[[Category:Slow Control]] [[Category:Frontend]]

Latest revision as of 16:09, 10 August 2015


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).


Class driver, Device and Bus driver in the slow control system

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.