Creating a Readout that is managed by the experiment manager is by hand is laborious. In addition to starting the Readout itself at experiment boot time you must:
Us an init script that loads the REST control interface into the Readout.
Arrange for ancillary REST client control programs to run at appropriate state transitions.
The mg_readout_wizard command allows you to specify the characterisitcs of a Readout program and then takes care of all of creating the programs and sequence entries needed to properly define the Readout to the experiment manager.
The manager supports three types of readout:
This is the split XIA Readout/hit sorting readout system that was introduced in NSCLDAQ-11.4 and is in NSCLDAQ-12.0 and later.
This is a readout program for either the VMUSB or CCUSB smart crate controllers.
This is any readout program that can can load the tclhttpd to supply the REST interface and accepts the REST interface's commands.
This is intended to supply legacy support for the SBS readout framework but also can work withthe readouts for the CAEN digitizers.
The readout wizard GUI is divided into three visible panes:
The top pane prompts for information that is common to all readout types.
The contents of this pane vary dependingon the type of readout program selected (from the common pane). It prompts for information needed by the specific readout program type you are using.
Provides the buttons needed to decide what to do with the information in the form. The button accepts the information, validates it and makes the database entries needed to define the program. unpost the GUI and makes no database changes.
The subsections of this section will describe the information different parts of the form can accept as input. First we will describe the common pane's inputs. Then we will describe each of the possible type specific panes and when they will appear.
The common pane provides the following inputs:
This is a name which will be used to derive the names of the program that will be created by the wizard. Program names will be created by appending an underscore and a functional description.
The following programs are created for a readout named xxx, and hopefully their names are self descriptive: xxx_readout, xxx_init, xxx_setrun, xxx_settitle, xxx_beginrun, xxx_endrun, xxx_shutdown. Where xxx_readout is the readout program itself and the other programs are REST control clients.
This is a radiobutton set that selects the readout program type. Selecting a radio button selects the contents of the type specific pane. Selecting XIA selects the XIA/DDAS readout/sort program, both VMUSB and CCUSB select the XXUSB pane and use the appropriate readout program (VMUSBReadout or CCUSBReadout, respectively), and Custom selects the custom readout pane.
The container part of the form allows you to select the container within which the programs are run and the host in which the programs are run. Not that to simplify, all programs created by the wizard will be run in the same container and same host. If the container pulldown is left empty, the programs are run in the native environment.
Sets the current working directory for all of the programs. Note that if the programs are run in the containerized environment, this path must be valid within that environment.
Selects the source Id that will tag the events produced by the readout. The source id of each data source must be unique for the event builder to function properly.
Name of the ring buffer that will receive events from the readout.
Provides the name of the REST service you want the readout to advertise (and the clients to interact with), as well as the username under which the manager is run. In NSCLDAQ, service names are qualified by the user registering them and in the experiment manager, all programs are run under the username of the user sthat started the manager.
This pane is visibible if the Common pane's XIA radio button is checked. It prompts for the additional parameters needed to set up the XIA readout/hit sort pipeline. It's important to note that the output ring and host in the common pane will be where the readout program itself will run and put data.
The system in which the hit sorting program will run. Note that the common pane's container selection will determine if the program runs in a containerized environment and which container will be used if so.
Determines the name of the ring buffer in which they hit sorter will write the sorted hits.
Determines the number of seconds in the sliding window within which hits can be emitted.
The number of words that must be in the FIFO of modules in order to trigger a readout.
The size of the ring item the readout will use to send hit aggregates o the sorter.
If Infinity is checked the readout will use infinity clock synchronization. That is clocks will be synchronized at boot but never again.
If external clocks are selected in the readout, the values of the external clock are multiplied by the Multiplier to form the event timestamp.
Specifies the number of seconds between scaler readouts. This should not be smaller than 2 as we've observed issues with the modules if it is.
This pane is visible if either the VMUSB or CCUSB radio buttons are checked in the common pane's readout type radio button set. It prompts for parameters needed by the XXUSBReadout programs.
If the By serial checkbutton is checked, the Serial String entry is enabled and you can type the serial string of the controller you want to use. Note that if only a single VMUSB or CCUSB controller is attached to the system the readouts will connect to it.
Provides for the daqconfig file, which defines the modules, their parameterization and the stacks to configure for acquisition mode.
If the Extract Timestamps checkbutton is checked, it's assumed you're using the readout in an event built environment and the entry to right allows you to supply a timestamp extraction shared object library file that can assign a timestamp to each event. Note that the paths for the daqconfig and timestamp extraction library must be valid within whatever container you might have selected for the readout program.
If the Use Control Server checkbutton is checked the XXUSBReadout's slow control server is enabled. You can then enter the control configuration file and the port on which the control server listens for connections.
Note that the path to the slow control configuraion file must be valid within whatever container environment you've selected for the program.
If the Enable checkbutton is selected, the debug logging and tracing are enabled. In that case, you must supply a log file and the verbosity level for the logging.
In general this tab configures versions of the SBS readout framework used either in legacy systems or with electronics that is not in general use at the FRIB (such as CAEN digitizers and nextgen CAEN digitizers) that have readout systems based on that framework.
The form for specifying the custom readout program allows you to specify:
The path to the program that will perform the readout (this path must be valid in whatever container environment you might have selected).
These are option/value pairs which are passed to the program on the command line, prior to any parameters.
These are an ordered list of parameters that are passed on the command line after the options.
These are environment variable name/value pairs that are defined prior to running the program.
Note that the common pane will also add several options to the program. The program must be able to accept them and must be able to correctly interpret them:
--sourceidSets the source id that events should be tagged with.
--ringSpecifies the ring buffer into which data will be written.
This will have a value that specifies the initialization script that starts the REST server that allows the Readout to be remote-controlled.
Note that if the readout program you have does not meet the requirements of a custom program, you can always manually define the program and what's needed to control it.
The readout wizard creates several database objects for readout programs it defines. It creates programs, if necessary, sequences and populates those sequences with programs needed to orchestrate the readout.
The following program definitions are created (xxx is the program name in the common panel):
The actual readout program itself.
Requests a hardware initialization from the Readout.
Reads the run number from the database KV store and asks the Readout program to set its run number to match.
Readss the run title from the database KV store and asks the readout program to set its title to match.
Asks the readout program to start data taking.
Asks the readout program to end data taking.
Asks the readout program to exit.
The following sequences are created and maintained:
Triggered by the BOOT transition. This will have xxx_readout appended to it.
Triggered by the HWINIT transition. This will have xxx_init appended to it.
Triggered by the BEGIN transition. In order, xxx_setrun, xxx_settitle and xxx_beginrun are appended to this sequence.
Triggered by the END transition. xxx_endrun is appended to this sequence.
Triggered by the SHUTDOWN transition. xxx_shutdown is appended to this sequence.