1 / 10

Enhancing TestDAQ Software for Uniform Testing Across Production Sites

Explore the comprehensive testing protocols and software enhancements proposed by Mark Krasberg from the University of Wisconsin for the Testing DAQ systems. Emphasizing standardized testing sites, GPS integration, string processor upgrades, and firmware improvements for efficient data collection.

ianna
Download Presentation

Enhancing TestDAQ Software for Uniform Testing Across Production Sites

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Testing DAQ PY04 Mark KrasbergUniversity of Wisconsin Berkeley Collaboration Meeting 20 March, 2005

  2. Current Testing DAQ Software • Python scripts (PyDOM, autogen-steering, multimon, lcchain.py, cold_reboot_test.py) • Domcal • Multiple workspaces (for running TestDAQ and STF) • TestDAQ launch scripts Testing DAQ PY04 Mark Krasberg – University of Wisconsin

  3. Many Different Test Setups 1 Testing DAQ PY04 Mark Krasberg – University of Wisconsin

  4. The Different Setups • StringProc yes/no implies different versions of TestDAQ launch scripts, and means data-collector either runs on a dedicated machine, or else it runs on the DOMHub. • GPS yes/no means different TestDAQ software necessary • Release “243” is last year’s standard FAT release (“bf” fixes bad timing bug) • Dedicated database determines whether STF and autogen-steering and multimon can run locally • Only South Pole and SPTS have done away with ZIPs so far – this makes things run much smoother. We continue to have occasional ZIP problems in DFL testing, and Sweden encounters ZIP problems more often (their string processor machine had/has only 800 Mbytes). Testing DAQ PY04 Mark Krasberg – University of Wisconsin

  5. Make Testing Uniform AcrossProduction Sites Testing DAQ PY04 Mark Krasberg – University of Wisconsin

  6. Testing Site Changes • Want to standardize the testing sites • Sweden • Needs a GPS unit • Needs an improved string processor • Needs a software upgrade • DESY • Needs a GPS unit • Needs to use the string processor they already have • Needs a software upgrade • Martin Kestel will integrate DOMTest Testing DAQ PY04 Mark Krasberg – University of Wisconsin

  7. Pole Improvements to Implement for next FAT • Improved launch scripts • TestDAQ can be run simultaneously from different local NFS’d accounts (eg SPTS and DFL), if need be. • Local output files go into temporary directory ~/output#######, where “#######”=run number (this means aborted run data is always saved) • Monolith was integrated into the launch scripts • we can run monolith on FAT data in the future • would be able to look at the data using icetray • An attempt was made to have as little deadtime between runs as possible • Axed zip files (finally) • this makes data taking smoother, less deadtime between runs, easier to analyze events • Added ability to create LocalCoincidence and Flasherboard TestDAQ steering files automatically (using autogen-steering) Testing DAQ PY04 Mark Krasberg – University of Wisconsin

  8. Proposed 2005 FAT TestDAQ runs • Axe Optical Sensitivity Runs (use “multimon” instead) • Continue to take GainVsHV and DarkNoise runs with Local Coincidence disabled • Would like to take Linearity Runs using new trigger mode – LocalCoincidence UP.and.DOWN • This would enable linearity data to be taken with no background • With this mode we would be able to • Take backgroundless cosmic data • Easily test Local Coincidence • This requires a firmware change • LBL thought they might be able to do this in May, after which we can integrate into FATs • Add new LocalCoincidence Runs (using LC enabled UP.or.DOWN) into normal FAT data-taking (LocalCoincidence runs require database to know where the “top” and “bottom” DOMs are • Pole improvements (eg. axing zip files) will reduce the deadtime between runs Testing DAQ PY04 Mark Krasberg – University of Wisconsin

  9. 2005 FAT Testing Firmware • Software – will use the Pole mainboard release (includes Local Coincidence/GPS/Flasherboard support) • Use DOR Rev 1’s if available, otherwise we can use Rev 0’s Testing DAQ PY04 Mark Krasberg – University of Wisconsin

  10. Summary • Want to make the different FAT setups uniform – may not be possible if GPS units unavailable • Axe Optical Sensitivity runs in favor of multimon • Intend to utilize Pole improvements in this year’s FATs (improvements should reduce deadtime between runs) • Minimize deadtime (axe zip files, for example) • Include Local Coincidence Runs as part of FAT • Linearity runs and also dedicated LC runs • Want to use the same mainboard release as at South Pole Testing DAQ PY04 Mark Krasberg – University of Wisconsin

More Related