EPICS for the Bewildered
So you've been asked to get EPICS up and running or---worse, yet---you've
inherited a project which involves EPICS and have to maintain/update/guard it.
Well, this page is going to hold all the stuff I know about EPICS. Maybe it
will help. If it does, and you have any additions/modifications to make,
feel free to shoot an email my way.
The Bird's Eye View
I'm a "big picture" kinda guy. Before we get into the details, let's see
what the whole point is.
In the beginning there was a computer. The computer was connected to
something (via the internal bus, SCSI bus, serial port, etc...) and that
something either performed some data acquisition, controlled a thingamajig
(technical term), or, possibly, both.
This gets the job done, but there are two problems inherent in this scheme:
- The only way to work with the thingamajig is to be physically at the
- If you had another (different) thingamajig to work with, you had to use
a completely different bit of code to play with it.
EPICS is Distributed
Once someone mentioned the word "networking," everyone and their other brother
Daryl wanted to do it. This meant that some workaholic wanted to be able to
play with the thingamajig from his office in the next building.
EPICS defines a scheme where any computer connected to the LAN over TCP/IP
can request or send information to the computer directly in control of the
thingamajig. We're assuming that the control computer is also attatched to
In addition, EPICS allows multiple IOCs on the network. Therefore
not only can the workaholic control thingamajig A in your lab connected to
your IOC with his computer (OPI), but he can control thingamajig B in another
lab on another IOC as long as that IOC is on the same LAN.
- Operator Interface (OPI) = computer used to send or receive
information across the LAN.
- Input/Output Controller (IOC) = computer connected directly to
EPICS Provides a Uniform Interface
Controlling a lamp (ON/OFF) and a motor (lots of variables for acceleration,
speed, direction, distance, etc.) is not a simple task. The lamp has a
controller requiring certain commands and the motor has a different one
requiring different commands.
EPICS provides a uniform interface where you can say "set lamp on" and
"set motor:direction negative"
Granted, there are different device drivers necessary so that EPICS can
correctly translate your commands to each thingamajig, but the user interface
does not look any different.
The way EPICS smooths out all the differences is by assigning database records
to every device. For the lamp, the database record is simple, you have a
record called "LAMP" and it has a field, "VAL". If you set LAMP.VAL to 1, you
turn the lamp on. Set it to zero, and the lamp should turn off.
For a motor, you have many more fields: Limit switch status, movement
status, direction status, velocity settings, etc. But you would read the
Process Variable (PV) "MOTOR.HLS" to find out if the High Limit Switch
was tripped. You could set the PV "MOTOR.VAL" to 28.645 to tell the controller
to send the motor to that position.
Just remember, everything to the left of the "." is the record name,
everything to the right is the field. We have funny record naming
conventions (e.g. 18ID:XY:Xw:ActPos) but that WHOLE string is the record name.
The field of interest would be 18ID:XY:Xw:ActPos.VAL which would contain the
actual position of the X-axis of the wedge XY-positioner on our beamline, 18ID.
For a heirarchacal view of EPICS, you might want to peruse this
1998 PDF overview written by Stephen Lewis of LBL
NEXT-> (Installing EPICS on a Linux client).