Digitizer IOCs: Difference between revisions

From GammaSphere DAQ
Jump to navigation Jump to search
Line 14: Line 14:
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.
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 ====
''==== 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.
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.


Line 24: Line 24:
#  
#  


==== How do I know what PVs are hosted by any given processor? ====
''==== 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.
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.



Revision as of 16:13, April 20, 2019

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.

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

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

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

The Monitor thread