BNMR: Software overview

From DaqWiki
Jump to navigation Jump to search

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

Python "real" programs

Compiled programs for debugging hardware etc

Compiled automated tests

Python test programs

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, 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.

Retrieved from "https://daq00.triumf.ca/DaqWiki/index.php?title=BNMR:_Software_overview&oldid=7851"