Difference between revisions of "DAQ Testing/20190204"
Line 26: | Line 26: | ||
** Result: '''this didn't fix it (in JAPAN error code assignment), so we should check with old PAN and do a HAPTB ramp DAC test again to see if the channels have actually broken''' | ** Result: '''this didn't fix it (in JAPAN error code assignment), so we should check with old PAN and do a HAPTB ramp DAC test again to see if the channels have actually broken''' | ||
− | We still need to put the helicity control board back in. | + | We still need to put the helicity control board back in. (UPDATE: Feb 8th - Cameron found both Hel CBs and tested both in Bob's TEDf test stand. The new one that was given new firmware didn't work, but the other one did, so Riad needs to look at the problem) |
== Establish Standard DAQ Procedure == | == Establish Standard DAQ Procedure == |
Revision as of 11:03, 8 February 2019
Back to Main Page >> DAQ Documentation Portal >> DAQ Testing >> DAQ Commissioning Notes
Previous Day of Testing << >> Next Day of Testing
February 4th, 2019 Testers: Cameron Clarke, Devi Adhikari, Ye Tian, Paul King
Goals
- Understand and correct problems with Cavity BCMs
- Restore Helicity Control Board in CH crate
- Establish standard DAQ procedure
- Establish standard data analysis procedure
- Take pedestal noise floor calibration runs for updated SAM cabling configuration
Cavity BCMs
Ye Tian made some serious progress on getting the Cavity BCMs up and running properly. The issue stemmed from saturating signals, possibly due to reflections or over-attenuation of signals, and several tests and parameter modifications have been developed to counter this problem. See her notes here and here.
Restore Helicity Control Board in CH crate
We took the fiber translator board and put it back in.
Importantly we noticed that the vqwk_1 and _4 were improperly inserted into the CH VME crate and we properly inserted them
- Run 1193 - checks that this fixed vqwk_1_channels that weren't working to work now hopefully
- Result: this didn't fix it (in JAPAN error code assignment), so we should check with old PAN and do a HAPTB ramp DAC test again to see if the channels have actually broken
We still need to put the helicity control board back in. (UPDATE: Feb 8th - Cameron found both Hel CBs and tested both in Bob's TEDf test stand. The new one that was given new firmware didn't work, but the other one did, so Riad needs to look at the problem)
Establish Standard DAQ Procedure
Steps to utilize the Parity DAQ in a healthy and collaborative fashion. The "DAQ" here refers to the CODA system and its attached processes, which must be run from within the "apar" user account on the "adaq" computer system. We prefer to use "adaq3" computer for parasitic testing purposes, but when PREX/CREX runs we will switch over to the new "adaq1" machine instead. We should be careful to utilize the "parity-daq" channel of the PREX collaboration Slack Channel to alert other users to intended DAQ operations and availability. For optimal collaboration the DAQ should be run only from the MCC building for injector studies or the 1st or 2nd floor of the counting house (or the HRS laptops for on the fly testing).
Note:
- If at any time while using CODA something simply fails, work your way backwards by simply
- trying whatever it was you were doing again
- then try restarting CODA
- then try rebooting each of the ROCs through telnet sessions
- and if after doing those at least twice, you still have failures, then call an expert
- CODA's RCgui failing to "stop" or failing to register the buttons at the top of the screen are not serious problems and can be ignored
- CODA definitely (for now) takes 20 seconds for the event builder to connect to the et_system (by design)
To run the DAQ:
- Log into apar@adaq3 (later adaq1, ask an expert for the password):
ssh -Y apar@adaq3
- Check that no other users are using the DAQ by checking for processes called "et_start", "coda_er_rc3", "coda_eb_rc3", and "rcgui". If any of these processes are running then the DAQ is in use by someone else.
top ps -u apar | grep -i rcgui
- If no other COAD processes are in use then begin a CODA session with the ~/bin/startcoda script which initializes the event transport (ET) systems and begins the run control (RCgui) session
startcoda
- Once the RCgui session is active, with several xterms opening up for diagnostic information, make sure that the session reads "par1", the experiment id reads "parity", and the configuration reads whatever configuration you want to use.
- To load a configuration into RCgui for data taking
- If the configuration is not the one you want, you can change it or make a new one with CEdit.
- To load a pre-existing configuration if changes have been made (and also in general, just for safety):
- Go through the menus to get to: Options->Coda2 Database->RunTypes
- Select the configuration you want from the DB2Cool (CODA 2 database to CODA 3 COOL) list
- Confirm Translation of CODA 2 database structure to CODA 3 COOL database format
- To load a pre-existing configuration after COOL translation has been done (this is the necessary step):
- Go through the menus to get to: Configurations->COOL
- Select the configuration you want from the COOL RunTypes list
- If the configuration you wanted was already set at start up of RCgui, then you can instead simply:
- Go through the menus to get to: Platform->Connect (or Shift-C)
- To start a run, use the buttons at the top of RCgui in the following sequence
- Configure: if successful then all of the components loaded in your configuration (cedit) should show up and read as "configured"
- Download: this step executes part of the CRL and initializes VME components as needed - wait for this step to finish changing all components' states to "downloaded" before proceeding (going to fast at this stage will crash the DAQ)
- Prestart (or start also works at this stage): if successful every component should read "paused"
- Go (play button): This connects all the components to each other, executes the first few initialization events, and begins data taking. Don't be alarmed when the 2nd ET causes slowdown for a few seconds while it connects (will be fixed soon)
- Stop: To end a run, press stop. Also reset works, but stop is preferred
- Reset: To recover from a minor CODA error press reset
- Start: Does Prestart and Go at the same time
- To look at ROC command line or to reboot them, see DAQ_Networking
Establish standard data analysis procedure
To analyze any CODA DAQ .dat file with JAPAN, do the following:
- Log into apar@adaq3 (later adaq1, ask an expert for the password):
ssh -Y apar@adaq3
- Find the official copy of the analysis software in the adaq file system:
cd ~/PREX/japan source ../setup_japan.tcsh
- Run the JAPAN software on a given run number with
./build/qwparity --config prex.conf -r [number]
- The config file (contained within the Parity/prminput folder) should contain all of the necessary information for JAPAN to decode the data
- Care must be taken to ensure that the maps correspond to what configuration the DAQ channels were in during the data collection for that run
- Run numbers can be used automatically to do this, but the user must define the map files appropriately so it works
- When doing no-beam testing it is important to turn off the beam current normalization for channel readouts (use prex_testing.conf instead)
- The ROOT output should go into your (setup_japan.tcsh initialized environment variable location) ${QW_ROOTFILES}, for analysis done on the corresponding .dat file in ${QW_DATA}
- After analyzing your run, be sure to look at the JAPAN outputs and read the Error Summary list
- Any number above 0 indicates that an event has failed some check and the data was not saved to the ROOTfile (or it was, but has an error code assigned to it)
PANGUIN and Compiled Scripts
Paul King says that it is best to let PANGUIN do its thing in as efficient a way as possible, and to make compiled scripts do as simple a task as possible as well. There is no need to overcomplicate any given task, and when something complex is needed to instead break it up into its tiniest parts and make things as general as possible to speed stuff up and avoid trying to incorporate too many bells and whistles at once.
- Panguin can be run with the following:
cd ~/PREX/japan/panguin source ../../setup_japan.tcsh ./panguin -f macros/[macroName].cfg -r [runNumber]
- Some of the macros in there are fairly well documented, and the functionality should be self-explanatory
- The general idea is that panguin can either do Draw() commands on variables and cuts you give it, or it can execute macros
- See the Tritium or APEX Online64 folders for their sets of macros and draw commands (and know that many more complicated activities can be accomplished, and all panguin is doing is interfacing the ROOT command line interface with a ROOT file with user config arguments)