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:

  1. The only way to work with the thingamajig is to be physically at the computer.
  2. 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 the LAN.

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.

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).