BNMR: frontend: Difference between revisions

From DaqWiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 1: Line 1:
{{Pagelinks}}
{{Pagelinks}}
== Links ==
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
* [[BNMR]]
* [[BNMR: Experimental Setup|Midas Host (isdaq01)]]
* [[BNMR: Experimental Modes|Experimental Modes]]
* [[BNMR: Getting Started|Getting Started]]
* [[BNMR: Experimental Setup#Environment Variables]]
</div>


== Introduction ==
== Introduction ==
The frontend task (''febnqr_vmic'' or ''febnmr_vmic'' runs on the VMIC frontend computer located in the VME crate (''lxbnqr'' or ''lxbnmr''). The VMIC is a 32-bit computer running linux. It has access to the same disk(s) as the [[BNMR: Experimental Setup|Midas Host]]. It also has access to the other VME DAQ Modules in the VME crate.
The frontend program ({{Client|name=febnmr_32bit.exe}} or {{Client|name=febnqr_32bit.exe}}) is at the heart of the {{bnmqr|join=and}} 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 [[BNMR: Experimental Setup|Midas Host]] and can directly access other VME modules in the VME crate.


The frontend task is a [https://midas.triumf.ca/MidasWiki/index.php/Frontend_Operation MIDAS frontend task], and the  frontend user code is linked with the MIDAS system frontend code and the MIDAS library. The frontend user code discussed here was written specifically for the  {{bnmqr|join=and}} experiments. Its underlying structure is that of the MIDAS example whose features are described in [https://midas.triumf.ca/MidasWiki/index.php/Frontend_user_code Frontend_user_code]. The frontend code is ideally identical for the two experiments  {{bnmqr|join=and}} with differences  handled with "ifdef" statements. Its purpose is to initialize, set up and read out the DAQ [[BNMR#Hardware Components|hardware modules]].
The frontend program is built using the [https://midas.triumf.ca/MidasWiki/index.php/Frontend_Operation MIDAS frontend system] and a core "cycling framework" that is used by several experiments that need to scan things while running PPG cycles.


Recently new modes have been added specific to either bnqr or bnqr so that the frontend code is no longer identical. The intention is that the code will again be made identical where possible.
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) <code>febnmr.cxx</code> and <code>febnqr.cxx</code> files, where the former creates a <code>PSM3</code> object while the latter creates a <code>PSM1</code> object, for example.


== Frontend operation ==
== Frontend operation ==


=== Reading data from the ODB ===
=== 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.
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 [[BNMR:_Histograms_and_Scalers|histogramming configuration]] which is very complex and doesn't change often.


Reading data from the ODB is simplified because '''the frontend code is linked with the MIDAS header file experim.h''' which maps areas of the ODB structure to a C structure. This file must be re-created if the structure of the ODB is changed e.g. by adding or removing keys to the mapped subdirectories, or the structure will no longer match that of the ODB. Keys under /Equipment/Settings are among those mapped - see MIDAS experim.h. Linking with experiment.h allows easier access to the large number of keys required by the frontend. The frontend code checks that the current size of the structure in the ODB and in experim.h match. If not, the structure
The frontend uses ODB using ''db_get_record()'' to access areas of the ODB where numerous keys are needed.  
is recreated in the ODB according to the structure in experim.h. Once the structure size is checked, call(s) of the MIDAS ''db_get_record()'' function will populate the C structure in the frontend with the current values from the ODB.  The MIDAS ''set_record_function()'' can be used to write the structure back to the ODB, if values have been updated. 
 
The frontend uses ODB using ''db_get_record()'' to access areas of the ODB where numerous keys are needed. It also uses the MIDAS functions ''db_get_value'' and ''db_set_value'' to read and write individual keys where the c structure is not mapped.  


=== Initialize hardware ===
=== 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).
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. The drivers are written such that they also double as
Access to the functions of the VME Modules is provided by a software driver (program) specific to each module.
a debug tool (see [[BNMR: Hardware Debugging#hardware debugging]].
 
 
== Begin-of-run ==
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  {{bnmqr|join=and}} experiments, at begin-of-run, rf_config is required to check the input parameters, generate and write the '''ppg load file''' and any required PSM load files. This must be completed before the frontend attempts to load these files.
 
This is accomplished in MIDAS by the use of transition sequence numbers. rf_config and the frontend both register to the START transition, but rf_config is registered with a lower transition sequence number, so it runs a "prestart" routine before the frontend runs its "begin-of-run" routine.
See [MIDAS doc #Run States and Transitions] for details.
 
At the begin-of-run transition, the function begin_of_run() is called. This function determines the Type of run (Type 1 (cf I-MUSR) or Type 2 (cf TD-MUSR)).
* determine run type
* determine beam control (single/dual channel)
** check EPICS switches
* set initial helicity state
* clear scaler modules
* setup scan (Type 1)
** setup PSM (frequency scan) or
** CAMP (camp scan) or
** EPICS (epics scan)
* or setup scan (Type 2)
** setup PSM module
* load PPG loadfile
* initialize scaler and histogram structures
* set beam control (continuous/pulsed)
* start cycle (calls cycle_start() )
* enable PPG external trigger for dual_channel mode
 


== cycle_start ==
=== Begin-of-run ===
The cycle_start() routine
* check if cycle is being skipped


* if Type 1
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 [[BNMR:_Software_overview#Run_transitions|the software overview page]] for the rationale.
**  clear histograms
**  increment the scan parameter (PSM/CAMP/EPICS)
* if Type 2
**  flip helicity if needed
* clear REAL cycle scalers
* clear scaler sums (REAL scalers only)
* clear gbl_bin_count
* rereference thresholds if requested
* clear scaler FIFO
* clear and arm scalers
* reset PSM
* start PPG (single channel mode only)


In the first transition, the frontend:
* Ensures that the various ODB structures match what we expect
* Reads the settings that were computed by the [[BNMR:_RF_calculator|RF calculator]]
* 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 ===
 
 
While the PPG cycle is running, it checks for Scaler half-full, reading out the data from the scaler internal buffer when needed. At the end of the cycle, it processes the data, storing it as histograms (Type 2 (TD)), calculates scaler sums and adds data to the cumulative scalers.  It sends out data banks (Type 1 only), scaler and information banks at the end of each cycle. It flips the helicity, increments the sweep device (if needed) and restarts the PPG for the next cycle.  For Type 2 runs, it sends out the histogram data banks periodically.
 
At end-of-run, the frontend program sends out the final data and disables the DAQ hardware.
 
;Note: the above describes the situation in [[BNMR Dual Channel Mode#Single Channel Mode|single channel mode]]. In [[BNMR Dual Channel Mode|dual channel mode]] each cycle is started by an external signal to the  PPG which occurs when the beam is switched between channels).
 
 
 
== Polling in the frontend for end-of-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 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.


Line 95: Line 39:




== To Build the frontend code ==
The frontend code is located in the experiment directory given by the Environment Variable [[BNMR: Experimental Setup#Environment Variables|MIDAS_EXPTAB]]. This directory is  {{Filepath|path=/home/<beamline>/online/[[BNMR#Nomenclature|<beamline>]]}}. The main frontend user code is called  {{File|name=febnqr_vmic.c}}. For bnmr, a softlink  {{File|name=febnmr_vmic.c}} points to this code.
The  {{File|name=Makefile}} in the main DAQ directory is identical for  {{bnmqr|join=and}} experiments. The environment variable [[BNMR: Experimental Setup#Environment Variables|BEAMLINE]] is used to set up the definitions automatically to build the frontend for either {{bnmqr|join=or}} experiments.
The code runs on and must be built on the 32-bit VMIC computer. To build the code, log onto lxbnmr or lxbnqr as user ''bnmr'' or user ''bnqr'' respectively. Then type
cd  /home/<beamline>/online/<beamline>
make
The task will be called  {{File|name=febn[mq]r_vmic.exe}} (see  [[BNMR#Nomenclature]]).
To completely rebuild the frontend task,  execute "make clean" before rebuilding.
    
    
[[Category:BNMR]] [[Category:Frontend]] [[Category:VMIC]]
[[Category:BNMR]] [[Category:Frontend]] [[Category:VMIC]]

Revision as of 13:43, 29 April 2022

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
  • 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).

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