Project

General

Profile

Combining the components into a working DAQ system

After getting an overview of artdaq-demo in A description of the demo system, learning to run it in Running a sample artdaq-demo system, and learning how to interface an artdaq-based DAQ system to an experiment's hardware and data layout via Fragments and FragmentGenerators w/ Toy Fragments as examples, the next step is to learn how to control both artdaq and experiment-specific components in a way to produce a working DAQ system. This is already done in the DemoControl.rb script called in the example DAQ provided, but of course an experiment will want to know how to include their own fragment generators to provide the DAQ with data and their own ART modules to process the events when assembled. While a study of DemoControl.rb can indicate how this is done, in these instructions we'll begin from the ground up to better understand the principles off of which DemoControl.rb operates.

The "driver" executable

The standard artdaq-demo DAQ model, described in the instructions for running, consists of separate artdaq processes communicating with one another: two BoardReaderMains to create the event fragments, two EventBuilderMains to receive the fragments from the BoardReaderMains and assemble them into complete events, and two AggregatorMains, one which writes the events to *.root files on disk, the other to run an ART module which provides an online monitoring display. The transitions issued in this DAQ, passed as arguments to the manage2x2x2System.sh script, are in turn passed as arguments to the DemoControl.rb script, which will send them via the XML-RPC protocol to the running processes. While it is a good idea to thoroughly understand the behavior of DemoControl.rb before either modifying it for a specific experiment's needs or writing a DAQ control script from scratch, beginning with DemoControl.rb is a "diving off the deep end" approach. In particular, to understand DemoControl.rb, one must first understand the FHiCL scripts which it sends to the processes to initialize them. One way to do this is to experiment with the driver executable, which is far simpler than the standard artdaq-demo DAQ in that instead of multiple artdaq processes communicating with one another this is a standalone executable which both generates simulated data fragments (the job of the BoardReaderMain process) and then passes them directly to an instance of the artdaq::EventStore class (found in the EventBuilderMain process in the standard artdaq-demo example). To run it, in the bash shell, after cd'ing to the artdaq-demo base directory and sourcing the "setupARTDAQDEMO" script, one can simply run the following command:

driver -c driver.fcl

What this command will do is pass a FHiCL script called driver.fcl, located in the artdaq-demo/tools/fcl directory, to the executable. The file will look something like this:


events_to_generate: 1
run_number: 101

fragment_receiver: {

   # Parameters defining and configuring the fragment generator to be used

   generator: ToySimulator
   fragment_type: TOY2        # Make sure downstream modules know about this fragment_type!
   fragments_per_board: 1
   nADCcounts: 100
   random_seed: 6514

   # Parameters configuring the fragment generator's parent class
   # artdaq::CommandableFragmentGenerator

   fragment_id: 0
   board_id: 0
}

event_builder: {

  expected_fragments_per_event: 1
  use_art: true
  print_event_store_stats: false
  verbose: false
  events_expected_in_SimpleQueueReader: @local::events_to_generate
}

######################################################################
# The ART code
######################################################################

physics:
{
  analyzers:
  {
    toyDump:
    {
      module_type: ToyDump
      raw_data_label: daq
      frag_type: @local::fragment_receiver.fragment_type
      num_adcs_to_show: 10   # Obviously this should be no more than ADC counts per fragment
    }
  }

  a1: [ toyDump ]
#  e1: [ out1 ]
  end_paths: [ a1 ]
}

outputs:
{
  out1:
  {
    module_type: FileDumperOutput
    wantProductFriendlyClassName: true
  }
}

source:
{
module_type: RawInput
waiting_time: 900
resume_after_timeout: true
fragment_type_map: [[3, "V1720"], [4, "V1724"], [6, "TOY1"], [7, "TOY2"] ]
}

process_name: Driver

This script, written in Fermilab's homegrown FHiCL language, does the following things:

  • It tells driver how many events to simulate, and what run number to use in the simulation
  • It uses the "fragment_receiver" table to configure an instance of a class derived from artdaq::CommandableFragmentGenerator (in this case, the demo::ToySimulator class)
  • It uses the "event_builder" table to configure an instance of the artdaq::EventStore object, used for processing the events
  • It tells driver to pass completed events through the ART module "ToyDump"

As the ART code is relatively complex, to better understand it, you can read about ART at the official wiki here or take a look at the excellent overview produced by the mu2e experiment here ; the latter also provides a nice overview of FHiCL.

Running the driver executable will provide some basic diagnostic info concerning each of the events processed, including generic artdaq::Fragment info (the sequence ID, the fragment ID, and the size of the fragment in bytes), implemented by the driver's source code, and toy fragment specific info, provided by the ToyDump module referred to in the FHiCL script. The user is encouraged to play with the parameters in the FHiCL script, in particular the "fragment_type" parameter (can be "TOY1" or "TOY2") and the "nADCcounts" parameter used to configure the ToySimulator, and the "use_art" boolean parameter used in the event_builder table, re-running driver with the script (i.e., "driver -c <scriptname>" after each modification.

DemoControl.rb: a full DAQ control script

As mentioned above, DemoControl.rb is the script which controls the full example DAQ provided by artdaq-demo. As is the case with RunDriver.rb, it contains a good deal of documentation within its comments. As is also the case with RunDriver.rb, it can configure an object of the demo::ToySimulator class via FHiCL code generated through the generateToy function, defined in generateToy.rb; however it also utilizes functions designed to generate FHiCL code usable by the artdaq processes BoardReaderMain (generateBoardReaderMain), EventBuilderMain (generateEventBuilderMain) and AggregatorMain (generateAggregatorMain).