Challenges and Solutions in Using EPICS for Digital DAQ Systems
Digital DAQ systems based on EPICS face issues with version control, data reading, trigger handling, and GUI consistency. Solutions involve code optimization, improving trigger management, and enhancing GUI design for better user experience.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
VME99 Making EPICS usable across multiple systems
What exists now The digital DAQ systems are based on EPICS A conversion technique was designed by J. Anderson / A. Kreps / T. Madden to match EPICS process variables (PVs) to registers/fields of firmware using spreadsheets. Spreadsheet is maintained in Excel, can be edited in OpenOffice or LibreOffice Spreadsheet is saved as tab-separated text file Python script reads tab-separated text file and generates C and/or C++ code plus EPICS database files Auto-generated code is then compiled along with template C/C++ using make script to build images for every VME embedded processor in system All Python code originally written by T. Madden; subsequent modifications done by M. Carpenter and J. Anderson Due to VxWorks licensing issues, compilation of VME processor code can only be done on old Sun node con5 . Multiple threads run on every VME processor One thread per digitizer for data collection, one for EPICS, one for data sender, etc. Firmware is maintained by engineers on Subversion Java code written by T. Madden uses EPICS to allow end users to erase, program and verify hardware Flash RAM on all boards in system. New code image takes effect upon power cycle or in response to specific sequence of register I/O to board (soft boot).
Most Commonly Known Problems Version control is, well, out of control. DGS1 folder structure a mess. Code base as-is does not use optimal method to read data from digitizers and has problems if fill rate of FIFO buffers in digitizer boards not well-matched across crate. Numerous patches such as per-board timers have been put in, but are fragile. Code base as-is does not correctly read out data from triggers, only digitizers. Code base does not properly flush digitizers at run stop. Code base has sort and copy modes put in at one point to assist with event sorting that now are of dubious value. Argument has been put forward that sort mode is vestigial and should be removed. Code can fall into states where data buffers continuously fill but no data is sent, resulting in crash of VME processor when it runs out of buffers. Only recourse known is to power cycle. Source of problem unknown. System should at minimum stop triggers and set error bits before power cycle required, but doesn t. GUIs for digital DAQ systems not consistent with each other and not consistent with PV/spreadsheets. Not even consistent in display method (DGS & HELIOS use MEDM; DFMA uses CSS). All GUIs have major problems with disconnected controls, lack of controls for various PVs, etc. Has resulted in generation of numerous bash scripts that are undocumented and not under version control. Many experimenters have personal cheat sheet setups in which they perform direct read/write cycles to specific registers by address using the back door access. These cheat sheet magical incantations have been written down during beam time for one specific experiment and are constantly misplaced or forgotten.
Less Commonly Known Problems No support in system for A24/D16 VME transactions. No support in system for VME interrupts or even use of VME interrupt lines as polled service request flags. No support in system for source-synchronous block transfer on backplane. No architectural support in system for any other kinds of modules other than trigger or digitizer . Some support for two subtypes of trigger (master and router) but no support for subtypes of digitizer (master and slave). Engineering diagnostics cannot be run in-situ except by connecting a Windows 2000 machine to onenet (violates network security rules) that runs one specific version of Java (long ago deprecated) and uses a very old version of the test stand software GammaWare that doesn t match current firmware. VME processor code compilation references many files from a old snapshot of GRETINA embedded processor code but uses only a little; source scattered in multiple places; confusing mix of function names. Due to manufacturer changes there are two EPICS board support package (BSP) sets required based upon hardware revision of VME processor. No method currently in place in make for full description of system architecture to ensure correct (or optimized) build per-crate. Requires manual intervention.
The VME99 idea Make a one-backplane system in the firmware test stand that is well-coupled to the test stand. Provide setup suitable to update GammaWare so that it works in the experimental systems without need of an obsolete computer running an obsolete version of Java. Test potential for Linux versions of GammaWare. Modify the development sequence (make, Python, etc.) to allow building code specific and unique to the test stand VME processor ( VME99 )without risk to the running experiments. Develop and institute full version control of VME99 software with branches, tags, etc. Implement formalized method of releasing VME99 software tagged versions to the experiments after thorough testing at the test stand. Develop system-level descriptor files to fully characterize make per-system (DGS, DFMA, HELIOS, MUSIC, Clover, X- array, etc.). Make the VME99 setup into a standard teaching setup to be used by every new grad student and post-doc to learn how digital DAQ works and to train them in how to run systems to ensure proficiency before taking shifts.
