Project

General

Profile

New "example systems" are contained in the daqInterface repository

See https://cdcvs.fnal.gov/redmine/projects/artdaq-utilities/repository/daqinterface/revisions/develop/show/simple_test_config
Some of these configurations are used in artdaq release testing
At the top of this Artdaq_Release_testing_documentation_and_results section are example run_demo.sh command lines.

Running a sample artdaq-demo system

Prerequisite

These steps assume that you have already installed and built the necessary packages using the steps listed on the Installing and building the demo page.

Running a sample system

The standard method of running an artdaq-based system for experiments is to use a program called DAQInterface; for actual experiments using an artdaq-based system specific to their hardware and analysis needs rather than artdaq-demo, a bit of configuration is needed, as described on the DAQInterface wiki. However, the good news is that when you installed artdaq-demo, not only was DAQInterface installed as well, but it was configured automatically to work with artdaq-demo. In other words, the instructions given in the "Getting Started" section of the DAQInterface wiki were executed within the artdaq-demo installation scripts. Therefore, to begin running immediately, first do the following:

cd <base directory where you installed artdaq-demo>/DAQInterface

...and then take up the instructions on the DAQInterface wiki from the section "A First Walkthrough", https://cdcvs.fnal.gov/redmine/projects/artdaq-utilities/wiki/Artdaq-daqinterface#A-first-walkthrough.

Or, you can use run_demo.sh as described next.

Using run_demo.sh

cd <base directory where you installed artdaq-demo>/DAQInterface
ipcrm -a;./run_demo.sh --config <configuration> --comps "<components>" --no_om --runduration 20

<configuration> is one of the sub-directories in the daqinterface/simple_test_config directory.
<components> is one of the "components" in the first column of docs/known_boardreaders_list_example files.
For example:

ipcrm -a;./run_demo.sh --config demo --comps component{01..02} --no_om --runduration 20

OR
ipcrm -a;./run_demo.sh --config request_based_dataflow_example --comps component{01..03} --no_om --runduration 20

Monitoring the data

If, following the instructions on the DAQInterface wiki, you get the DAQ into a running state, it's possible to launch an art process designed for online monitoring purposes. To accomplish this, open a new terminal, and do the following:

cd <base directory where you installed artdaq-demo>
source setupARTDAQDEMO
art -c ${MRB_TOP}/srcs/artdaq_demo/tools/fcl/TransferInputShmem.fcl

and what you'll see, twice a second, are messages like the following:
######################################################################
Run 5, subrun 1, event 135 has 2 fragment(s) of type TOY1 or TOY2

TOY1 fragment 0 w/ seqID 135 has total ADC counts = 40

Fragment metadata: 
Board serial number = 618, sample bits = 12 -> max ADC value = 4095

First 10 ADC values in the fragment: 
...0:   2552  1218  2957  2154  1547  1510  1834  2028  2072  2186

TOY2 fragment 1 w/ seqID 135 has total ADC counts = 40

Fragment metadata: 
Board serial number = 7848, sample bits = 14 -> max ADC value = 16383

First 10 ADC values in the fragment: 
...0:   6682  8936 10249  5296 10108  6224  9552  8805  8923  9715

######################################################################

Basically, each of the two BoardReaders contains a fragment generator called "ToySimulator" which is creating fragments with a payload of 40 ADC counts apiece. However, the two fragment generators are configured differently - in one, the ADC values are 12-bit and can therefore assume a maximum value of 4095, in the other, the ADC values are 14-bit and can assume a maximum value of 16383. The values are randomly distributed according to a gaussian centered half-max with a sigma of 1/10th of the max. This monitoring you're running prints out the first 10 ADC values of this fragment from every 5th event passing through the system.

Let's play with this a little. First, hit "Ctrl-c"; you should see something like the following:

%MSG-i TransferWrapper:  ToyDump:toyDump@EndJob 19-Sep-2016 13:50:49 CDT  PostEndRun
Requesting that this monitor (shmem1) be unregistered from the dispatcher aggregator
%MSG
%MSG-i TransferWrapper:  ToyDump:toyDump@EndJob 19-Sep-2016 13:50:49 CDT  PostEndRun
Response from dispatcher is "Success" 

