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.
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.
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.
Within Digital Gammasphere, the process variables associated with a given VME crate are broken into three groups.
- Module-specific PVs have names of the form VMExx:<boardtype>xx:<name>. There are two sub-types of a module-specific PV.
- 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.
- 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.
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