DAQ applications (still to be reviewed)


The process collecting data and sending it to the EVB. Each one of the SEBs is running one instance.
Multi-threaded handling, so we have different threads that handle NU and SN streams (and trigger stream on SEB10)
sebApps have configurable rawFragmentProducerConsumer pairs


collects data from a source (like “DMA” buffer memory from PCIe card, or random data for test modes)
One thread continuously moves that data from source to a large “circular buffer”: fillCircularBuffer
One thread continuously pulls data from circular buffer and tries to make fragment corresponding to one “event”: readFragment
Completed fragments are put in a queue, to be handled by consumer


collects fragments from Queue, and sends them to their “sink” (like event builder via a TCP connection, or to a local file)


The process collecting data from the SEBs and writing it to disk on EVB
There one instance which runs on the EVB
Can connect to configurable number of SEBs, Though only typically do this for ”PMT-only” runs
It applies software trigger after event is built
Can attach descriptive data and other info to the event (“global” header)
Sends data to OM for processing too
Fragments are collected and stored in “EventStore”

  • Each fragment as a fragment ID (usually which SEB it comes from) and a
    sequence ID (the event number)
    1. EventStore is a map, keyed on sequence ID, with elements that are vectors of collected fragments
    2. When all fragments for a sequence ID are in EventStore, event can be written to disk
    3. Fragment collection transferred to queue to be handled by EventBuilder
  • fragments added to the event record
    1. “ProcessAndShip” takes event record, fills in global headers and other info,
      and then event is written to disk
    2. Writes “subrun” info as well if max events per file has been reached

The state machine

Both sebApp and AssemblerApp follow the strict state machine:

DDS messages passing for communication on each stage of this chart flow.
The "checkstatus” commands can determine
  • What machines are up and running applications (and responding)
  • Status of each application

Typically, after every run we bring down the applications completely, and reconfigure before starting a new run.
The RunConsoleDAQ is a simple run control that chains together a lot of individual scripts to automate running for shifters.