BNMR: Dual Channel Mode: Difference between revisions

From DaqWiki
Jump to navigation Jump to search
en>Suz
No edit summary
 
(11 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: Experimental Modes|Experimental Modes]]
* [[BNMR: Getting Started|Getting Started]]
</div>


==Introduction ==
==Introduction ==
When the beam is switched alternately between the two experiments  {{bnmqr|join=and}}, the experiments are running in '''dual channel mode'''. When no switching takes place, and the beam is sent to either {{bnmr}} or {{bnqr}} experiment, the experiment is running in '''single channel mode'''.  Switching the beam alternately between the two experiments is done by the Controls Group using the [[#EPICS switch]]. Currently, only Type 2 (TD) experiments can be run in dual channel mode. When running in dual channel mode, both the DAQ systems {{bnmqr|join=and}} may be running and taking data, therefore dual channel mode makes better use of the beam time.  In single channel mode, only one DAQ system  ({{bnmqr|join=or}}) is active (see [[#Single channel mode]]).  
; dual channel mode
: is when the '''beam is switched alternately''' between the two experiments  <span style="color:#7b68ee; font-style=italic">bnmr </span> and <span style="color:#20b2aa; font-style=italic">bnqr</span> .
 
; single channel mode
: is when '''no switching of the beam''' takes place. and the beam is sent to '''one''' of the two experiments (<span style="color:#7b68ee; font-style=italic">bnmr </span> or <span style="color:#20b2aa; font-style=italic">bnqr</span>), that experiment is said to be running in [[#Single Channel Mode]].   
 
Switching the beam alternately between the two experiments is done by the Controls Group using the [[#EPICS switch]].
 
Currently, only Type 2 (TD) experiments can be run in dual channel mode. When running in dual channel mode, both the DAQ systems {{bnmqr|join=and}} may be running and taking data, therefore dual channel mode makes better use of the beam time.
 
In [[#Single channel mode]], only one DAQ system  ({{bnmqr|join=or}}) is active.  
    
    
== EPICS switch ==
== EPICS switch ==
The EPICS parameter that controls switching is called "BNMR:BNQRSW:ENBSWITCHING". Switching must be enabled for dual channel mode, and disabled for single channel mode. During the beam period for  {{bnmqr|join=/}}, the experimenters telephone the controls group and ask them set this switch as required to run in dual channel or single channel mode. Figure 1 shows the switching set for Dual channel mode (scheduled switching enabled, manual switching disabled).  This page can be found on the EPICS page display by clicking on the button "beam line switch" on the page "ILE2A3/BNMR OPTICS".
The EPICS parameter that controls switching is called <code>BNMR:BNQRSW:ENBSWITCHING</code>. Switching must be
* '''enabled''' for dual channel mode
* '''disabled''' for single channel mode  
 
Only the Controls Group can change this switch. The experimenters telephone the Control Room and ask them set this switch as required to run in dual channel or single channel mode. Figure 1 shows the switching set for Dual channel mode (scheduled switching enabled, manual switching disabled).  This page can be found on the EPICS page display by clicking "LE Exp." > "ILE2A3 Optics/BNMR" > "beam line switch" button.
 
It is important to match the timing of the beam switch (BNMR Period/Delay  and BNQR Period/Delay) to the PPG Cycle of each experiment (see [[#Timing]]).
 
<gallery widths=450px heights=450px>
Image:Bnmr dual channel beamon.png|Dual channel mode enabled. {{bnmr}} is eligible for beam and is currently requesting it.
Image:Bnmr dual channel beamoff.png|Dual channel mode enabled. {{bnqr}} is eligible for beam but is not currently requesting it.
</gallery>


[[Image:bnmr_bnqr_switching_en.png|frame|center|Figure 1: EPICS BNMR-BNQR Switching set for dual channel mode]]
Experimenters must ensure that the DAQ ODB parameter {{Odbpath|path=/Scanning/BNXRCustomCycleLogic/Settings/Enable dual channel mode}} (called <code>Enable dual channel mode</code> on the [[BNMR: Custom Status page|custom status page]]) is set appropriately.


Experimenters must also ensure that the DAQ ODB parameter {{Odbpath|path=Enable dual channel mode}} is set to the appropriate value. The ODB parameter  {{Odbpath|path=enable epics switch checks}} (on the custom status page) should also be set true (except for testing). This causes rf_config to compare the EPICS switch position with the value of {{Odbpath|path=Enable dual channel mode}}. If the switch is not set correctly, rf_config prevents the run from starting.
== Frontend sanity-checks ==
 
Unless performing tests, the ODB parameter {{Odbpath|path=/Scanning/BNXRCustomCycleLogic/Settings/Enable EPICS access checks}} (called <code>Check switching in run start</code> on the [[BNMR: Custom Status page|custom status page]]) should be set true. This causes the [[BNMR: frontend|frontend]] to validate the beam switching setup:
* Ensures the DAQ {{Odbpath|path=Enable dual channel mode}} flag must match the EPICS <code>BNMR:BNQRSW:ENBSWITCHING</code> flag.
* Ensures the EPICS <code>ILE2:BIAS15:VOL.ASG</code> value must be set to <code>expbnmr</code> (for both {{bnmqr|join=and}}).
* Ensures the EPICS <code>BNMR:BNQRSW:SCHEDULE.SCAN</code> value is set to <code>.1 second</code>. If this value is <code>Disabled</code>, then switching never happens and the DAQ does not run correctly.


== Helicity ==
== Helicity ==
The PPG requests the [[BNMR: Helicity|helicity]] it requires for the next cycle by a signal from the PPG Output "Pol" connected to the [[BNMR: Helicity#Helicity Switch Box|helicity switch box]]. In Single Channel mode, the helicity is immediately set to this value (UP/DOWN). In Dual Channel mode, the helicity state is not changed until that channel is active (see [[#Timing]]).
The PPG requests the [[BNMR: Helicity|helicity]] it requires for the next cycle by a signal from the PPG Output "Pol" connected to the [[BNMR: Helicity#Helicity Switch Box|helicity switch box]]. In Single Channel mode, the helicity is immediately set to this value (UP/DOWN). In Dual Channel mode, the helicity state is not changed until that channel is active (see [[#Timing]]).


==Timing==
== Starting the PPG ==
Historically the PPG was started by an "external trigger" signal from the kicker. When an experiment ({{bnmqr|join=or}}) was eligible to request beam, a signal was sent from the kicker to the PPG. This signal stayed high for the entire time the experiment was allowed to request beam, and the PPG would start its program as soon as it detected the level was high. Note the PPG only cared about the level of the signal; it did not detect a transition, just the level. If {{bnmr}} was eligible for beam for 10s but ran a program that only lasted 7s, the program would start again with 3s of beam remaining! As noted in the [[#Timing]] section of this page, it is very important to match the switching schedule to the length of PPG programs being run!
 
In summer 2022 the PPGs started having issues responding to the external trigger signal. The problem mostly affected {{bnqr}}, but did also appear on {{bnmr}} one time. The PPG registers would show that it was in "external trigger" mode, would show that it was detecting the trigger signal changing between high/low, but would not start the program when it was supposed to! The only solution was to reboot the VME crate, which is both tedious and sometimes problematic if experimenters are doing careful instrument control via CAMP, as the PPG and CAMP server are both in the same crate. Note it was still possible to start the program via a software signal, just not via hardware.
 
For this reason, a new option was added to the frontend code to allow it start the program via software. It checks the state of the <code>BNMR:BNQRSW:STATBNMRENB</code> or <code>BNMR:BNQRSW:STATBNQRENB</code> PVs to see whether it is "off" or "on". When it is "on" (and the PPG isn't already running), it starts the PPG via a software signal. This appears to be more robust, but does involve a lot of polling of EPICS to ensure we start the PPG program as soon as possible after we become eligible for beam.
 
The [[BNMR:_RF_calculator|RF calculator]] program has functionality to force which behaviour is used (hardware or software start). The choice is currently hard-coded with <code>force_epics_for_dual_channel = True</code> in <code>bnxr_common.rf_calculator_fe.RFCalculatorEquipment.check_mode_params()</code>, which is called at the start of each run. This flag then sets the ODB keys:
* {{Odbpath|path=/Scanning/BNXRCustomCycleLogic/Settings/Dual channel start on beam enb}} to true, to ensure the frontend will start the PPG
* {{Odbpath|path=/Equipment/PPGCompiler/Settings/Use external trigger}} to false, to ensure the PPG gets configured to not respond to the external trigger (we don't want the software and hardware methods to compete with each other)
 
== Timing ==
Figure 2 shows a timing diagram for dual channel mode.
Figure 2 shows a timing diagram for dual channel mode.
[[Image:dual_channel_timing.gif|frame|center|Figure 2: Timing diagram for Dual Channel mode]]
[[Image:dual_channel_timing.gif|frame|center|Figure 2: Timing diagram for Dual Channel mode]]


In dual channel mode, the PPG is started by an external signal (PPG Start/Beam Ready) that occurs at the end of the BNMR or BNQR Delay (Figure 2).  Usually the PPG cycle is divided into 3 regions: prebeam, beam on , and post-beam. Once the PPG cycle is started, the PPG Output "Beam On" controls when and how long the beam is on.
In dual channel mode, the PPG Cycle is started by an external signal (PPG Start/Beam Ready) that occurs at the end of the BNMR or BNQR Delay (Figure 2).  Usually the PPG cycle is divided into 3 regions: prebeam, beam on, and post-beam. Once the PPG cycle is started, the PPG Output "Beam On" controls when and how long the beam is on. The timing of these signals is controlled by parameters set for each PPG timing scheme.
    
    
The experimenter must be careful to set the timing of the BNMR and BNQR cycles such that the Beam On period has finished before the beam is switched to the other channel. The post-beam period of one channel generally overlaps part of the cycle of the other channel. This timing is controlled by the EPICS parameters ''BNMR Period (s), BNQR Period (s), BNMR Delay (s), BNQR Delay (s)''. These are available on the EPICS Kicker Control/BNMR-BNQR Switching page (Figure 1). The BNMR and BNQR Delays must be set to give the Helicity time to change. They are equivalent to the ODB parameter {{Odbpath|path=Helicity Sleep time}} in Single Channel mode. This parameter is ignored in dual channel mode.
The experimenter must be careful to set the timing of the BNMR and BNQR cycles such that the Beam On period of the PPG Cycle has finished before the beam is switched to the other channel. The post-beam period of one channel generally overlaps part of the cycle of the other channel. This timing is controlled by the EPICS parameters ''BNMR Period (s), BNQR Period (s), BNMR Delay (s), BNQR Delay (s)''. These are available on the EPICS Kicker Control/BNMR-BNQR Switching page (Figure 1). The BNMR and BNQR Delays must be set to give the Helicity time to change. They are equivalent to the ODB parameter {{Odbpath|path=Helicity Sleep time}} in Single Channel mode. This parameter is ignored in dual channel mode.


== Single Channel Mode ==
In '''single channel mode''', the beam is directed to '''one''' of the channels ({{bnmqr|join=or}}). The [[#EPICS switch]] and the DAQ ODB parameter {{Odbpath|path=/Scanning/BNXRCustomCycleLogic/Settings/Dual channel mode}} must both be set to off/false/disabled.


== Single Channel Mode ==
'''Only the DAQ system for the channel with the beam should be running.''' The other DAQ system must not be run (except by "experts" for [[#Testing]] under certain conditions). This is because there is currently NO CHECK against both DAQ systems running simultaneously in single channel mode, and both trying to flip the helicity. This would ruin the data for the active channel with the beam.
In single channel mode, the beam is switched to '''one''' of the channels ({{bnmqr|join=or}}). Only that DAQ system is active.  The other DAQ system must not be run (except by "experts" for [[#Testing]] under certain conditions). This is because there is NO CHECK against both DAQ systems running simultaneously in single channel mode, and both trying to flip the helicity. This would ruin the data for the active channel with the beam.  
 
In single channel mode, the PPG Cycle is started by a software command given by the  [[BNMR: frontend|frontend]].  


=== Testing ===
== Testing ==
Both DAQ systems may be run in single channel mode simultaneously for testing under certain conditions. Outside the beam period, it is sufficient to disable helicity flipping on one of the DAQ systems, so that for example BNMR flips the helicity, and BNQR does not. In that case, the check on helicity flipping  {{Odbpath|path=enable all hel checks}} may be disabled on BNQR.  
Both DAQ systems may be run in single channel mode simultaneously for testing under certain conditions. Outside the beam period, it is sufficient to disable helicity flipping on one of the DAQ systems, so that for example BNMR flips the helicity, and BNQR does not. In that case, the [[BNMR: Helicity#EPICS Helicity checks|Helicity check]] must be disabled on BNQR.  


Alternatively, and especially during the beam period, the helicity signal from the PPG should be disconnected so that the second DAQ cannot interfere with the data taking run. In this case, helicity flipping can be enabled on the disconnected system, but the check on helicity flipping  {{Odbpath|path=enable all hel checks}} must be disabled.
Alternatively, and especially during the beam period, the beam on/off and helicity outputs from the PPG on the test system should be disconnected so that the test DAQ cannot interfere with the data taking run. In this case, helicity flipping can be enabled on the disconnected system (but helicity is not actually flipped), but [[BNMR: Helicity#EPICS Helicity checks|Helicity check]] must be disabled.


[[Category:BNMR]]
[[Category:BNMR]] [[Category:Dual Channel Mode]] [[Category:Single Channel Mode]]

Latest revision as of 12:13, 18 July 2022

Introduction

dual channel mode
is when the beam is switched alternately between the two experiments bnmr and bnqr .
single channel mode
is when no switching of the beam takes place. and the beam is sent to one of the two experiments (bnmr or bnqr), that experiment is said to be running in #Single Channel Mode.

Switching the beam alternately between the two experiments is done by the Controls Group using the #EPICS switch.

Currently, only Type 2 (TD) experiments can be run in dual channel mode. When running in dual channel mode, both the DAQ systems bnmr and bnqr may be running and taking data, therefore dual channel mode makes better use of the beam time.

In #Single channel mode, only one DAQ system (bnmr or bnqr) is active.

EPICS switch

The EPICS parameter that controls switching is called BNMR:BNQRSW:ENBSWITCHING. Switching must be

  • enabled for dual channel mode
  • disabled for single channel mode

Only the Controls Group can change this switch. The experimenters telephone the Control Room and ask them set this switch as required to run in dual channel or single channel mode. Figure 1 shows the switching set for Dual channel mode (scheduled switching enabled, manual switching disabled). This page can be found on the EPICS page display by clicking "LE Exp." > "ILE2A3 Optics/BNMR" > "beam line switch" button.

It is important to match the timing of the beam switch (BNMR Period/Delay and BNQR Period/Delay) to the PPG Cycle of each experiment (see #Timing).

Experimenters must ensure that the DAQ ODB parameter /Scanning/BNXRCustomCycleLogic/Settings/Enable dual channel mode (called Enable dual channel mode on the custom status page) is set appropriately.

Frontend sanity-checks

Unless performing tests, the ODB parameter /Scanning/BNXRCustomCycleLogic/Settings/Enable EPICS access checks (called Check switching in run start on the custom status page) should be set true. This causes the frontend to validate the beam switching setup:

  • Ensures the DAQ Enable dual channel mode flag must match the EPICS BNMR:BNQRSW:ENBSWITCHING flag.
  • Ensures the EPICS ILE2:BIAS15:VOL.ASG value must be set to expbnmr (for both bnmr and bnqr).
  • Ensures the EPICS BNMR:BNQRSW:SCHEDULE.SCAN value is set to .1 second. If this value is Disabled, then switching never happens and the DAQ does not run correctly.

Helicity

The PPG requests the helicity it requires for the next cycle by a signal from the PPG Output "Pol" connected to the helicity switch box. In Single Channel mode, the helicity is immediately set to this value (UP/DOWN). In Dual Channel mode, the helicity state is not changed until that channel is active (see #Timing).

Starting the PPG

Historically the PPG was started by an "external trigger" signal from the kicker. When an experiment (bnmr or bnqr) was eligible to request beam, a signal was sent from the kicker to the PPG. This signal stayed high for the entire time the experiment was allowed to request beam, and the PPG would start its program as soon as it detected the level was high. Note the PPG only cared about the level of the signal; it did not detect a transition, just the level. If bnmr was eligible for beam for 10s but ran a program that only lasted 7s, the program would start again with 3s of beam remaining! As noted in the #Timing section of this page, it is very important to match the switching schedule to the length of PPG programs being run!

In summer 2022 the PPGs started having issues responding to the external trigger signal. The problem mostly affected bnqr, but did also appear on bnmr one time. The PPG registers would show that it was in "external trigger" mode, would show that it was detecting the trigger signal changing between high/low, but would not start the program when it was supposed to! The only solution was to reboot the VME crate, which is both tedious and sometimes problematic if experimenters are doing careful instrument control via CAMP, as the PPG and CAMP server are both in the same crate. Note it was still possible to start the program via a software signal, just not via hardware.

For this reason, a new option was added to the frontend code to allow it start the program via software. It checks the state of the BNMR:BNQRSW:STATBNMRENB or BNMR:BNQRSW:STATBNQRENB PVs to see whether it is "off" or "on". When it is "on" (and the PPG isn't already running), it starts the PPG via a software signal. This appears to be more robust, but does involve a lot of polling of EPICS to ensure we start the PPG program as soon as possible after we become eligible for beam.

The RF calculator program has functionality to force which behaviour is used (hardware or software start). The choice is currently hard-coded with force_epics_for_dual_channel = True in bnxr_common.rf_calculator_fe.RFCalculatorEquipment.check_mode_params(), which is called at the start of each run. This flag then sets the ODB keys:

  • /Scanning/BNXRCustomCycleLogic/Settings/Dual channel start on beam enb to true, to ensure the frontend will start the PPG
  • /Equipment/PPGCompiler/Settings/Use external trigger to false, to ensure the PPG gets configured to not respond to the external trigger (we don't want the software and hardware methods to compete with each other)

Timing

Figure 2 shows a timing diagram for dual channel mode.

Figure 2: Timing diagram for Dual Channel mode

In dual channel mode, the PPG Cycle is started by an external signal (PPG Start/Beam Ready) that occurs at the end of the BNMR or BNQR Delay (Figure 2). Usually the PPG cycle is divided into 3 regions: prebeam, beam on, and post-beam. Once the PPG cycle is started, the PPG Output "Beam On" controls when and how long the beam is on. The timing of these signals is controlled by parameters set for each PPG timing scheme.

The experimenter must be careful to set the timing of the BNMR and BNQR cycles such that the Beam On period of the PPG Cycle has finished before the beam is switched to the other channel. The post-beam period of one channel generally overlaps part of the cycle of the other channel. This timing is controlled by the EPICS parameters BNMR Period (s), BNQR Period (s), BNMR Delay (s), BNQR Delay (s). These are available on the EPICS Kicker Control/BNMR-BNQR Switching page (Figure 1). The BNMR and BNQR Delays must be set to give the Helicity time to change. They are equivalent to the ODB parameter Helicity Sleep time in Single Channel mode. This parameter is ignored in dual channel mode.

Single Channel Mode

In single channel mode, the beam is directed to one of the channels (bnmr or bnqr). The #EPICS switch and the DAQ ODB parameter /Scanning/BNXRCustomCycleLogic/Settings/Dual channel mode must both be set to off/false/disabled.

Only the DAQ system for the channel with the beam should be running. The other DAQ system must not be run (except by "experts" for #Testing under certain conditions). This is because there is currently NO CHECK against both DAQ systems running simultaneously in single channel mode, and both trying to flip the helicity. This would ruin the data for the active channel with the beam.

In single channel mode, the PPG Cycle is started by a software command given by the frontend.

Testing

Both DAQ systems may be run in single channel mode simultaneously for testing under certain conditions. Outside the beam period, it is sufficient to disable helicity flipping on one of the DAQ systems, so that for example BNMR flips the helicity, and BNQR does not. In that case, the Helicity check must be disabled on BNQR.

Alternatively, and especially during the beam period, the beam on/off and helicity outputs from the PPG on the test system should be disconnected so that the test DAQ cannot interfere with the data taking run. In this case, helicity flipping can be enabled on the disconnected system (but helicity is not actually flipped), but Helicity check must be disabled.