When you started art, a message was sent via XML-RPC to Dispatcher indicating that you wanted it to send you events. The details (that every 5th event should be sent, and that it should be done via shared memory as opposed to, say, over a network via multicast) were provided in the FHiCL, along with a unique label for your process, "shmem1". The aggregator will refuse to accept your request for events if you don't provide it with a unique label - so if, e.g., you set up another artdaq-demo environment and tried to run the same script without having terminated the first instance, you'd get something like the following:
%MSG-i TransferWrapper:  art 19-Sep-2016 14:14:56 CDT JobSetup
Attempting to register this monitor ("shmem1") with the dispatcher aggregator
%MSG
%MSG-i TransferWrapper:  art 19-Sep-2016 14:14:56 CDT JobSetup
Response from dispatcher is "Attempt to register newly-created monitor with label "shmem1" failed; a monitor with that label already exists" 

However, since we just hit "Ctrl-c" on the first monitoring process, if the Dispatcher successfully unregistered it, we can fire it up again with the same FHiCL document (and hence the same unique label). However, before we fire it up again, let's change both the fraction of events we receive as well as the way we monitor them. Edit the TransferInputShmem.fcl file you provided the art process by changing its "modulus" variable from 5 to 100, and then change the following line:
  end_paths: [ a3 ]

to
  end_paths: [ a1 ]

Now run
art -c srcs/artdaq_demo/tools/fcl/TransferInputShmem.fcl

once again.

What you'll see is two plots, which update about once every ten seconds, and which are filled with data from every 100th event. One shows all the ADC values for both fragments within a single event; notice that while the TOY1 fragment has 12-bit ADCs and hence a max ADC value of 4096, TOY2 has 14-bit ADCs and hence a max ADC value four times greater:

The other plot is two histograms, each showing the cumulative ADC values from all fragments of a given type for every 100th event. If you let it run for a while, you'll slowly see a gaussian forming.

artdaqDriver: a lightweight executable for testing

While the demo described above is designed to give a feel for what a full artdaq-based DAQ system looks like, frequently it's desirable to test fragment generators (discussed in-depth later in this wiki) and art modules in a more lightweight environment. Along with the standard BoardReaderMain, EventBuilderMain and AggregatorMain processes out of which one can create a DAQ, artdaq also supplies the artdaqDriver executable. Running artdaqDriver at the command line itself is very simple as all one needs to do is provide it with a FHiCL document; the complexity is in the FHiCL document itself. An example of this can be seen by the following steps:

  1. log into the test system where you installed the artdaq-demo
  2. switch to the bash shell, if needed
  3. cd <BASE_DIR>
  4. source setupARTDAQDEMO
  5. artdaqDriver -c srcs/artdaq_demo/tools/fcl/driver.fcl

And you'll see output like the following:

######################################################################

Run 101, subrun 0, event 1 has 1 fragment(s) of type TOY2

Toy fragment 0 has total ADC counts = 100

Fragment metadata: 
Board serial number = 999, sample bits = 14 -> max ADC value = 16384

First 10 ADC values in the fragment: 

PRINCIPAL TYPE: Event
PROCESS NAME | MODULE LABEL.. | PRODUCT INSTANCE NAME | PRODUCT FRIENDLY TYPE | SIZE
Driver...... | TriggerResults | ..................... | art::TriggerResults.. | ...-
Driver...... | daq........... | TOY2................. | artdaq::Fragments.... | ...1

Total products (present, not present): 2 (2, 0).

######################################################################

Basically, in the driver.fcl document, it's specified that an instance of the ToySimulator fragment generator (the same type used in the 2x2x2 demo) generate and send a set of events, which are then processed by the ToyDump art module, found in artdaq-demo/ArtModules. You can open up driver.fcl and play around with things like the parameter settings for ToySimulator, the art modules used to process the events, or even the fragment generator used - on this final point, artdaqDriver is very useful for testing purposes when you're developing your own fragment generator.

Next steps

By now you should have a taste of what artdaq and artdaq-demo are capable of. To learn how to run a DAQ system with different numbers of artdaq processes running on different hosts, potentially using artdaq-based systems different than artdaq-demo, take a look at the DAQInterface documentation, https://cdcvs.fnal.gov/redmine/projects/artdaq-utilities/wiki/Artdaq-daqinterface .