BNMR: Software overview: Difference between revisions

From DaqWiki
Jump to navigation Jump to search
mNo edit summary
(4 intermediate revisions by the same user not shown)
Line 56: Line 56:
  git submodule update
  git submodule update


To compile the real software, run the following on isdaq01 from the repository root:
To compile the real software, we currently have to compile separately on isdaq01 (for stuff that runs there) and isdaq06 (for stuff that runs on lxbnmr/lxbnqr). This is because isdaq06 and the lx machines run modern OSes, and isdaq01 is still on an old OS (so we can't cross-compile from it). 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
  # For the first install
#
# on isdaq01
  mkdir build
  mkdir build
  cd build
  cd build
  cmake .. -DEXP=BNMR
  cmake .. -DEXP=BNMR -DONLY_64=1 -DNO_MTRPC=1
  # or cmake .. -DEXP=BNQR
  # or cmake .. -DEXP=BNQR -DONLY_64=1 -DNO_MTRPC=1
  make install
  make install
   
   
# on isdaq06
mkdir build_32
cd build_32
cmake .. -DEXP=BNMR -DNO_UNIT_TESTS=1 -DONLY_32=1
# or cmake .. -DEXP=BNQR -DNO_UNIT_TESTS=1 -DONLY_32=1
make install
#
  # For updates
  # For updates
#
# on isdaq01
  cd build
  cd build
make install
# on isdaq06
cd build_32
  make install
  make install


Line 72: Line 89:
* Cross-compile the frontend to run on the 32-bit VMIC machine (either febnmr or febnqr depending on the <code>-DEXP=...</code> flag you passed to cmake)
* Cross-compile the frontend to run on the 32-bit VMIC machine (either febnmr or febnqr depending on the <code>-DEXP=...</code> flag you passed to cmake)
* Compile the MUD logger
* Compile the MUD logger
* Compile and/or cross-compile various debug executables
* Compile various debug executables
* Compile and/or cross-compile various automated tests
* 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):
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):
Line 88: Line 105:
  cd $MIDASSYS
  cd $MIDASSYS
  git pull
  git pull
  git submodule update
  git submodule update --init --recursive
   
   
  # Compile 64-bit version
  # Compile 64-bit version
  cd build
mkdir -p $MIDASSYS/build
  cd $MIDASSYS/build
  make install
  make install
   
   
  # Cross-compile 32-bit version
  # Cross-compile 32-bit version
  cd ..
  cd $MIDASSYS
  make linux32
  make linux32
   
   

Revision as of 14:16, 26 July 2024

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 (for stuff that runs there) and isdaq06 (for stuff that runs on lxbnmr/lxbnqr). This is because isdaq06 and the lx machines run modern OSes, and isdaq01 is still on an old OS (so we can't cross-compile from it). 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 isdaq06
mkdir build_32
cd build_32
cmake .. -DEXP=BNMR -DNO_UNIT_TESTS=1 -DONLY_32=1
# or cmake .. -DEXP=BNQR -DNO_UNIT_TESTS=1 -DONLY_32=1
make install 
#
# For updates
#
# on isdaq01
cd build
make install

# on isdaq06
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 various debug executables
  • 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.