Difference between revisions of "Slow Control System"

From MidasWiki
Jump to navigation Jump to search
Line 7: Line 7:
 
</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==
 
==MIDAS Slow Control System==
Line 135: Line 135:
 
  }
 
  }
  
 +
Templates for slow control frontends are available in the MIDAS package - see [[Frontend Operation#Frontend Templates|Frontend templates]].
  
Templates for slow control frontends are available in the MIDAS package - see [[Frontend Operation#Introduction|Frontend templates]].
+
 
 +
= 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://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]].
  
 
[[Category:Slow Control]] [[Category:Frontend]]
 
[[Category:Slow Control]] [[Category:Frontend]]

Revision as of 13:51, 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.

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.

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.


Slow Control variables can be accessed through the web using the mhttpd web server Equipment Page and MSCB Page.

This can be done by setting the variable names under the Settings subdirectory of the corresponding ODB /Equipment tree. The variable description is given under History_System . The History Page will also be automatically activated if mlogger is running.


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


Example of Equipment Declaration (see also Equipment List parameters Class Driver and Device Driver List) :

 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;
  }
 ....
}

Templates for slow control frontends are available in the MIDAS package - see Frontend templates.


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.