BNMR: Software overview
Program list
Programs with the _32bit suffix are designed to be run on the VMIC machine; all others are designed to be run on the host PC.
Compiled "real" programs
bin/febnmr_32bit.exe
(bnmr only) - see frontendbin/febnqr_32bit.exe
(bnqr only) - see frontendbin/bnxr_logger.exe
- see data loggingbin/logger_cleanup.exe
- see data logging
Python "real" programs
bnxr_common/beamtime_monitor.py
- see shift monitorbnxr_common/beamtime_to_excel.py
- see shift monitorbnxr_common/elog_every_run.py
- see run transition scriptsbnxr_common/mode_changer.py
- see mode changerbnxr_common/rf_calculator_fe.py
- see RF calculatorcycling_framework/ppg/ppg_compiler_fe.py
- see PPG compilercycling_framework/run_comments/run_comment_editor.py
- see data logging
Compiled programs for debugging hardware etc
bin/bnmrbeamsim_32bit.exe
- see hardware debuggingbin/camp_test.exe
andbin/camp_test_32bit.exe
- see hardware debuggingbin/epics_test.exe
andbin/epics_test_32bit.exe
- see hardware debuggingbin/vppg_interactive_32bit.exe
- see hardware debuggingbin/sis3801_interactive_32bit.exe
(bnmr only) - see hardware debuggingbin/sis3820_interactive_32bit.exe
(bnqr only) - see hardware debuggingbin/psm_interactive_32bit.exe
(bnqr only) - see hardware debuggingbin/psm3_interactive_32bit.exe
(bnmr only) - see hardware debugging
Compiled automated tests
bin/unit_tests/*.exe
- see Automated tests that don't use the ODB
Python test programs
bnxr_common/tests/test_mud_logger.py
- see automated tests that use the ODBbnxr_common/tests/test_ppg_calc.py
- see automated tests that use the ODBbnxr_common/tests/test_psm_calc.py
- see automated tests that use the ODBbnxr_common/tests/diff_mud_file.py
- see data loggingbnxr_common/tests/dump_mud_file.py
- see data loggingcycling_framework/ppg/tests/test_ppg.py
Unused compiled programs
bin/epics_log.exe
andbin/epics_log_32bit.exe
- EPICS logging is handled by the MUD logger in bnmr / bnqrbin/tppg_interactive_32bit.exe
- this version is for TRIUMF PPGs; we use PulseBlaster PPGs
Repository location
The main repository is on BitBucket at https://bitbucket.org/ttriumfdaq/bnmr/.
Updating bnmr/bnqr software
The main repository uses submodules for some dependencies, so checking out updates requires:
git pull git submodule update
To compile the real software, we currently have to compile separately on isdaq01 and lxbnmr/lxbnqr (as the lx machines have had their OS upgraded, but isdaq01 has not, and the two are mutually incompatible for cross-compilation). Once isdaq01 has been upgraded, we will be able to run all compilation from there again and compile times will be significantly faster.
# # For the first install # # on isdaq01 mkdir build cd build cmake .. -DEXP=BNMR -DONLY_64=1 -DNO_MTRPC=1 # or cmake .. -DEXP=BNQR -DONLY_64=1 -DNO_MTRPC=1 make install
# on lxbnmr (or lxbnqr) mkdir build_32 cd build_32 cmake .. -DEXP=BNMR -DNO_UNIT_TESTS=1 -DONLY_32=1 -DNO_MTRPC=1 # or cmake .. -DEXP=BNQR -DNO_UNIT_TESTS=1 -DONLY_32=1 -DNO_MTRPC=1 make install # # For updates # # on isdaq01 cd build make install
# on lxbnmr (or lxbnqr) cd build_32 make install
This will:
- Cross-compile the frontend to run on the 32-bit VMIC machine (either febnmr or febnqr depending on the
-DEXP=...
flag you passed to cmake) - Compile the MUD logger
- Compile and/or cross-compile various debug executables
- Compile and/or cross-compile various automated tests
To compile a dummy version of the software that does not talk to the real hardware or EPICS (and which can be run on a laptop):
mkdir build cd build cmake .. -DEXP=BNMR -DDUMMY_MODE=1 # or cmake .. -DEXP=BNQR -DDUMMY_MODE=1 make install
Updating midas
# Get updates cd $MIDASSYS git pull git submodule update --init --recursive # Compile 64-bit version mkdir -p $MIDASSYS/build cd $MIDASSYS/build make install # Cross-compile 32-bit version cd $MIDASSYS make linux32 # Change status page from midas default to a symlink if ! [ -L $MIDASSYS/resources/status.html ]; then mv $MIDASSYS/resources/status.html $MIDASSYS/resources/status.html.orig if [ $USER == "bnmr" ]; then ln -s ~/packages/bnmr/bnxr_common/custom/status.html $MIDASSYS/resources/status.html else ln -s ~/packages/bnqr/bnxr_common/custom/status.html $MIDASSYS/resources/status.html fi fi
Then re-compile the bnmr/bnqr software
Interactions between programs
- RPC between febnmr.exe/febnqr.exe and ppg_compiler_fe.py to generate PPG bytecode at begin-of-run
- RPC between rf_calculator_fe.py and ppg_compiler_fe.py to generate PPG bytecode when user clicks button on Settings webpage
- Midas buffers between febnmr.exe/febnqr.exe and bnxr_logger.exe for data
- Midas buffers between kalliope_fe.exe and bnxr_logger.exe for data
- RPC between febnmr.exe/febnqr.exe and kalliope_fe.exe to inform it of PPG cycle state
- run_comment_editor.py writes to a text file in the data directory, which is then read by bnxr_logger.exe when it's time to write a new MUD file. Text file is deleted at the end of the run.
Run transitions
MIDAS allows clients to register to various transitions (e.g. START,STOP). However, many clients need to perform actions in a certain order. For example, in the bnmr and bnqr experiments, at begin-of-run, the RF calculator is required to check the input parameters and compute various derived values (e.g. the list of I,Q pairs to load on the PSM). This must be completed before the frontend attempts to load these values.
This is accomplished in MIDAS by the use of transition sequence numbers. The RF calculator and the frontend both register to the START transition, but the frontend is registered to only handle the transition after the RF calculator has finished doing the work it need to do.
The full list of transition orderings (higher happens later) is:
- 1 - mode changer (ensure correct run number)
- 50 - RF calculator (compute PSM I,Q pairs, create human-readable PPG program to run, setup ODB links for MUD logging etc)
- 100 - frontend configuration (setup PSM, call PPG compiler to generate bytecode etc)
- 100 - run comment editor (no-op)
- 500 - PPG compiler (no-op for bnmr / bnqr as the frontend calls the PPG compiler by JRPC)
- 900 - MUD logger (connect to CAMP, open Midas buffers etc)
- 990 - frontend setup first cycle (configure first scan step and start PPG)
If any of these transitions fail, the latter ones do not happen (and a "STARTABORT" transition signal is sent to all the clients). Having the frontend delay starting the PPG until the end of the sequence ensures that all the clients are ready for when the data starts to flow. Having the frontend configure the hardware early in the sequence prevents the MUD logger from doing unnecessary work if there is a hardware issue.