Digitizer IOCs

Digitizer IOCs

The IOC, or Input/Output Controller of a VME crate is an MVME5500E embedded processor module. The processors use the vxWorks operating system. VxWorks is capable of supporting multiple concurrent threads. The major thread types used in the Digital Gammasphere setup are shown in the white boxes within the picture of the IOC.

Threads inside a digitizer IOC

EPICS

EPICS, or the Experimental Physics and Industrial Control System, is the main thread that runs on the IOCs. EPICS implements a distributed database architecture in which a large number of Process Variables (PVs) are distributed across multiple processors. In Digital Gammasphere the mesh of processors consists of

• Eleven MVME5500s that each manage one VME backplane with four digitizer modules (VME01, VME02, ..., VME11)
• One MVME5500 that manages the VME backplane where the trigger modules are plugged in (VME32)
• The Linux computer DGS1, that is hosting two different processing threads related to EPICS:
  • The "Soft IOC" program that acts like all the other IOCs, participating in the shared database; and
  • The "DGSCommander" GUI that links GUI controls (buttons, indicators, drop-downs, graphs, etc.) to PVs in the distributed database.

When any of the VME-based IOC processors is rebooted, the boot script automatically initiates the EPICS thread and connects the processor to the portion of the database that is specific to that processor. The overall purpose of EPICS as implemented is to monitor whenever any PV value is changed (by the GUI or execution of a shell script) and to then report that to the entire database. Within each IOC, the EPICS thread there listens to those global reports. When a PV is changed, the specific IOC that has responsibility to react to a given PV (because that PV is in that IOCs part of the database) is then supposed to "do something" when the PV changes.

IOC response to a PV being changed

Exactly what the "do something" means is NOT part of EPICS. EPICS does not actually do any VME transactions. In any of the VME processors the EPICS thread sets a flag or updates a variable in response to a PV changing, but any action that is supposed to occur in response to a change in a PV is the responsibilty of a different thread. That thread is called the Control thread and is discussed below.

Within Digital Gammasphere, the process variables associated with a given VME crate are broken into three groups.

1. Module-specific PVs have names of the form VMExx:<boardtype>xx:<name>. There are two sub-types of a module-specific PV.
   1. There are whole register PVs that are formatted like VME02:MDIG2:reg_LED_threshold5. As the name implies, changing the value of this PV will perform a simple write transaction, writing a single value to a single register in one board of one crate. The transaction overwrites the whole register.
   2. There are many registers in the firmware that contain multiple sub-fields (individual bits or a value that spans some few bits). In these cases, when the user changes the PV associated with that field, on the VME side the IOC has to do a read-modify-write transaction that changes just those bits while leaving the other bits of the register untouched.
2. Crate-specific PVs have names of the form VMExx:CV These PVs are associated with control of the threads within the IOC processor and have no connection to any digitizer or trigger module.

How do I know what PVs are hosted by any given processor?

At the terminal window of any IOC you can type the command dbgrep followed by a search string (Linux regular expression) to list all PVs matching the search string. The search string should be enclosed in quotes.

vxWorks does not understand the Backspace key and thinks it is some weird character. It also doesn't understand the arrows or the delete key. In the vxWorks terminal window you use the key combination Ctrl-H as the backspace if you make a typing error.

There are many similar commands that can be typed in at the vxWorks prompt (or put into the startup script). The full list is found here. Besides dbgrep, the other two that should be noted are

• dbpf allows you to "put" a value to a PV. This is a manual way to change a PV. The identical functionality is also available at any Linux terminal window, but with a little different format. In Linux, the "put" function is done by typing caput <PV_name> <new value>.
• dbgf allows you to "get" the value of a PV. This polls the value of the PV in the database and prints it to the screen. The identical functionality is also available at any Linux terminal window, but with a little different format. In Linux, the "put" function is done by typing caget <PV_name>.

How IOCs change PVs

EPICS does not automatically update PVs. EPICS is just a processor-to-processor communication mechanism. There has to be a separate thread to collect system information and provide updates to the user through the GUI. We call this thread the Monitor thread, and it is discussed in detail below.

In the database, there is a completely separate set of EPICS process variables for displaying monitoring information to the user. Every register-level object in the firmware of each digitizer or trigger has a control PV and a matching readback PV. That is, the VME05:MDIG2:reg_CFD_fraction3 is the control PV, and it has a matching VME05:MDIG2:reg_CFD_fraction3_RBV readback PV. The "_RBV" stands for Read Back Value.

Why the duplication? The control PV allows the user to change the value in the register. The readback PV shows the user what is in the register. If you have a status register in the firmware - like a diagnostic counter or something that provides status bits about the hardware - this would be implemented as a read-only object. The user will want to see those values and changes in them, so the IOC must have a thread to poll them every so often so the user can see what's going on. For a normal read-write register in the firmware, monitoring the _RBV process variable provides confirmation that when the control PV was changed, the desired modification of the firmware register actually occurred.

The Control thread

The Control thread is the program within the IOC that actually "does something" in response to a notification from EPICS that a PV has changed. The Control thread simply translates changes in PVs to write transactions over VME. The Control thread is actually multiple threads, one per VME slot in the crate. Each of the Control threads has a list of 'parameters' associated with a subset of