Copied from Controls Software Operations Group's page by Tasha Summers and Jeremy Mock & Kyle Lelux's Epics Training Program
Accelerator Equipment ↔ Control System ↔ People
The control system is (mostly) a set of software tools and applications that the accelerator operators, physicists, and engineers interact with to understand and control the state of the thousands of pieces of equipment that make up the Linear Accelerator complex.
A lot of accelerator equipment is connected to controllers (e.g. PLCs) that do low-level work like reading in voltages, controlling current, interpreting timing signals, opening and closing valves, and more. A highly specialized software program is needed to translate those signals and states into meaningful and rich data that can be used by operator interfaces and applications. For this we use EPICS (Experimental Physics and Industrial Control Systems). EPICS is a distributed control system toolkit, actively maintained and managed by an diverse group of international collaborators. It started in the 1989 as a joint project between two DOE labs - LANL (Los Alamos) and ANL (Argonne) - as part of the Star Wars program (more history here!). It went open-source in 2004 and is now one of the most widely used control system by particle accelerators and scientific facilities across the world.
The main EPICS software application is called an IOC (Input Output Controller). An IOC has 3 main functions:
A good-sized accelerator facility will have many hundreds of IOCs deployed. Some IOCs run on small computers in hardware racks, and run on real-time operating systems. Others (most actually) are simple software processes that can run on any Linux computer. Here at SLAC, these simple software IOCs (softiocs) run on one of a couple dedicated Linux servers.
At SLAC, we develop our IOCs on the Development network (e.g. lcls-dev3), sometimes against a test stand or a software simulation. How the work is done depends on whether we are changing an existing IOC application, or creating a new one. The folder containing the IOC application files is version controlled with Git. When ready to deploy to the Production network, the Git repo is tagged with a release number and copied over to a production server and booted up using specialized commands. Deploying new software like this is highly controlled and generally only scheduled on accelerator maintenance days. The recipes for updating existing applications and for deploying new ones are beyond the scope of this introduction.
In this section we'll explore some of the most commonly used PV types and their attributes. In the end you will have a small database of unique records you can run and use for learning about the operator interface applications in the next section.
A Record is a software object with a unique name, e.g. MY_RECORD:SETPOINT, controllable fields, and a behavior or action.
A PV has two parts: the record name and a field, e.g. '.VAL', '.DESC', or '.SEVR' which are common to all records. To retrieve the information in the .DESC field we would use the PV name MY_RECORD:SETPOINT.DESC. Note that 'VAL' is the default field and can be left off, so these are equivalent: MY_RECORD:SETPOINT=MY_RECORD:SETPOINT.VAL.
There are different record types that can be used depending on the type of data they are handling. In the example to follow we will be looking at these common record types and their frequently configured fields:
Controls engineers rely on the EPICS Record Reference for information about the different record types and their fields. This reference site also has a good Introduction to EPICS and Process Database Concepts.
Each record starts by declaring a unique name and the type. At SLAC the names are created following an official naming convention in a standardized all-caps format: DEVICE_TYPE:AREA:POSITION:(INSTANCE):SIGNAL_ATTRIBUTES. This makes the names look complicated but they contain a lot of information! For example, QUAD:LI22:401:IACT is a quadrupole magnet in sector LI22 at position 401, and the attribute is IACT (actual current readback).
EPICS Channel Access makes every PV available on the network so any client or person logged on can access them. For this reason it's important not to have duplicate PV names out there because you will randomly connect to either one and this can cause obvious issues. For this introduction we'll stick to simplified record names, E.g. MYNAME:SETPOINT using your own username to ensure they are unique on the network.
Following the name and type are a list of fields. Usually a record type will have many more fields than we care to define so if we don't specify it they fall back to a default (defined in the Record Reference).
There are several fields that are common to all records such as:
Example record types and common field definitions:
record(ai, "MYNAME:READBACK"){ | record(ao, "MYNAME:SETPOINT"){ | record(calc, "MYNAME:SCALED"){ |
| INP: input (other PV, PLC address) SCAN: how often to process note we don't need to put a 'CP' after this address to trigger processing since it already will process at 1 Hz PREC: precision (# decimal places) HIHI,HIGH,LOW,LOLO: alarm levels HHSV,HSV,LSV,LLSV: alarm severities | OUT: output (other PV, PLC address) | INPA-INPL: multiple input addresses |
record(bi, "MYNAME:STATUS"){ | record(bo, "MYNAME:COMMAND"){ | record(stringin, "MYNAME:MESSAGE"){ |
| INP: input (other PV, PLC address) ZNAM,ONAM: 0,1 value labels ZSV,OSV: 0,1 alarm severities | OUT: output (other PV, PLC address) | VAL: An initial message - notes that we |
Some reference material useful for the entire problem:
