BNMR: frontend

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

Introduction

The frontend program (febnmr_32bit.exe or febnqr_32bit.exe) is at the heart of the bnmr and bnqr DAQ systems, and is responsible for starting the PPG, reading data from the multichannel scalers, programming the PSM, and scanning variables (frequency, CAMP, EPICS etc) during the run. It runs on the VMIC frontend computer located in the VME crate (lxbnmr or lxbnqr). The VMIC is a 32-bit computer running linux that has access to the same disk(s) as the Midas Host and can directly access other VME modules in the VME crate.

The frontend program is built using the MIDAS frontend system and a core "cycling framework" that is used by several experiments that need to scan things while running PPG cycles.

The code is very object based, with abstractions for things like "data sources" and "scannable devices". The core logic for when data gets read out, or a voltage gets changed etc, is centralized in the core framework and identical for both DAQs. The differences between the two DAQs are contained in the (relatively small) febnmr.cxx and febnqr.cxx files, where the former creates a PSM3 object while the latter creates a PSM1 object, for example.

Frontend operation

Reading data from the ODB

The frontend obtains system data, experiment control parameters etc. from the ODB. It also writes information back into the ODB. Almost all configuration is done via the ODB, except for the histogramming configuration which is very complex and doesn't change often.

The frontend uses ODB using db_get_record() to access areas of the ODB where numerous keys are needed.

Initialize hardware

When the frontend is started, the function frontend_init() is run. This function opens records to the ODB (see above) and may open some hotlinks. It also opens a connection to the VME crate, and performs initial initialization of the DAQ hardware modules (PPG,PSM,Scaler(s),VMEIO32).

Access to the functions of the VME Modules is provided by a software driver (program) specific to each module.

Begin-of-run

The frontend actually handles the begin-of-run transition twice. First to validate various settings and configure the various hardware devices, then a second time to actually start the PPG. See the software overview page for the rationale.

In the first transition, the frontend:

• Ensures that the various ODB structures match what we expect
• Reads the settings that were computed by the RF calculator
• Call the PPG compiler to grab the bytecode to load
• Configures the hardware devices (PPG, PSM, scalers, helicity etc)

In the second transition, the frontend:

• Prepares the hardware for the first cycle in each scan
• Starts the first cycle

Checking the progress of each cycle

The PPG produces a pulse train of "MCS next" output signals during each cycle. The number of pulses corresponds to the number of dwell times (number of bins). The MCS Next signals advance the Scaler to the next bin (connected to Scaler input "External Next"). This signal is called "Load Next Event" (LNE). The continuous operation of the frontend depends on the Scaler receiving the correct number of LNE i.e. MCS Next pulses. If too few are received, the PPG cycle will not be restarted, and the DAQ will appear to grind to a halt. If too many, the PPG will continue to cycle, but the data will be no good (overlapping cycles). The scaler counts the number of LNE pulses it receives, and this number can be read via the acquisition count register.

The frontend program polls the acquisition count register. When this number reaches the expected number of bins, the PPG cycle is complete, and the frontend goes into its end-of-cycle routine, reads out the final data from the scaler(s) and processes the data. It then restarts the PPG for the next cycle (single channel mode) or waits for an external start (dual channel mode).