Location of this file: http://cdms.physics.ucsb.edu/daqii/daq_faq.html

DAQ Frequently Asked Questions and Answers

  1. What is the directory structure of the DAQPackage?
    The DAQPackage on any DAQ computer is divided mainly into 4 subdirectories

  2. How do I modify experimental settings like time between flashes, etc?
    Edit the master.config file in the configuration directory on monitor. For example, one can modify the time between flashes corresponding to the tag TOTALTIME. After editing, click on Update Servers on the RC GUI, which will sync all servers with this new file. Most parameters are self explanatory.

  3. How do I stop automatic operations of the DAQ?
    Edit the master.config file on monitor and set all AUTO tags to "0" and "Update Servers". Write down what the settings were for these "AUTO" tags, so that you can again set them properly. Normally, we leave "AUTP_RESTART_AFTER_FILL", "AUTO_QET_SNAP_AT_CONFIG", "AUTO_RELOCK", "AUTO_LED_FLASH_DURING_CRYO_FILL" and "AUTO_VETO_PULSER_DURING_CRYO_FILL" enabled. As the situation arises, one may decide to disable any specific automatic feature, such as disabling "AUTO_LED_FLASH_DURING_CRYO_FILL", so as not to flash during a certain cryo fill.

  4. Cryo transfer is ongoing and I don't want the data taking to auto restart. What to do?
    Just disable the "AUTO_RESTART_AFTER_FILL" in the master.config file on monitor and "Update Servers". Run Control will not start a run after the cryo fill is finished.

  5. What is the optimum time to intiate a fill?
    The automatic flashing is done every 4 hours, so optimal time to initiate an evening or even morning fill is to time accordingly, so that the automatic flashing during cryo fill happens around the time when the automatic flashing would have happened, while still keeping in consideration the cryogen levels.

  6. What does the DAQ do during a cryo fill?
    Upon getting the fill request from the intellution, DAQ stops the ongoing run and acknowledges back to the intellution to proceed with the fill. Then, the DAQ configures the detectors and automatically takes a 2 min Veto Pulser run, where the veto system is flashed with a blue light pulser for calibration/monitoring purposes. Upon completition of this run, the DAQ flashes the towers sequentially, flasing Tower1 by the amount of time (FLASH_ON_TIME) specified in the master.config file and Tower2 by half that time (more effective LEDs), 20 minutes later. These procedures finish in about 45 mins from the beginning of the cryo fill. After the intellution relays to DAQ that it is done with the transfer, the DAQ waits for an additional 15 mins before automatically starting a new run. This new run is started in the same experiment mode as when the run was stoppped for cryofill.

  7. What are the periodic LED flashings?
    Every 4 hours (TOTALTIME specified in master.config), the DAQ pauses to neutralize the detectors by flashing the LEDs. To save time, unlike the sequential flashings during cryo fill, the DAQ flashes both towers simultaneously with a length of 1/5th of the FLASH_ON_TIME. There is a 20 mins cool down period before the DAQ resumes taking data.

  8. We just stopped a data run and I want to flash manually. OR, the Automatic Flashing during Cryo Transfer was disabled and we are doing Cryo Transfer now. How do I flash manually?
    Bring up the LED GUI from the RunControl GUI. The default values are all correct. You have 2 choices depending on how much time you have before starting the next run. If you are going to take a new dataset soon so would like to minimize the downtime, just flash both towers simultaneously. Modify the Bake On = 0.06 min. If you are doing a manual flash during the cryo transfer, you have more time, hence should flash the towers individually for more effective flashing. First flash the Tower1 only, by setting the Tower2 bias currents to 0 and LEDs to NO LEDs and modify the Bake On = 0.25 min. Then, click on "Bake". The baking should proceed, 10 mK CAN temp should reach as high as 280 mK. This bake will automatically stop in about 20 mins. Once you see the bake stopped message on the RC GUI, close the LED bake GUI and reopen it from the RC GUI, for ease of operation in flashing Tower2. Again, the defaults values should be correct. Just set the Tower1 bias current and leds to zero, like last time. Now, modify the Bake On = 0.12 min. Then, click on bake and the Tower2 should bake now. The 10mK CAN temp should go up to about 250mK.

  9. Where do the noise files go? How do I access them?
    The noise files produced by analyzing the first 500 randoms (_F0001) are stored on datasrv, in the location /var/www/noise/. Also, you can point your browser to the Noise Page and download any individual noise file. Using the NoiseViewer from the main RunControl GUI, one can always download the last 2 noise files. Username/Password combination is the same as the standard cdms combination for internal access.

  10. Where are the various status pages?
    The main status page is the Datasrv Status Page. There are important links at the top of this page. Particularly important is the Fast Online Analysis page which shows a variety of diagnostic plots based on fast online analysis of the data as they are acquired. Also, one must periodically check the DarkPipe/PipeCleaner Farm Status page to verify the healthy state of the SAC farm.

  11. Where do the data files go in the mine? On the surface??
    The data files are written to their individual dataset directories on builder in the /data/ directory. The data files are copied to tape as well as copied to the surface, to the location /cdmstmpf2/, accessible from any of the SAC computers (cdmsx). The fastest way to get to the SAC computers, while in the mine, is to use the private network, so do ssh cdmsd-p or cdmsf-p from any of the DAQ nodes. On the surface, once the datafiles are DarkPiped, they are moved to tape. So, there are 2 tape copies for each data file. Space is cleaned up in the mine disks as well as the SAC disks, only after the files have been successfully copied to the respective tapes.

  12. Where are the processed data files? How do I analyze the data?
    The processed data files exist on /cdmstmpb/RRQ_Run119/ accessible from any of the SAC computers. You are supposed to do CAP analysis only on cdmsg.

  13. There are error messages on the GUI regarding dp:Tapewriting. What should I do?
    If the error message is tar_error, it means the tape is full on the SAC SDLT drive. Please follow Steve Yellin's tape changing instructions on the DAQ Notebook and for streamlined step by step instruction, follow Mike D's summary from Steve's detailed instructions. Other possible error messages are busy which means the tape drive is busy writing tapes. The error messaroge could also be 1 GB left on device which means the tape is getting full.

  14. The event number on the RunControl GUI has stopped increasing since a long time. What should I do?
    It probably means one of the nodes of the Event Builder chain has stopped working, either due to the program crashing or one of the digitizer VME crate interfaces failing. Please call a DAQ expert to intiate a diagnostic.

  15. Well, I am expert enough to know that I need to remove and reinsert the SIS device driver to fix the crate problem. Just forgot how to actually do it!
    log in (rlogin computername) to both "vetocrate" and "tower1" and check on which node the corresponding "Event Builder" process has died. do ps x | grep runVetocrate on "vetocrate" and ps x | grep runTower1 on "tower1" to find this out. Once you identify on which computer the EventBuilder subprocess died (no process with show up from last step), on that computer, su to root and do /sbin/rmmod sis1100 and then do /sbin/insmod sis1100

  16. I see all these state changes like config, run, stop, etc. I would like to know more about whatever exactly happens during these state changes.
    Please refer to the Run State Changes Explained page to know the details of each operation.

  17. I see GPIB error with message like Unable to write to FEB or RTF or TLB. Should I be concerned?
    This means the GPIB server had failure in successfully setting the experimental parameters for the corresponding device. Best is to stop the run and config again. If you GPIB error(s) again, please contact a DAQ expert. Also, check on control if there is more than 1 copy of the RunControl running by doing ps x | grep RunControl. Each copy has multiple processes with more or less consequetive process IDs. If there are is more than 1 copy of RunControl running, you will see a 2 sets of very different process IDs.

  18. There was a cryo burp, now we have recovered and would like to set up the detectors again. What is the procedure?
    If the 10mK CAN temp went above 500mK, the detectors probably need to be baked. Bake for a few hours, flashing both towers simultaneously with all the default settings on the LED Bake GUI, with Bake On Time = 0.07 mins. If the temp didn't go high, flashing for a couple of cycles should be enough. The number of cycles is determined by the total Bake Time, which is divided by Bake Off Time + Bake On Time to arrive at the number of cycles.

    After this, once should ZAP the detectors one by one to get rid of the trapped flux. One MUST Reset Each Board before Zapping the board. Failure to do so may cause in oscillations causing high trigger rates. So, bring up the FEB GUI and first do Reset This Zip, followed by Zapping all 4 Squids at 5V. Do this for all the detectors one by one.

    Now, do a test run and verify the Noise Data looks good. If any detector has a lower bandwidth compared to normal, please repeat the Zapping procedure from above for that detector.