VME99 test stand IOC: Difference between revisions
| Line 6: | Line 6: | ||
==Goals for VME99== | ==Goals for VME99== | ||
List of the issues or requested features that will be addressed by VME99. | List of the issues or requested features that will be addressed by VME99. | ||
1) buffer management - flush buffer, faster file writes, clear and flexible system. Workforce undefined at this point. | |||
2) Gammaware working on LINUX / another machine | |||
3) MTrigger Readout | |||
*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 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. | ||
Revision as of 20:00, April 30, 2018
VME99
The concept of "VME99" is to integrate the firmware development test stand more fully as part of the experiments. The goal is to provide a system designed specifically for development of IOC software unique from any experimental system so that development work can proceed freely without risk to any running setup.
Goals for VME99
List of the issues or requested features that will be addressed by VME99.
1) buffer management - flush buffer, faster file writes, clear and flexible system. Workforce undefined at this point. 2) Gammaware working on LINUX / another machine 3) MTrigger Readout
- 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 does not properly flush digitizers at run stop.
- 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.
- Code base as-is does not correctly read out data from triggers, only digitizers.
- 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.
- 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.
- Version control is, well, out of control. DGS1 folder structure a mess.
JTA's less well-known issues:
- 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.
Hardware To Do
- Cable to setup a terminal without a terminal server. JTA will do this by end of 5/4/18.
Software To Do (most is in ppt file attached)
- Implementation of system config file into the Python scripts for building a specific system. E.g., vme99, xdigitizers. Need names of lists and locations, anything else? Mike will look at getting a system config file going [report on it next week]. - Modify of the Makefile to only compile what is needed. Mike and JTA both looking at the Makefile. - Best path forward? The correct path or simple path [start with correct path]? Argument for the simple path is to get Gammaware working on linux?