Operating the DAQ

This page will give a description of how to run the two test beam DAQs in order to take data.

Beamline DAQ

Setting up

The beamline DAQ is run from the

machine. Log in as user novadaq (must be on k5login). When logging in, all the required software is set up by default.

When operating the DAQ, do so on the VNC sessions, so we only have one place we are running things from. Right now this is set up as screen 2.

Before taking a run, it must be configured. This typically involves defining which components will be included in the run and setting the trigger conditions.

Selecting DAQ components

The available components are:
  • trigger board
  • digitizer
  • mwpcs
  • crate controller (not readout)
  • tdu

The configurations for the first four are located at


and are named V1495.config (trigger board), V1742.config (digitizer), V2718.config (crate controller) and TDC.config (MWPCs). The first line of each is named

Set this to 1 to enable readout of this components and 0 to disable.

All other parameters in these files should be set to their optimal values and changed only by experts.

The TDU is different since it uses its own board reader. The board readers included in the run are set in


There are three lines; one for lariat board reader only (all components except TDU), one for TDU only and one for both. Comment or uncomment lines to change which board readers are run.

Setting the trigger condition

The trigger conditions are set in the trigger board configuration file,


There are 16 trigger patterns available to set. The final trigger is a global OR of all these patterns (so if any of the conditions are met, the trigger board will fire). They are named

in the file. Typically we would just use one, but there are cases when using multiple to set multiple conditions is required.

The trigger patterns look something like

    <off> DIGBUSY </off>

Only change the bottom three parameters. And, more than likely, you won't want to prescale, so you will only want to change the 'ON' and 'OFF' conditions. The on and off define which variables are required to be on or off in order to satisfy the full trigger condition. Listing multiple here requires all to be on or off (i.e. there is an implicit AND). In this case, the trigger board is set to run in firmware pulsing mode and it requires both MWPCOFF and SWYDGATE to be ON and DIGBUSY to be off in order to make a trigger.

All patterns which aren't being used should have


NOTE when taking beam, please keep the MWPCOFF and SWYDGATE variables in the ON conditions and DIGBUSY in off. This doesn't affect the triggering but ensures the board only makes triggers when the beam in present and the MWPC controller is collecting data (this uses its own gate). This is important when matching up data offline between all the systems.
  • MWPCOFF -- is true with the MWPC controller is ready to accept a trigger. Is false when is still dealing with the previous trigger (we enforce a large latency to keep the controller in a responsive state)
  • SWYDGATE -- is true during our beam spill from switchyard. Same gate as used by the MWPC controller, so in order to ensure we have MWPC data in the same window as other data, we only make triggers during this gate
  • DIGBUSY -- is true when the digitizer is still busy digitizing the last event. False when ready to accept a new trigger. We enforce this to ensure we always get digitizer data whenever there is a trigger

How to check DAQ and trigger configuration

You can use script in scripts directory on novabeamlinedaq00 machine to retrieve current DAQ and trigger configuration.

Defining the DAQ spill

The final thing which may be changed is defining when DAQ starts and stops spills. There are two ways to do this: using an external clock or using the gate given to the MWPC controller. In general, and certainly when taking beam data, we want to set up the former. The latter is useful when doing studies of just the MWPCs and is often used for this purpose.

To switch between them, we use the crate controller. The parameter


in the crate controller configuration file

is relevant: set to 1 to use the external clock and turn off (set to 0) when wanting to use the MWPC controller gate.
So in general, this should be turned on.

If we are not using the MWPC gate for the DAQ spill, we probably want to be using the external gate to collect MWPC data (not the internally generated one). In which case, ensure


is disabled in the MWPC config file,

Running the DAQ

When the run is configured correctly, run the DAQ by simply executing


in the terminal. No fancy GUIs, here.

Although there is a nice messageViewer which handles all the messages sent from the various parts of the DAQ system. Very useful for debugging and understanding the run but it takes a while to get used to the output!

When starting a run, put a note in the ECL. Note the components in the run and the trigger conditions used. In the comments include the run numbers which were collected with this configuration and any other comments which may be useful. For example, see

The forms 'Beamline Start Run' and 'Beamline End Run' should be used when shifting to record the beamline runs.

Stopping runs (and crashes)

When the DAQ starts successfully, it takes a couple of minutes to set things up and then starts collecting data. The terminal from which you execute 'go' will eventually say

Will acquire data until Ctrl-C in hit

If this doesn't happen, likely the DAQ crashed during initialization. If there is an obvious problem this should be addressed; if not, try again! Often it works second time. If it's still not working, call an expert (or, if you are an expert, figure it out).

Once data acquisition starts, messages will constantly roll on the messageViewer and the terminal will remain at this message. Obviously, to stop the run, hit Ctrl-C. DO IT ONCE. It will stop, it just takes a few minutes. And we want to make sure we get the data!

If the DAQ crashes, it'll be obvious by looking at this terminal and seeing messages other than this.

Running the DQM

To run the DQM, log into the novabeamlinedaq00 machine in a different terminal and execute


NOTE the DAQ must already be running in order for this to work. The online monitoring will then start and run as a DAQ process (you can see messages by filtering on 'Dispatcher' in the normal DAQ message viewer). Images will be synced to the web