BNMR: Software overview

• BNMR overview
• Getting started
• Troubleshooting
• All BNMR pages
• Midas

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 frontend
• bin/febnqr_32bit.exe (bnqr only) - see frontend
• bin/bnxr_logger.exe - see data logging
• bin/logger_cleanup.exe - see data logging

Python "real" programs

• bnxr_common/beamtime_monitor.py - see shift monitor
• bnxr_common/beamtime_to_excel.py - see shift monitor
• bnxr_common/elog_every_run.py - see run transition scripts
• bnxr_common/mode_changer.py - see mode changer
• bnxr_common/rf_calculator_fe.py - see RF calculator
• cycling_framework/ppg/ppg_compiler_fe.py - see PPG compiler
• cycling_framework/run_comments/run_comment_editor.py - see data logging

Compiled programs for debugging hardware etc

• bin/bnmrbeamsim_32bit.exe - see hardware debugging
• bin/camp_test.exe and bin/camp_test_32bit.exe - see hardware debugging
• bin/epics_test.exe and bin/epics_test_32bit.exe - see hardware debugging
• bin/vppg_interactive_32bit.exe - see hardware debugging
• bin/sis3801_interactive_32bit.exe (bnmr only) - see hardware debugging
• bin/sis3820_interactive_32bit.exe (bnqr only) - see hardware debugging
• bin/psm_interactive_32bit.exe (bnqr only) - see hardware debugging
• bin/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 ODB
• bnxr_common/tests/test_ppg_calc.py - see automated tests that use the ODB
• bnxr_common/tests/test_psm_calc.py - see automated tests that use the ODB
• bnxr_common/tests/diff_mud_file.py - see data logging
• bnxr_common/tests/dump_mud_file.py - see data logging
• cycling_framework/ppg/tests/test_ppg.py

Unused compiled programs

• bin/epics_log.exe and bin/epics_log_32bit.exe - EPICS logging is handled by the MUD logger in bnmr / bnqr
• bin/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, run the following on isdaq01 from the repository root:

# For the first install
mkdir build
cd build
cmake .. -DEXP=BNMR
# or cmake .. -DEXP=BNQR
make install

# For updates
cd build
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

# Compile 64-bit version
cd build
make install

# Cross-compile 32-bit version
cd ..
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 ~/cycling_dev/packages/benmr/bnxr_common/custom/status.html $MIDASSYS/resources/status.html
  else
    ln -s ~/cycling_dev_bnqr/packages/benqr/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.