BNMR: frontend: Difference between revisions

From DaqWiki
Jump to navigation Jump to search
en>Suz
No edit summary
No edit summary
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Pagelinks}}
{{Pagelinks}}
== Links ==
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
* [[BNMR]]
* [[BNMR: Midas Host|Midas Host (isdaq01)]]
* [[BNMR: Experimental Modes|Experimental Modes]]
* [[BNMR: Getting Started|Getting Started]]
</div>


== Introduction ==
== Introduction ==
The [https://midas.triumf.ca/MidasWiki/index.php/Frontend_Operation frontend task] (MIDAS clients ''febnqr_vmic'' or ''febnmr_vmic'') runs on the VMIC frontend computer (''lxbnmr'' or ''lxbnqr''), located in the VME crate. The VMIC is a 32-bit computer running linux. It has access to the same disk(s) as the [[BNMR: Midas Host|Midas Host]].  
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 MIDAS libraries. 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 identical for the two experiments  {{bnmqr|join=and}}. Differences are handled with "ifdef" statements. Its purpose is to initialize, set up and read out the DAQ 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.


When the frontend task is started, it performs initial initialization of the DAQ hardware. At begin-of-run, it loads the run parameters into the hardware modules (scaler(s),PSM),  and loads the PPG control code (a loadfile previously written by client [[BNMR rf_config|rf_config]]), into the PPG.
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.
It sets the DAQ hardware into acquisition mode, sets the first value of the sweep (if required), and sets the helicity. It then starts the first PPG cycle by starting the PPG.
While the PPG cycle is running, it checks for Scaler half-full, reads out the data from the scaler(s) 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.
== Frontend operation ==


== Polling in the frontend ==
=== Reading data from the ODB ===
When running the PPG cycle, the frontend program polls the SIS3801 Scaler to see if its internal data buffer needs reading out (looks for scaler half-full), in which case it reads the scaler data into a buffer. The  {{bnmqr|join=and}} experiments do not usually produce enough scaler data during the cycle to require reading out before the end of the PPG cycle.  
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.


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. If too many, the PPG will continue to cycle, but the data will be no good. The scaler counts the number of LNE pulses it receives, and the number is available to be read via the acquisition count register.
The frontend uses ODB using ''db_get_record()'' to access areas of the ODB where numerous keys are needed.  


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).
=== 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 [[BNMR:_Software_overview#Run_transitions|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 [[BNMR:_RF_calculator|RF calculator]]
* Call the [[BNMR:_PPG_compiler|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.


Source Code
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).
The source code is stored in the DAQ CVS repository under the directory "bnmr".
Local copies are checked out into the main DAQ  directories for BNMR and BNQR, i.e. /home/<beamline>/online/<beamline> where <beamline> is either bnmr or bnqr.
The main program is febnmr.c, which includes bnmr.init.c  and various header files. Other code needed includes bnmr_epics.c .


=== Run stop logic ===


There are several ways to configure when a run should stop:


== To Build the frontend code ==
* Manually (by clicking the "Stop" or "Stop after this loop" buttons on the status page.
The frontend code is located in directory  {{Filepath|path=/home/<beamline>/online/<beamline>}} where <beamline> is bnmr or bnqr (see [[BNMR#Nomenclature]]). 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.
* After a certain amount of time (as part of an autorun plan).
The  {{File|name=Makefile}} in the main DAQ directory is identical for {{bnmqr|join=and}} experiments. The environment variable [[BNMR: Midas Host#Environment Variables|BEAMLINE]] is used to set up the definitions automatically to build the frontend for either {{bnmqr|join=or}} experiments.
* After a certain number of scan loops have completed (for TI runs). Specify number of loops before the run, or edit during the run. 0 means no limit.
* After a certain number of counts have been acquired (for TD runs). We use the total of B+F counts for BNMR, and L+R counts for BNQR. Specify number of counts before the run, or edit during the run. 0 means no limit.


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
=== Error checking ===
cd  /home/<beamline>/online/<beamline>
make


The task will be called  {{File|name=febn[mq]r_vmic.exe}} (see  [[BNMR#Nomenclature]]).
If the frontend encounters an '''unrecoverable''' error, it will stop the run (or crash if things went really badly). Examples of unrecoverable errors include invalid ODB values, lost connections to other servers etc. Details will generally be reported on the Messages page.


To completely rebuild the frontend task, execute "make clean" before rebuilding.
The status page shows how often various '''recoverable''' errors have been encountered during a run:
* <b>Constant time</b> - if running in "constant time" mode (where there is a constant time between PPG cycles), this is the number of times the DAQ had not finished reading out data / setting up the next cycle by the time the next cycle was due to start. The DAQ will stop the PPG, step back a value in the scan, then try again. If this happens often, consider increasing the "DAQ service time" PPG variable.
* <b>Flipping</b> - if flipping helicity (or flipping between sample/reference for BNQR), this reports how many times the observed state didn't match the expected state at the end of the cycle. The DAQ will try again. (If the DAQ fails to set the correct state at the start of a cycle it will stop the run; the "flipping" error is how often the state unexpectedly changed during a cycle). If this happens often, it suggests that something else is controlling the same device in addition to the DAQ software.
* <b>Empty bin</b> - the scalers are configured to count pulses from a 25MHz clock on one if their channels. If any of the time bins on this channel report 0 counts, it indicates a failure of either the scaler hardware/firmware or the DAQ software. The DAQ will ignore the data from this cycle and try again. If this happens often, a DAQ expert should investigate the problem.
* <b>EPICS unstable</b> - if scanning an EPICS variable (e.g. the Rb cell voltage), whether the measured value was unstable during a cycle. If so, the DAQ will ignore the data from this cycle and try again. There are custom tolerance functions defined for the Rb cell, laser and field that should suffice. If the tolerance check fails often, it can be overriden on the "EPICS definitions" page (Settings page > Miscellaneous > EPICS device > Define more devices here).
* <b>NB out-of-tolerance</b> - the total counts on the neutral beam monitors for each cycle are recorded, and compared to both a "reference" value (generally the first cycle of the run) and the total from the previous cycle. If the current value is far from the reference or previous values, it indicates that the beam intensity is unstable. The DAQ will ignore the data from this cycle and try again. The tolerances (in %) can be configured in the ODB (Status page > Neutral beam > Set tolerances). The reference values can be updated by clicking the "Re-ref" buttons on the status page.</li>
* <b>RF trip</b> - power to the PSM (RF generator) has tripped. The DAQ will ignore the data from this cycle, unset the trip, and try again. If it happens often, a DAQ hardware expert should investigate the problem.


    
    
[[Category:BNMR]]
[[Category:BNMR]] [[Category:Frontend]] [[Category:VMIC]]

Latest revision as of 14:41, 6 November 2023

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

Run stop logic

There are several ways to configure when a run should stop:

  • Manually (by clicking the "Stop" or "Stop after this loop" buttons on the status page.
  • After a certain amount of time (as part of an autorun plan).
  • After a certain number of scan loops have completed (for TI runs). Specify number of loops before the run, or edit during the run. 0 means no limit.
  • After a certain number of counts have been acquired (for TD runs). We use the total of B+F counts for BNMR, and L+R counts for BNQR. Specify number of counts before the run, or edit during the run. 0 means no limit.

Error checking

If the frontend encounters an unrecoverable error, it will stop the run (or crash if things went really badly). Examples of unrecoverable errors include invalid ODB values, lost connections to other servers etc. Details will generally be reported on the Messages page.

The status page shows how often various recoverable errors have been encountered during a run:

  • Constant time - if running in "constant time" mode (where there is a constant time between PPG cycles), this is the number of times the DAQ had not finished reading out data / setting up the next cycle by the time the next cycle was due to start. The DAQ will stop the PPG, step back a value in the scan, then try again. If this happens often, consider increasing the "DAQ service time" PPG variable.
  • Flipping - if flipping helicity (or flipping between sample/reference for BNQR), this reports how many times the observed state didn't match the expected state at the end of the cycle. The DAQ will try again. (If the DAQ fails to set the correct state at the start of a cycle it will stop the run; the "flipping" error is how often the state unexpectedly changed during a cycle). If this happens often, it suggests that something else is controlling the same device in addition to the DAQ software.
  • Empty bin - the scalers are configured to count pulses from a 25MHz clock on one if their channels. If any of the time bins on this channel report 0 counts, it indicates a failure of either the scaler hardware/firmware or the DAQ software. The DAQ will ignore the data from this cycle and try again. If this happens often, a DAQ expert should investigate the problem.
  • EPICS unstable - if scanning an EPICS variable (e.g. the Rb cell voltage), whether the measured value was unstable during a cycle. If so, the DAQ will ignore the data from this cycle and try again. There are custom tolerance functions defined for the Rb cell, laser and field that should suffice. If the tolerance check fails often, it can be overriden on the "EPICS definitions" page (Settings page > Miscellaneous > EPICS device > Define more devices here).
  • NB out-of-tolerance - the total counts on the neutral beam monitors for each cycle are recorded, and compared to both a "reference" value (generally the first cycle of the run) and the total from the previous cycle. If the current value is far from the reference or previous values, it indicates that the beam intensity is unstable. The DAQ will ignore the data from this cycle and try again. The tolerances (in %) can be configured in the ODB (Status page > Neutral beam > Set tolerances). The reference values can be updated by clicking the "Re-ref" buttons on the status page.
  • RF trip - power to the PSM (RF generator) has tripped. The DAQ will ignore the data from this cycle, unset the trip, and try again. If it happens often, a DAQ hardware expert should investigate the problem.
Retrieved from "https://daq00.triumf.ca/DaqWiki/index.php?title=BNMR:_frontend&oldid=7412"