BNMR: Software overview

From DaqWiki
Revision as of 13:31, 29 April 2022 by Bsmith (talk | contribs) (Created page with "{{Pagelinks}} == 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...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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/. It contains submodules, so checking out updates requires:

git pull
git submodule update

Compilation

To compile the real software, run the following on isdaq01 from the repository root:

mkdir build
cd build
cmake .. -DEXP=BNMR
# or cmake .. -DEXP=BNQR
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

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.