Slow Control System: Difference between revisions
No edit summary |
No edit summary |
||
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]] | ||
Line 135: | Line 137: | ||
Templates for slow control frontends are available in the MIDAS package - see [[Frontend Operation#Introduction|Frontend templates]]. | Templates for slow control frontends are available in the MIDAS package - see [[Frontend Operation#Introduction|Frontend templates]]. | ||
[[Category:Slow Control]] [[Category:Frontend]] |
Revision as of 12:28, 8 July 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.
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.