Slow control: overview

Slow control means setting up and monitoring hardware that isn't time-critical, such as high voltage supplies, temperature sensors, pressure gauges, power supplies and PID controllers. Unlike the readout of triggered data, slow control equipment is usually read every few seconds, and its values are mostly used through the ODB and the history rather than in the data files.

Midas also includes MSCB (the midas slow control bus), a fieldbus for connecting many low-cost slow control devices to a computer. You can use MSCB devices without midas, from the MSCB webpage, from a slow control frontend, or from your own code. See Slow control: MSCB.

Do you need a slow control framework?

Midas has optional slow control frameworks, which help you write frontends for this kind of equipment. You don't have to use them. Many experiments just write a normal frontend, even for their slow control equipment: a periodic equipment that reads the devices, writes the values to a bank, and checks the ODB for new settings. This is often the simplest choice, especially if you use the TMFE or Python frontend frameworks, which the slow control frameworks don't support.

Midas has two slow control frameworks, and a frontend uses one or the other. In the original class driver framework, you choose a class driver (e.g. for high voltage) and a device driver for your hardware. In the newer mdev framework, each device is a C++ object that the frontend code creates. See Choosing a framework for the pros and cons of each.

The frameworks look different in the equipment's ODB directory:

	Class driver framework	mdev framework
Values	`Variables/Demand` and `Variables/Measured` (`Input` and `Output` for the `multi` class driver)	Chosen by each mdev driver, e.g. `Variables/MSCB`
Settings	Set in the ODB, e.g. limits and thresholds	Mostly written from the frontend code each time it starts
How to recognise it	`Settings` has a `Devices` subdirectory	No `Settings/Devices`

Not for safety systems

With either framework, all control goes through the ODB. Don't use it for systems that need to be safe if the ODB or the frontend fails (e.g. interlocks): use hardware interlocks for those.

Class driver framework

The class driver framework has up to three layers of drivers:

a class driver connects the equipment to the ODB, and has the high-level features for a kind of equipment (e.g. limits and ramping for high voltage). It doesn't know about the hardware
a device driver talks to one kind of hardware, with simple commands such as "set the voltage of channel 3" or "read channel 3"
a bus driver (optional) handles the communication, e.g. over RS-232 or TCP/IP, so that a device driver can be used with different connections

An equipment uses one class driver, which can use several device drivers. For example, one high voltage equipment can control supplies from two different makers, with their channels shown as one list.

The class driver keeps the values in the equipment's ODB directory:

the values you want to set (e.g. voltages) are in Variables/Demand. When you change a value, for example on the equipment page, the frontend is notified and sets the new value in the hardware
the values read back are in Variables/Measured. The frontend reads all the channels continuously, and writes a value to the ODB when it has changed by more than a threshold
the settings of the class driver (e.g. channel names and voltage limits) and of each device (e.g. a serial port) are in Settings

The frontend also sends the values as periodic events, so they are written to the data files, and recorded in the history.

The built-in class drivers are:

Class driver	Used for
`generic`	Any channels with a set value (`Demand`) and a read-back value (`Measured`)
`hv`	High voltage supplies. Adds the read-back current, voltage and current limits, and ramping
`multi`	Separate input and output channels (`Input` and `Output`), e.g. temperature sensors and valves. Adds factors, offsets and formulas to convert the values

There are also special-purpose class drivers for particular hardware (cd_rf, cd_fgd and cd_ivc32). Midas includes device drivers for many common devices, for example high voltage supplies from CAEN, iseg, Wiener and LeCroy, MSCB devices and EPICS channels.

For the settings of the class driver framework, see Slow control: configuring.

For writing frontends and drivers, and the full list of drivers, see Slow control: programming.

mdev framework

In the mdev framework, each device is a C++ object of an mdev driver class (e.g. mdev_mscb for MSCB devices). The frontend code creates the objects, and says which channels of the device to use, with their names and units.

Each mdev driver keeps its values and settings in the equipment's ODB directory, in its own layout:

the values of all the channels are in one array in Variables, e.g. Variables/MSCB for mdev_mscb. The frontend reads the device continuously, and writes the values there
when you change the value of an output channel, for example on the equipment page, the frontend is notified and sets the new value in the hardware
the names, units and formats of the channels, and which ones can be edited, are in Settings. They are written from the frontend code each time the frontend starts

The frontend also sends the values as periodic events, so they are written to the data files, and recorded in the history.

The mdev drivers in midas are mdev_mscb (MSCB devices), mdev_revpi (Revolution Pi) and mdev_tdk (TDK power supplies).

For the settings of the mdev framework, see Slow control: configuring.

For writing mdev frontends, see Slow control: programming.

Using slow control equipment (both frameworks)

With either framework, slow control equipment is used in the same way as other equipment:

the equipment page (click the equipment name on the Status page) shows the values, and lets you change the editable ones
the history records the values, and shows them on the History page
the values and settings can also be changed directly in the ODB, or by scripts and the sequencer