``Slow-Control'' is a generic word to qualify every control (for the detector and beam line) that are not part of the acquisition itself. It deserves this qualification because the flow of data needed for slow controls (some kHz) is far smaller than the acquisition data rate (some MHz).
For the detector itself, Slow Controls consist of monitoring and driving the thousands of power supplies needed for all the individual detectors, from individual PM to large drift chambers. It can be high voltage (some kV), but usually these devices have a very low power consumption, but the accuracy of the control of those parameters has a direct impact on the detector resolution.
For the beam line, the Slow-Controls are essentially here to provide a monitoring of the beam quality, position, energy, polarization, etc. It has of course also a great impact on the resolution of the final reconstruction of events, giving total energy, vertex position indications and so on. But in this area, the driving power can be far higher (Mega Watts) and thus requires special attention to reliability, security and safety of the software and hardware.
As the EPICS system has been widely explained in previous thesis by Marc Winoc Swynghedauw [17], Thierry Auger [7] and Sebastien Fabbro, [10], I won't do much more than a quick review about the basics and then introduce some more specific informations about the use of EPICS on the beam line devices that were implemented.
EPICS provides an interfaces for instrumentation and supervisory control, it uses a client-server protocol to establish a communication between the controller software that runs on a dedicated computer, and the client, usually an interactive graphic user interface (GUI).
A common and coherent architecture helps the designer of a control system, starting from the device drivers to the graphic interface using standardized interfaces between layers that allow a great recyclability of written code. Elements of codes written with EPICS (drivers, databases, GUIs...) are very modular and can easily be reused in another application.
The different layers of EPICS are schematized in Figure 3.1.
The EPICS control program itself runs on dedicated CPU (IOC for Input Output Controller). In Hall B it is a Motorola Board equipped with a 68k or PowerPC processor and some RAM. 5
These boards are housed in VME crates located in the Hall itself and act as Master of the VME bus. Then dedicated VME slave cards, interfaced with the hardware we want to monitor and control, can be managed by the IOC. It can also use it's serial link to talk with some application devices.
The IOC is also connected to the LAN (Local Area Network) under TCP/IP with whatever twisted pair or coaxial cable available. Having no internal disk drive, it has to boot from the network, and then an operator using any station on the network can open it's shell using a telnet or rlogin protocol.
In the Hall B, to avoid bandwidth problems the Slow Control system has it's own subnet and is connected to only one UNIX station (clas10, an old HP 735/125), then the subnet is outside of the main lab communication network. As things are never that simple, we have had to open some gateway on clas10, to allow the Accelerator Division to request data from our own IOCs. But basically, this network insulation requires that the EPICS clients will have to run on clas10.
The IOCs are using a real time UNIX-like Operating System called VxWorks 6 made by Wind River Systems [5]. This environment is not suitable for application development, and everything is cross-compiled on a workstation7 before being down-loaded into the IOC.
To create the VxWorks executable applications, tools like db2database
to compile databases that will be loaded into the IOC and, C cross-compiler
with the EPICS pre-processor to compile the SNL (State Notation Language)
programs, will be used. Some debugging tools provided by the VxWorks
Operating System can be useful sometimes too.
When running, the IOCs are loaded with the EPICS core and the user databases and program executables. The UNIX stations run EPICS clients, usually a GUI (Graphical User Interface) developed under medm (a tool provided in the EPICS distribution) or in various languages (mostly tcl/tk and C). The client request and provide informations to the EPICS applications that are running in the IOCs by the channel access protocol.
