VME99 test stand IOC

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.

The IOC has been flashed with the most recent BSP file (devel7) and has been given in IP address on ONENET

192.168.203.211

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

Known issues brought up from past experiments:

• 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. Discussion of this is found at digitizer flushing.
• 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.

Other bugs found in DGS1 Gnote files

Hardware To Do

- Cable to setup a terminal without a terminal server. JTA will do this by end of 5/4/18. (completed)

- Issue with the older IOC, perhaps need to flash the new IOC to try as it is "seen" by the terminal (done)

- Serial connect on the "new" linux machine (need root access) (done)

-

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]. - Update [5/7]: Mike not here to update. Suggestion to manually update the files for vme99. genSystem.py (various versions). Around lines 480ish, sets arrays defining the system boards and channels. Parse a text file to generate these [vmelist, boardlist, vmecrates, brds, chans]. Only change in the vme01.DGS.cmd is the asynDigitizerConfig() call. Have the "name of sys", etc..generating a text file on the fly to demonstrate for DGS.

- Now just need to parse to read in, as a test. Seems simple but still some details. HOWTO: pycd on dgs1, a number of build directories are there, genSystem.py is the main program.

- Modify of the Makefile to only compile what is needed. Mike and JTA both looking at the Makefile. - Update [5/7]: JTA and WJ working on this on CON5. Located, now looking for a simple Makefile that is flat. /global/devel/gretTop/9-22/dgsDrivers/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?

relevant documentation that is elsewhere

https://wiki.anl.gov/gsdaq/The_DGS/DFMA_EPICS_Implementation

https://wiki.anl.gov/gsdaq/Tim_Madden_software_documentation

Understanding how many Makes there are in the system

The general process for updating the PVs is to do the following:

ssh con5
cd /global/devel/gretTop/9-22/dgsDrivers
make
cd ..
cd dgsIoc
make
 

There is a cryptic comment in the Python code where the above is in comments, that says

#it may be devel or develbuild... depending on where you are building from

Breakdown of the make file

MakeFile Archaeology

Powerpoint notes

File:VME99 20180430.pptx

System configuration file concept

We in principle agree that we could have a simple text file that could be read in by Python to control the generation of files. Something along the lines of

DGS System File
vmelist = [32,1,2,3,4,5,6,7,8,9,10,11]
vmecrates=['VME01','VME02','VME03','VME04','VME05','VME06','VME07','VME08','VME09','VME10','VME11']
// replicate board list and names for each instance in vmelist
// VME 32 is the trigger
boardlist=[1,2,3,4,5]
brds=['MTRIG','RTR1','RTR2','RTR3', 'RTR4']
// VME 1 has four digitizers, like every other DGS digitizer crate
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 2
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 3
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 4
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 5
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 6
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 7
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 8
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 9
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 10
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
// VME 11
boardlist=[1,2,3,4]
brds=['MDIG1','SDIG1','MDIG2','SDIG2']
 

is what we foresee.