Notes on running dcmapplication for feb readout tests¶
Last updated 2011/05/06 S. Kasahara
These notes describe how to run a standalone dcmapplication on a dcm node
on the test stand. Similar steps can be used to run the dcmapplication on the
- The first step is to determine an available dcm. The location of dcms are tabulated on:
dcms on the teststand and their position in the test stand timing chain are documented
on this web site. A contact person is listed next to the teststand dcms. Because multiple people working on the same dcm needs to be coordinated to avoid conflict, please contact the person next to the teststand dcm(s) on which the test is to be done or send an email out to the email@example.com email list before beginning work.
- Log into the dcm under account dcm:
kasahara@novatest01>ssh dcm-10 -l dcm dcm@dcm-10's password: [dcm@dcm-10:~]$This requires a password common to all dcms. Ask someone to obtain it.
- If concerned about getting a fresh start, the dcm can be rebooted using:
[dcm@dcm-10:~]$ su root [root@dcm-10:dcm]$ reboot [root@dcm-10:dcm]$ Connection to dcm-10 closed by remote host. Connection to dcm-10 closed. kasahara@novatest01>On reboot, the latest dcm kernel device drivers will be installed from the development base release:
kasahara@novatest01>ssh dcm-10 -l dcm dcm@dcm-10's password: [dcm@dcm-10:~]$ ls -l /dev/dcm* crw-rw---- 1 dcm nova 254, 0 May 5 23:41 /dev/dcm_control crw-rw---- 1 dcm nova 253, 0 May 5 23:41 /dev/dcm_data crw-rw---- 1 dcm nova 252, 0 May 5 23:41 /dev/dcm_status [dcm@dcm-10:~]$so rebooting is one way to get a fresh start using the development version of the device driver kernel module.
- Now check to see which febs are connected to the dcm and which timing link is enabled. This is done in the example below using dcmconntest.
[dcm@dcm-10:~]$ source /nova/novadaq/setup/setup_novadaq_nt1.sh --xcompile --opt Setting Up the NOVA-DAQ Environment INFORMATIONAL: Product 'cstXSD' (with qualifiers ''), has no v3_2_0 version (or may not exist) INFORMATIONAL: Product 'doxygen' (with qualifiers ''), has no v1_6_1 version (or may not exist) NOVA-DAQ Environment Enabled [dcm@dcm-10:~]$ dcmconntest Testing for connections... Enabled FEB Links: FEB Mask Hi 0x0000001f/Lo 0xffffffff FEB Serial Numbers: [ 0] FEB4.0-00514 [ 1] FEB4.0-00142 [ 2] FEB4.0-00506 [ 3] FEB4.0-00513 [ 4] FEB4.0-00547 [ 5] FEB4.0-00369 [ 6] FEB4.0-00536 [ 7] FEB4.0-00515 [ 8] FEB4.0-00412 [ 9] FEB4.0-00509  FEB4.0-00505  FEB4.0-00529  FEB4.0-00511  FEB4.0-00527  FEB4.0-00528  FEB4.0-00518  FEB4.0-00517  FEB4.0-00510  FEB4.0-00182  FEB4.0-00508  FEB4.0-00541  FEB4.0-00516  FEB4.0-00134  FEB4.0-00372  FEB4.0-00524  FEB4.0-00530  FEB4.0-00533  FEB4.0-00521  FEB4.0-00539  FEB4.0-00184  FEB4.0-00427  FEB4.0-00185  FEB4.0-00501  FEB4.0-00358  FEB4.0-00129  FEB4.0-00526  FEB4.0-00181  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------  ------------ Enabled Timing Ports: 0. [dcm@dcm-10:~]$In the example, febs are enabled on links 0-36 and the timing system is connected to timing port 0 (choices are 0 and 1). The check of the connected febs and enabled timing link can be used as a sanity check and the results should
be consistent with those shown in the wiki table: https://nova-daq.fnal.gov/redmine/wiki/dcm. If not, ask someone or
the nova_daq_software email list why.
- The next step is to begin the dcmapplication in a configuration that suits the test under study. Data taking tests which approximate the conditions of the detector can be done by configuring the dcm for DCS operating mode, with ASIC charge injection pulser enabled, and with the timing system enabled. Note that for logistical reasons on the test stand, it is often easier to run tests without the timing system (using the dcm internal timing emulator) since the use of the timing system requires coordination with other teststand dcm users. This is because all teststand dcms are in the same timing chain.
- The following test shows an example of running the dcmapplication with:
- DCS mode * Charge injection pulser enabled * Timing System in emulator mode
[dcm@dcm-10:~]$ source /nova/novadaq/setup/setup_novadaq_nt1.sh --xcompile --opt Setting Up the NOVA-DAQ Environment INFORMATIONAL: Product 'cstXSD' (with qualifiers ''), has no v3_2_0 version (or may not exist) INFORMATIONAL: Product 'doxygen' (with qualifiers ''), has no v1_6_1 version (or may not exist) NOVA-DAQ Environment Enabled [dcm@dcm-10:~]$ dcmapplication -c DcmFEBDCSModePulserEnabledConfiguration.xml -fl 0xffffffff -fh 0x1f -m test/datMessageFacility.cfg -n -1
In this test, the configuration file DcmFEBDCSModePulserEnabledConfiguration.xml supplies the majority of the configuration, however command line options are used to override or supplement that configuration. In particular:
- The -fl and -fh options specify the enabled feb lo and hi masks on the test dcm. A subset of the enabled febs can be selected using these options if desired.
- The -n option is used to specify the number of millislices the dcmapplication will generate before stopping. (-1 means run indefinitely).
- The -m option is used to select a message facility configuration file that does not require a dds server. All messages will be logged to standard output.
- To direct the output to a log file, scratch space has been set up on /scratch/dcmlog that is writable by the dcm account.
For example, execute the above command as:
[dcm@dcm-10:~]$ dcmapplication -c DcmFEBDCSModePulserEnabledConfiguration.xml -fl 0xffffffff -fh 0x1f -m test/datMessageFacility.cfg -n -1 >& /scratch/dcmlog/dcmapptest.log &
to direct the output to the /scratch area and run the dcmapplication in the background.
- A second test is to run the dcmapplication as above with the timing system enabled. In the following test the configuration of the dcmapplication is set to:
- DCS mode
- Charge injection pulser enabled
- Timing System enabled using Timing Port 0 (as determined from dcmconntest, this is the active timing port on dcm-10)
[dcm@dcm-10:~]$ dcmapplication -c DcmFEBDCSModePulserEnabledConfiguration.xml -fl 0xffffffff -fh 0x1f -m test/datMessageFacility.cfg -n -1 -t 0
The difference between this test and the previous test is that:
- The -t option has been used to specify the timing system is to be enabled using timing port 0.
As before the output can be redirected to the /scratch/dcmlog directory or any dcm writable directory.
Note that when the timing system enabled, the FEB StartDAQ command is not actually issued to the FEBs by the dcmapplication as it is when using the internal timing system emulator. Instead the StartDAQ command is passed in as part of a timing system sequence of commands to first sync the dcm to the external clock and then StartDAQ. Until this Sync/StartDAQ set of commands is issued, only empty MicroSlices are generated by the DCM FPGA, although even empty MicroSlices are processed by the dcmapplication so "data" will still flow.
The issuing of the sync command is done using the TDUControl application. This needs to be run on novatest01. To issue a sync, first note the position of the dcm in the timing chain as described on https://nova-daq.fnal.gov/redmine/wiki/dcm.
Currently dcm-10 is the first dcm in the timing chain, so it is easiest to do tests using the external timing system on this machine as it doesn't require doing anything to upstream dcms in the timing chain.
To begin TDUControl on novatest01:
kasahara@novatest01>source /nova/novadaq/setup/setup_novadaq_nt1.sh Setting Up the NOVA-DAQ Environment NOVA-DAQ Environment Enabled kasahara@novatest01>TDUControl
This will bring up the TDUControl GUI. Enter "tdu-master-01" as the Server and click the Connect button. If all goes well, the connection will be successful. If it's not successful, it may be that someone is already connected to the server, or that the configuration at the test stand has changed since this note was written. Ask someone, or send a note out to firstname.lastname@example.org if this is the case. (Note that you can often diagnose who is making use of the timing system by looking for a running TDUControl on novatest01.)
When this step is complete, push the big red button (just once) on the TDUControl GUI. This will send the timing system time, a sync, and a startdaq command. When this happens, one should notice a discontinuity in the time logged by the dcmapplication, a print of the receipt of the timing command, and a jump in the size of the MicroSlices indicating that the StartDAQ command was issued and the MicroSlices are no longer empty. The dcmapplication should then continue with normal data taking indefinitely.