TACTIC

2025-09-17T20:11:41Z

Bsmith:

TACTIC

2025-09-04T21:48:55Z

Bsmith:

2024-10-02T21:27:40Z

Bsmith:

BNMR: Mode changer

2024-10-02T21:24:19Z

Bsmith: /* Resetting the run numbers */

BNMR: Software overview

2024-10-02T20:51:00Z

Bsmith: /* Updating bnmr/bnqr software */

BNMR: Software overview

2024-10-02T20:47:28Z

Bsmith: /* Updating bnmr/bnqr software */

{{Pagelinks}}

== 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 ===
* <code>bin/febnmr_32bit.exe</code> ({{bnmr}} only) - see [[BNMR:_frontend|frontend]]
* <code>bin/febnqr_32bit.exe</code> ({{bnqr}} only) - see [[BNMR:_frontend|frontend]]
* <code>bin/bnxr_logger.exe</code> - see [[BNMR: Data Logging|data logging]]
* <code>bin/logger_cleanup.exe</code> - see [[BNMR: Data Logging#Cleaning_up_if_end-of-run_fails|data logging]]

=== Python "real" programs ===
* <code>bnxr_common/beamtime_monitor.py</code> - see [[BNMR:_Shift_Monitor|shift monitor]]
* <code>bnxr_common/beamtime_to_excel.py</code> - see [[BNMR:_Shift_Monitor|shift monitor]]
* <code>bnxr_common/elog_every_run.py</code> - see [[BNMR:_Scripts#Run_transition_scripts|run transition scripts]]
* <code>bnxr_common/mode_changer.py</code> - see [[BNMR:_Mode_changer|mode changer]]
* <code>bnxr_common/rf_calculator_fe.py</code> - see [[BNMR:_RF_calculator|RF calculator]]
* <code>cycling_framework/ppg/ppg_compiler_fe.py</code> - see [[BNMR:_PPG_compiler|PPG compiler]]
* <code>cycling_framework/run_comments/run_comment_editor.py</code> - see [[BNMR:_Data_Logging#Run_comments|data logging]]

=== Compiled programs for debugging hardware etc ===
* <code>bin/bnmrbeamsim_32bit.exe</code> - see [[BNMR:_Hardware_Debugging|hardware debugging]]
* <code>bin/camp_test.exe</code> and <code>bin/camp_test_32bit.exe</code> - see [[BNMR:_Hardware_Debugging|hardware debugging]]
* <code>bin/epics_test.exe</code> and <code>bin/epics_test_32bit.exe</code> - see [[BNMR:_Hardware_Debugging|hardware debugging]]
* <code>bin/vppg_interactive_32bit.exe</code> - see [[BNMR:_Hardware_Debugging|hardware debugging]]
* <code>bin/sis3801_interactive_32bit.exe</code> ({{bnmr}} only) - see [[BNMR:_Hardware_Debugging|hardware debugging]]
* <code>bin/sis3820_interactive_32bit.exe</code> ({{bnqr}} only) - see [[BNMR:_Hardware_Debugging|hardware debugging]]
* <code>bin/psm_interactive_32bit.exe</code> ({{bnqr}} only) - see [[BNMR:_Hardware_Debugging|hardware debugging]]
* <code>bin/psm3_interactive_32bit.exe</code> ({{bnmr}} only) - see [[BNMR:_Hardware_Debugging|hardware debugging]]

=== Compiled automated tests ===
* <code>bin/unit_tests/*.exe</code> - see [[BNMR:_Tests#Automated_tests_that_don.27t_use_the_ODB|Automated tests that don't use the ODB]]

=== Python test programs ===
* <code>bnxr_common/tests/test_mud_logger.py</code> - see [[BNMR:_Tests#Automated_tests_that_do_use_the_ODB|automated tests that use the ODB]]
* <code>bnxr_common/tests/test_ppg_calc.py</code> - see [[BNMR:_Tests#Automated_tests_that_do_use_the_ODB|automated tests that use the ODB]]
* <code>bnxr_common/tests/test_psm_calc.py</code> - see [[BNMR:_Tests#Automated_tests_that_do_use_the_ODB|automated tests that use the ODB]]
* <code>bnxr_common/tests/diff_mud_file.py</code> - see [[BNMR:_Data_Logging#MUD_files|data logging]]
* <code>bnxr_common/tests/dump_mud_file.py</code> - see [[BNMR:_Data_Logging#MUD_files|data logging]]
* <code>cycling_framework/ppg/tests/test_ppg.py</code>

=== Unused compiled programs ===
* <code>bin/epics_log.exe</code> and <code>bin/epics_log_32bit.exe</code> - EPICS logging is handled by the MUD logger in {{bnmqr|join=/}}
* <code>bin/tppg_interactive_32bit.exe</code> - this version is for TRIUMF PPGs; we use PulseBlaster PPGs

== Repository location ==

The main repository is on BitBucket at [https://bitbucket.org/ttriumfdaq/bnmr/ 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
# or cmake .. -DEXP=BNQR
make install

#
# For updates
#
# on isdaq01
cd build
make install

This will:
* 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 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 {{bnmqr|join=and}} experiments, at begin-of-run, [[BNMR:_RF_calculator|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)
* <span style="color:#999999">100 - run comment editor (no-op)</span>
* <span style="color:#999999">500 - PPG compiler (no-op for {{bnmqr|join=/}} as the frontend calls the PPG compiler by JRPC)</span>
* 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.

[[Category:BNMR]]

BNMR

2024-10-01T22:48:22Z

Bsmith: /* Tasks to be done before each beamtime */

{{Pagelinks}}

== BNMR and BNQR Experiments at TRIUMF ==
This is the main page of the documentation for the Data Acquisition System (DAQ) for the BetaNMR (BNMR) and BetaNQR (BNQR) experiments at TRIUMF

[[:Category:BNMR|Click here for a full list of all the pages in the BNMR documentation]].

== Introduction ==
The Data Acquisition System is based on the [https://midas.triumf.ca/MidasWiki/index.php/Midas_documentation MIDAS] data acquisition package.

There are two separate '''beamlines''', BNMR and BNQR, each with its own experimental setup :

* {{bnmr}} running on the BNMR high-voltage platform
* {{bnqr}} running on the BNQR high-voltage platform

Each experimental setup has its own [[#Hardware Components]] (i.e. a VME crate containing DAQ modules). Each runs as a separate MIDAS experiment named {{bnmqr|join=or}}. DAQ software specific to these experiments (MIDAS clients) run the experiments - see [[#Software Components]]. Experimenters control the experiment using the MIDAS Web Server (mhttpd).

== Beam Control ==
The main TRIUMF EPICS Control System is used to control the beam, which can be switched to either experiment's '''beamline'''. There are two '''Beam Modes''' that the experiments can be run in:

; [[BNMR Dual Channel Mode #Single Channel Mode|single channel mode]]
: where the beam is sent to one beamline (channel) only, either BNMR or BNQR. Only '''one''' of the DAQ systems <span style="color:#7b68ee; font-style=italic">bnmr </span> or <span style="color:#20b2aa; font-style=italic">bnqr</span> is active.
; [[BNMR Dual Channel Mode|dual channel mode]]
: where the beam is switched between the two beamlines (channels) BNMR and BNQR at regular intervals. '''Both''' DAQ systems <span style="color:#7b68ee; font-style=italic">bnmr </span> and <span style="color:#20b2aa; font-style=italic">bnqr</span> are active.

== Experimental modes ==
For both experiments, two types of environment are defined (cf MUSR experiments):

* '''Integral or TI (Type 1)'''
* '''Time Differential or TD (Type 2)'''

There are two separate concepts that use similar naming schemes (e.g. 1f, 20) - the timing of pulses issued by the PPG and the name of the overall experimental mode. The overall mode determines both which timing scheme is run, as well as which hardware is scanned during the run (e.g. RF frequency, Na cell voltage). Multiple experimental modes may use the same PPG timing scheme (e.g. modes 1c, 1d, 1e, 1n use the PPG timing scheme called 1n).

Below is a full list of experimental modes, with the most common ones highlighted in bold. More details about each mode can be found on the [https://isdaq01.triumf.ca:8447/?cmd=custom&page=Modes BNMR mode changer] page and the [https://isdaq01.triumf.ca:8448/?cmd=custom&page=Modes BNQR mode changer] page.

{| class="wikitable"
|+ Experimental modes
|-
! Mode name !! PPG timing !! BNMR? !! BNQR? !! Comment
|-
| '''10''' || 10 || ✓ || ✓ || No RF, nothing scanned
|-
| 1a || 1a || ✓ || ✓ || Scan RF frequency
|-
| 1b || 1b || ✓ || ✓ || Scan RF frequency
|-
| 1c || 1n || ✓ || ✓ || Scan settings on a Camp device
|-
| 1d || 1n || ✓ || ✓ || Scan the laser intensity
|-
| 1e || 1n || || ✓ || Scan the magnetic field strength
|-
| '''1f''' || 1f || ✓ || ✓ || Scan RF frequency
|-
| 1g || 20 || ✓ || ✓ || Scan RF frequency
|-
| 1j || 20 || ✓ || ✓ || Scan settings on a Camp device
|-
| '''1n''' || 1n || ✓ || ✓ || Scan the Rb cell voltage or any other EPICS device
|-
| 1w || 1w || ✓ || || Parametric scan of RF frequencies
|-
| '''1x''' || 1f || ✓ || ✓ || Scan RF frequency with one region at higher resolution
|-
| '''20''' || 20 || ✓ || ✓ || Nothing scanned
|-
| 2a || 2a || ✓ || ✓ || Scan RF frequency
|-
| 2b || 2b || ✓ || ✓ || Scan RF frequency
|-
| 2d || 1b || ✓ || ✓ || RF on, nothing scanned
|-
| 2e || 2e || ✓ || ✓ || Scan RF frequency
|-
| 2f || 2f || ✓ || ✓ || Scan RF frequency
|-
| 2h || 20 || || ✓ || Read alpha channels from scalers
|-
| 2s || 2s || ✓ || || Spin-echo
|-
| 2w || 2w || ✓ || || RF Wurst modulation
|}

Any of these modes may be run in [[#Beam Control|single channel mode]]. Only Type 2 modes may be run in [[#Beam Control|dual channel mode]].

Users change which mode is active using the webpages for each experiment, which in turn interact with the [[#Software_Components|mode changer]] python script.

== Hardware Components ==

DAQ hardware components for each DAQ system (BNMR/BNQR) include the following VME modules:
{| class="wikitable" border=1 cellspacing=3 cellpadding=10
|+ <b><center> Table 2: VME Modules for each Experiment</center></b>
|-
! Module !! Description !! VME Base Address !! BNMR? !! BNQR? !! Manual
|-
| SIS3801 version E || multichannel scaler A || 0x2800 || ✓ || ||rowspan="2" | [[Media:Sis3801_V5_to_VE.pdf|SIS3801 manual (PDF)]]
|-
| SIS3801 version E || multichannel scaler B || 0x1800 || ✓ ||
|-
| SIS3820 || multichannel scaler B || 0x38000000 || || ✓ || [[Media:Sis3820-M-0-001-v186-scaler.pdf|SIS3820 manual (PDF)]]
|-
| PPG (Pulseblaster)|| Pulse Programmer ||0x8000 || ✓ || ✓|| [[Media:PPG.pdf|PPG manual (PDF)]] [[Media:Spincore.pdf|Spincore Pulseblaster (PDF)]]
|-
| PSM || Pol Synthesizer module (RF)|| 0x820000 || || ✓ ||rowspan="3" |[[BNMR:_PSM_(Pol_Synth_Module)|PSM]]
|-
| PSMII || Pol Synthesizer module II (RF) || 0x820000 || ||
|-
| PSMIII|| Pol Synthesizer module III(RF) || 0x820000 || ✓ ||
|-
| NIMIO32 || Input/Output Register ||0x100000 || ✓ || ✓ || [[VME-NIMIO32| NIMIO32]]
|-
| MVME162 || 68040 board (VxWorks) that runs CAMP || || ✓ (bnmrvw) || ✓ (polvw) || <div id=VMIC></div>
|-
| VMIC|| Linux machine in VME crate that runs frontend || || ✓ (lxbnmr) || ✓ (lxbnqr) ||
|}

The connections between the DAQ VME Modules are shown in [[BNMR DAQ Hardware Connections]].

== Software Components ==
The DAQ system is based on the [https://midas.triumf.ca/MidasWiki/index.php/Midas_documentation MIDAS] package. Data acquisition software to run the {{bnmqr|join=and}} experiments has been written to run under MIDAS. This includes the frontend, custom logger etc. This software is mostly common to both experiments, with the differences between each experiment handled by Midas ODB settings (most things) and a compile-time flag (choosing whether to build the febnmr or febnqr frontend).

The experiment is controlled using the MIDAS webserver (mhttpd). Due to the large number of experimental parameters required, Midas custom pages have been written for the experimenters to control and monitor their experiment.

The custom logger (mdarc/midbnmr) saves the data into MUSR MUD format files, and the MUSR CAMP slow control system is used for slow controls. Analysis is done by physica.

The DAQ software components are started by the script ''start-all'' and stopped by the script ''kill-all''. These include '''standard MIDAS utilities''' (e.g. [https://midas.triumf.ca/MidasWiki/index.php/Mhttpd mhttpd], [https://midas.triumf.ca/MidasWiki/index.php/Mlogger mlogger], [https://midas.triumf.ca/MidasWiki/index.php/Mserver mserver]) as well as components specific to the {{bnmqr|join=and}} experiments.

The main DAQ software components specific to the {{bnmqr|join=and}} experiments are shown in the table below. A full ist can be found on the [[BNMR:_Software_overview|software overview page]].

{| class="wikitable" border=1 cellspacing=3 cellpadding=2 style="background-color:#f0f0f5"
|+ <b><center> Table 3: DAQ Software Components</center></b>
|- style="background-color: #e0e0eb;"
! Component !! Host !! Experiment !! Purpose
|-
|-
| colspan=4| ''Midas frontends''
|- style="background-color:floralwhite;"
| [[BNMR: frontend|febnmr_32bit.exe]] || '''lxbnmr''' || bnmr || rowspan=2| the '''frontend''' sets up, reads out hardware modules, sends histograms.<br>The frontend code for both experiments is identical.
|- style="background-color:floralwhite;"
| [[BNMR: frontend|febnqr_32bit.exe]] || '''lxbnqr''' || bnqr
|-
| colspan=4| ''Midas clients - configuration''
|- style="background-color:mintcream"
| [[BNMR:_Mode_changer|mode_changer.py]]|| isdaq01|| both || changes between experimental modes and between real/test runs
|- style="background-color:mintcream"
| [[BNMR:_RF_calculator|rf_calculator_fe.py]]|| isdaq01|| both || generates PPG program based on user-specified ODB parameters; reports calculated quantities in the ODB; sets up links in the ODB that should be stored in MUD files
|- style="background-color:mintcream"
| [[BNMR:_PPG_compiler|ppg_compiler_fe.py]]|| isdaq01|| both || low-level conversion of PPG program to PPG bytecode
|-
| colspan=4| ''Midas clients - logging''
|- style="background-color: mintcream;"
| [[BNMR:_Data_Logging|bnxr_logger.exe]]|| isdaq01|| both|| writes data to MUD files. Reads information from midas banks (for scaler histograms), EPICS, and CAMP
|- style="background-color: mintcream;"
| [[BNMR:_Data_Logging#Cleaning_up_if_end-of-run_fails|logger_cleanup.exe]]|| isdaq01|| both|| cleans up and archives any saved run files that were not properly archived. Run by user occasionally as needed.
|- style="background-color:mintcream"
| [[BNMR:_Data_Logging#Run_comments|run_comment_editor.py ]]|| isdaq01|| both || responds to comments written by user in text box on the status page, saving to disk and/or midas banks
|-
| colspan=4| ''Other''
|- style="background-color:#ffe6e6;"
| [[BNMR: autorun|autorun]]|| isdaq01|| both|| automatic run controller
|- style="background-color:#ffe6e6"
| [[BNMR: Scripts|scripts]]|| isdaq01 || both|| scripts perform important functions e.g. kill-all, start-all. Scripts run at the begin and end of each run send information to the elog etc.
|- style="background-color:#ffe6e6"
| rowspan=2| [[BNMR: CAMP|camp]] || '''bnmrvw''' || bnmr || rowspan=2| MUSR slow control system
|- style="background-color:#ffe6e6"
| '''polvw''' || bnqr
|}

Click the links in the above table for more details of each program.

Not listed above are various [[BNMR:_Tests|automated test]] programs for both the C++ and python programs. There are also some interactive test programs for [[BNMR: Hardware Debugging|debugging hardware issues]].

Note that the DAQ was rewritten in 2020. Details of the rewritten in 2020. Details of the differences between the new DAQ (documented here) and legacy DAQ (documentation removed) can be found on the [[BNMR:_Rewrite_2020|2020 rewrite]] page.

== DAQ Summary ==
;The VMIC front end computer
* runs the [[BNMR: frontend|frontend code]]''' which
** controls PSM,PPG, VMEIO, Scaler modules
** acquires data from SIS MCS (scaler) module(s), builds [[BNMR: Histograms and Scalers|histograms]]
** uses channel access to control EPICS variable(s) (e.g. helicity)
** periodically sends the data out into the data buffer

;The host computer (isdaq01)
* runs all other software components which
** acquire the data from the data buffer
** log the data
** monitor the experiment
** start/stop runs

== Tasks to be done before each beamtime ==

* If this is the first beamtime of the year, [[BNMR:_Mode_changer#Resetting_the_run_numbers|create a new data directory and reset the run numbers]].
* If there have been changes to the code that affect the ODB structure, [[BNMR:_Mode_changer#Handling_changes_to_the_ODB_structure|ensure saved settings have been updated to contain the new variables]].
* Edit the bnmr user's cronjob (using <code>crontab -e</code>) to specify the schedule number and date range to include in the generated Excel file. See the [[BNMR:_Shift_Monitor#beamtime_to_excel.py|supported arguments to beamtime_to_excel.py]] and the [https://mis.triumf.ca/science/schedules.jsf TRIUMF beamtime schedule].
* Try changing between a few common modes (e.g. 20, 1f, 1n, and back to 20) and ensure the run can start (in test mode, not real mode). You may need to disable "switching" checks on the [[BNMR:_Custom_Status_page|status page]] if the beamline is not currently configured for BNMR/BNQR.

== Nomenclature ==
In this document, " ''bnmr'' or ''bnqr'' " may be written as " ''bn['''mq''']r'' "

For example, directories :
: <span style="color:#004d4d; font-weight:normal; font-style:italic ">/home/<span style="font-weight:bold;">bnmr</span>/online/<span style="font-weight:bold;">bnmr</span></span> <span style="color:white">spc</span> and <span style="color:white">spc</span> <span style="color:#004d4d; font-weight:normal; font-style:italic ">/home/<span style="font-weight:bold;">bnqr</span>/online/<span style="font-weight:bold;">bnqr</span></span>

are referred to by '''shortcuts''' such as

<span style="color:white">space</span> {{Filepath|path=/home/bn<span style="font-weight:bold;">[nm]</span>r/online/b<span style="font-weight:bold;">[nm]</span>r}} <span style="color:white">spc</span> and <span style="color:white">spc</span> {{Filepath|path=~/online/b<span style="font-weight:bold;">[nm]</span>r}}

Alternatively, these directories may be written as
<ul>
<li> {{Filepath|path=/home/<experiment>/online/<beamline>}}
<li> {{Filepath|path=/home/<expt>/online/<beamline>}}
<li> {{Filepath|path=~/online/<beamline>}}
</ul>
where {{Filepath|path=<experiment>}} {{Filepath|path=<expt>}} and {{Filepath|path=<beamline>}} are {{bnmqr|join=or}}.

[[Category:BNMR]]

BNMR

2024-10-01T22:45:51Z

Bsmith:

{{Pagelinks}}

== BNMR and BNQR Experiments at TRIUMF ==
This is the main page of the documentation for the Data Acquisition System (DAQ) for the BetaNMR (BNMR) and BetaNQR (BNQR) experiments at TRIUMF

[[:Category:BNMR|Click here for a full list of all the pages in the BNMR documentation]].

== Introduction ==
The Data Acquisition System is based on the [https://midas.triumf.ca/MidasWiki/index.php/Midas_documentation MIDAS] data acquisition package.

There are two separate '''beamlines''', BNMR and BNQR, each with its own experimental setup :

* {{bnmr}} running on the BNMR high-voltage platform
* {{bnqr}} running on the BNQR high-voltage platform

Each experimental setup has its own [[#Hardware Components]] (i.e. a VME crate containing DAQ modules). Each runs as a separate MIDAS experiment named {{bnmqr|join=or}}. DAQ software specific to these experiments (MIDAS clients) run the experiments - see [[#Software Components]]. Experimenters control the experiment using the MIDAS Web Server (mhttpd).

== Beam Control ==
The main TRIUMF EPICS Control System is used to control the beam, which can be switched to either experiment's '''beamline'''. There are two '''Beam Modes''' that the experiments can be run in:

; [[BNMR Dual Channel Mode #Single Channel Mode|single channel mode]]
: where the beam is sent to one beamline (channel) only, either BNMR or BNQR. Only '''one''' of the DAQ systems <span style="color:#7b68ee; font-style=italic">bnmr </span> or <span style="color:#20b2aa; font-style=italic">bnqr</span> is active.
; [[BNMR Dual Channel Mode|dual channel mode]]
: where the beam is switched between the two beamlines (channels) BNMR and BNQR at regular intervals. '''Both''' DAQ systems <span style="color:#7b68ee; font-style=italic">bnmr </span> and <span style="color:#20b2aa; font-style=italic">bnqr</span> are active.

== Experimental modes ==
For both experiments, two types of environment are defined (cf MUSR experiments):

* '''Integral or TI (Type 1)'''
* '''Time Differential or TD (Type 2)'''

There are two separate concepts that use similar naming schemes (e.g. 1f, 20) - the timing of pulses issued by the PPG and the name of the overall experimental mode. The overall mode determines both which timing scheme is run, as well as which hardware is scanned during the run (e.g. RF frequency, Na cell voltage). Multiple experimental modes may use the same PPG timing scheme (e.g. modes 1c, 1d, 1e, 1n use the PPG timing scheme called 1n).

Below is a full list of experimental modes, with the most common ones highlighted in bold. More details about each mode can be found on the [https://isdaq01.triumf.ca:8447/?cmd=custom&page=Modes BNMR mode changer] page and the [https://isdaq01.triumf.ca:8448/?cmd=custom&page=Modes BNQR mode changer] page.

{| class="wikitable"
|+ Experimental modes
|-
! Mode name !! PPG timing !! BNMR? !! BNQR? !! Comment
|-
| '''10''' || 10 || ✓ || ✓ || No RF, nothing scanned
|-
| 1a || 1a || ✓ || ✓ || Scan RF frequency
|-
| 1b || 1b || ✓ || ✓ || Scan RF frequency
|-
| 1c || 1n || ✓ || ✓ || Scan settings on a Camp device
|-
| 1d || 1n || ✓ || ✓ || Scan the laser intensity
|-
| 1e || 1n || || ✓ || Scan the magnetic field strength
|-
| '''1f''' || 1f || ✓ || ✓ || Scan RF frequency
|-
| 1g || 20 || ✓ || ✓ || Scan RF frequency
|-
| 1j || 20 || ✓ || ✓ || Scan settings on a Camp device
|-
| '''1n''' || 1n || ✓ || ✓ || Scan the Rb cell voltage or any other EPICS device
|-
| 1w || 1w || ✓ || || Parametric scan of RF frequencies
|-
| '''1x''' || 1f || ✓ || ✓ || Scan RF frequency with one region at higher resolution
|-
| '''20''' || 20 || ✓ || ✓ || Nothing scanned
|-
| 2a || 2a || ✓ || ✓ || Scan RF frequency
|-
| 2b || 2b || ✓ || ✓ || Scan RF frequency
|-
| 2d || 1b || ✓ || ✓ || RF on, nothing scanned
|-
| 2e || 2e || ✓ || ✓ || Scan RF frequency
|-
| 2f || 2f || ✓ || ✓ || Scan RF frequency
|-
| 2h || 20 || || ✓ || Read alpha channels from scalers
|-
| 2s || 2s || ✓ || || Spin-echo
|-
| 2w || 2w || ✓ || || RF Wurst modulation
|}

Any of these modes may be run in [[#Beam Control|single channel mode]]. Only Type 2 modes may be run in [[#Beam Control|dual channel mode]].

Users change which mode is active using the webpages for each experiment, which in turn interact with the [[#Software_Components|mode changer]] python script.

== Hardware Components ==

DAQ hardware components for each DAQ system (BNMR/BNQR) include the following VME modules:
{| class="wikitable" border=1 cellspacing=3 cellpadding=10
|+ <b><center> Table 2: VME Modules for each Experiment</center></b>
|-
! Module !! Description !! VME Base Address !! BNMR? !! BNQR? !! Manual
|-
| SIS3801 version E || multichannel scaler A || 0x2800 || ✓ || ||rowspan="2" | [[Media:Sis3801_V5_to_VE.pdf|SIS3801 manual (PDF)]]
|-
| SIS3801 version E || multichannel scaler B || 0x1800 || ✓ ||
|-
| SIS3820 || multichannel scaler B || 0x38000000 || || ✓ || [[Media:Sis3820-M-0-001-v186-scaler.pdf|SIS3820 manual (PDF)]]
|-
| PPG (Pulseblaster)|| Pulse Programmer ||0x8000 || ✓ || ✓|| [[Media:PPG.pdf|PPG manual (PDF)]] [[Media:Spincore.pdf|Spincore Pulseblaster (PDF)]]
|-
| PSM || Pol Synthesizer module (RF)|| 0x820000 || || ✓ ||rowspan="3" |[[BNMR:_PSM_(Pol_Synth_Module)|PSM]]
|-
| PSMII || Pol Synthesizer module II (RF) || 0x820000 || ||
|-
| PSMIII|| Pol Synthesizer module III(RF) || 0x820000 || ✓ ||
|-
| NIMIO32 || Input/Output Register ||0x100000 || ✓ || ✓ || [[VME-NIMIO32| NIMIO32]]
|-
| MVME162 || 68040 board (VxWorks) that runs CAMP || || ✓ (bnmrvw) || ✓ (polvw) || <div id=VMIC></div>
|-
| VMIC|| Linux machine in VME crate that runs frontend || || ✓ (lxbnmr) || ✓ (lxbnqr) ||
|}

The connections between the DAQ VME Modules are shown in [[BNMR DAQ Hardware Connections]].

== Software Components ==
The DAQ system is based on the [https://midas.triumf.ca/MidasWiki/index.php/Midas_documentation MIDAS] package. Data acquisition software to run the {{bnmqr|join=and}} experiments has been written to run under MIDAS. This includes the frontend, custom logger etc. This software is mostly common to both experiments, with the differences between each experiment handled by Midas ODB settings (most things) and a compile-time flag (choosing whether to build the febnmr or febnqr frontend).

The experiment is controlled using the MIDAS webserver (mhttpd). Due to the large number of experimental parameters required, Midas custom pages have been written for the experimenters to control and monitor their experiment.

The custom logger (mdarc/midbnmr) saves the data into MUSR MUD format files, and the MUSR CAMP slow control system is used for slow controls. Analysis is done by physica.

The DAQ software components are started by the script ''start-all'' and stopped by the script ''kill-all''. These include '''standard MIDAS utilities''' (e.g. [https://midas.triumf.ca/MidasWiki/index.php/Mhttpd mhttpd], [https://midas.triumf.ca/MidasWiki/index.php/Mlogger mlogger], [https://midas.triumf.ca/MidasWiki/index.php/Mserver mserver]) as well as components specific to the {{bnmqr|join=and}} experiments.

The main DAQ software components specific to the {{bnmqr|join=and}} experiments are shown in the table below. A full ist can be found on the [[BNMR:_Software_overview|software overview page]].

{| class="wikitable" border=1 cellspacing=3 cellpadding=2 style="background-color:#f0f0f5"
|+ <b><center> Table 3: DAQ Software Components</center></b>
|- style="background-color: #e0e0eb;"
! Component !! Host !! Experiment !! Purpose
|-
|-
| colspan=4| ''Midas frontends''
|- style="background-color:floralwhite;"
| [[BNMR: frontend|febnmr_32bit.exe]] || '''lxbnmr''' || bnmr || rowspan=2| the '''frontend''' sets up, reads out hardware modules, sends histograms.<br>The frontend code for both experiments is identical.
|- style="background-color:floralwhite;"
| [[BNMR: frontend|febnqr_32bit.exe]] || '''lxbnqr''' || bnqr
|-
| colspan=4| ''Midas clients - configuration''
|- style="background-color:mintcream"
| [[BNMR:_Mode_changer|mode_changer.py]]|| isdaq01|| both || changes between experimental modes and between real/test runs
|- style="background-color:mintcream"
| [[BNMR:_RF_calculator|rf_calculator_fe.py]]|| isdaq01|| both || generates PPG program based on user-specified ODB parameters; reports calculated quantities in the ODB; sets up links in the ODB that should be stored in MUD files
|- style="background-color:mintcream"
| [[BNMR:_PPG_compiler|ppg_compiler_fe.py]]|| isdaq01|| both || low-level conversion of PPG program to PPG bytecode
|-
| colspan=4| ''Midas clients - logging''
|- style="background-color: mintcream;"
| [[BNMR:_Data_Logging|bnxr_logger.exe]]|| isdaq01|| both|| writes data to MUD files. Reads information from midas banks (for scaler histograms), EPICS, and CAMP
|- style="background-color: mintcream;"
| [[BNMR:_Data_Logging#Cleaning_up_if_end-of-run_fails|logger_cleanup.exe]]|| isdaq01|| both|| cleans up and archives any saved run files that were not properly archived. Run by user occasionally as needed.
|- style="background-color:mintcream"
| [[BNMR:_Data_Logging#Run_comments|run_comment_editor.py ]]|| isdaq01|| both || responds to comments written by user in text box on the status page, saving to disk and/or midas banks
|-
| colspan=4| ''Other''
|- style="background-color:#ffe6e6;"
| [[BNMR: autorun|autorun]]|| isdaq01|| both|| automatic run controller
|- style="background-color:#ffe6e6"
| [[BNMR: Scripts|scripts]]|| isdaq01 || both|| scripts perform important functions e.g. kill-all, start-all. Scripts run at the begin and end of each run send information to the elog etc.
|- style="background-color:#ffe6e6"
| rowspan=2| [[BNMR: CAMP|camp]] || '''bnmrvw''' || bnmr || rowspan=2| MUSR slow control system
|- style="background-color:#ffe6e6"
| '''polvw''' || bnqr
|}

Click the links in the above table for more details of each program.

Not listed above are various [[BNMR:_Tests|automated test]] programs for both the C++ and python programs. There are also some interactive test programs for [[BNMR: Hardware Debugging|debugging hardware issues]].

Note that the DAQ was rewritten in 2020. Details of the rewritten in 2020. Details of the differences between the new DAQ (documented here) and legacy DAQ (documentation removed) can be found on the [[BNMR:_Rewrite_2020|2020 rewrite]] page.

== DAQ Summary ==
;The VMIC front end computer
* runs the [[BNMR: frontend|frontend code]]''' which
** controls PSM,PPG, VMEIO, Scaler modules
** acquires data from SIS MCS (scaler) module(s), builds [[BNMR: Histograms and Scalers|histograms]]
** uses channel access to control EPICS variable(s) (e.g. helicity)
** periodically sends the data out into the data buffer

;The host computer (isdaq01)
* runs all other software components which
** acquire the data from the data buffer
** log the data
** monitor the experiment
** start/stop runs

== Tasks to be done before each beamtime ==

* If this is the first beamtime of the year, [[BNMR:_Mode_changer#Resetting_the_run_numbers|create a new data directory and reset the run numbers]].
* If there have been changes to the code that affect the ODB structure, [[BNMR:_Mode_changer#Handling_changes_to_the_ODB_structure|ensure saved settings have been updated to contain the new variables]].
* Edit the bnmr user's cronjob (using <code>crontab -e</code>) to specify the schedule number and date range to include in the generated Excel file ([[BNMR:_Shift_Monitor#beamtime_to_excel.py|see the supported arguments to beamtime_to_excel.py]]).
* Try changing between a few common modes (e.g. 20, 1f, 1n, and back to 20) and ensure the run can start (in test mode, not real mode). You may need to disable "switching" checks on the [[BNMR:_Custom_Status_page|status page]] if the beamline is not currently configured for BNMR/BNQR.

== Nomenclature ==
In this document, " ''bnmr'' or ''bnqr'' " may be written as " ''bn['''mq''']r'' "

For example, directories :
: <span style="color:#004d4d; font-weight:normal; font-style:italic ">/home/<span style="font-weight:bold;">bnmr</span>/online/<span style="font-weight:bold;">bnmr</span></span> <span style="color:white">spc</span> and <span style="color:white">spc</span> <span style="color:#004d4d; font-weight:normal; font-style:italic ">/home/<span style="font-weight:bold;">bnqr</span>/online/<span style="font-weight:bold;">bnqr</span></span>

are referred to by '''shortcuts''' such as

<span style="color:white">space</span> {{Filepath|path=/home/bn<span style="font-weight:bold;">[nm]</span>r/online/b<span style="font-weight:bold;">[nm]</span>r}} <span style="color:white">spc</span> and <span style="color:white">spc</span> {{Filepath|path=~/online/b<span style="font-weight:bold;">[nm]</span>r}}

Alternatively, these directories may be written as
<ul>
<li> {{Filepath|path=/home/<experiment>/online/<beamline>}}
<li> {{Filepath|path=/home/<expt>/online/<beamline>}}
<li> {{Filepath|path=~/online/<beamline>}}
</ul>
where {{Filepath|path=<experiment>}} {{Filepath|path=<expt>}} and {{Filepath|path=<beamline>}} are {{bnmqr|join=or}}.

[[Category:BNMR]]

2024-01-09T23:44:05Z

Bsmith:

PPG Building Blocks

2024-01-09T23:43:10Z

Bsmith: /* Automatic and user-defined time references */

= Links =
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
* [[TITAN]] page
* [[TITAN DAQ General Documentation]]
* [[PPG ODB Block Structure]]
</div>
== Introduction ==
[[Image:PPG_page.png|250px|thumb|right|Example of PPG page showing user settings and preview of the timing scheme]] TITAN and other experiments use a Programmable Pulse Generator (PPG) to issue precise timing signals during their experiments. TITAN in particular require very flexible timing schemes, and users change these schemes often. A TITAN grad student initially implemented a way to program the PPGs via settings in an ODB directory. This concept has now been expanded and made more felxible and user-friendly. At the heart of the systems is a python-based compiler that converts the ODB settings into bytecode that the PPG hardware understands.

This page explains the contents of the PPG Blocks stored in the ODB, how they are named and how they work.

In general, the user does not need to know these details, as they are handled by the python/javascript provided in the [https://bitbucket.org/ttriumfdaq/cycling_framework/ cycling_framework].

The structure of the user's PPG program is stored in the ODB as a set of sub-directories within {{Odbpath|path=/Equipment/PPGCompiler/Programming}}. The order of the sub-directories matters, as if no explicit "time reference" supplied, one block is assumed to start immediately after the previous one finishes. Sub-directories must be named according to the conventions listed in [[#Defined Block Types]]. Each sub-directory must have a unique name. The keys that must be present within each subdirectory are detailed below, and vary based on the block type (pulse, delay, loop etc).

A python program (the PPG compiler, [https://bitbucket.org/ttriumfdaq/cycling_framework/src/master/ppg/ppg_compiler_fe.py ppg_compiler_fe.py]) runs as a midas frontend and converts the ODB structure into bytecode that can be loaded onto the PPG.

== Compiler settings ==

The compiler has some global settings in {{Odbpath|path=/Equipment/PPGCompiler/Settings}}:

* ''Standard pulse width (ms)'' - see [[#Standard Pulse Widths]]
* ''PPG clock (MHz)'' - PPG clock frequency, so we can convert from ms to number of clock cycles
* ''Use external trigger'' - y/n for whether the PPG should use an external signal or a software command to start
* ''Use external clock'' - y/n for whether the PPG should use an external or internal clock
* ''Inverted channels bitmask'' - bitmask to invert output of any channels; not generally used
* ''Loadfile path'' - where to write the bytecode that is generated (note that the frontend can also ask for the bytecode to be sent to it directly, not via a written file)
* ''PPG uses pulseblaster - y/n for whether this is the older PulseBlaster PPG or newer TRIUMF PPG (as they have different bytecode requirements)
* ''Debug'' - y/n for whether to debug the compiler
* ''Compile at BOR'' - y/n for whether to automatically compile bytecode at begin-of-run (note that TITAN frontends ask the compiler themselves during their BOR transition, so this can safely be 'n' for TITAN experiments)
* ''Enable extra 1-time BOR program'' - see [[#Begin-of-run program]]
* ''Wrap program in automatic loop'' - some experiments have very strict timing, and want to run the same program multiple times without delay. However, the user did not want to think about this as a loop in their own program. So we allow wrapping everything that the user provides in an automatic loop, and only ask the user how many time to run the loop before stopping. (In cycling_framework language, the user's code runs multiple times within a single cycle).
* ''Auto loop num iterations'' - if wrapping the user's program in an automatic loop, how many iterations to run.
* ''Record T0 offsets'' - y/n for whether to record timing offsets of each block in the ODB. This is useful for some experiments who need to know the time difference between 2 pulses for their analysis. Results are written to {{Odbpath|path=/Equipment/PPGCompiler/Computed/T0 offsets (ms)}}.
* ''Enable formulae'' - see [[#Specifying times with a formula]]
* ''Image path'' - legacy, for when webpage showing a static image of the cycle rather than an interactive plot
* ''Expanded image path'' - legacy, for when webpage showing a static image of the cycle rather than an interactive plot

=== PPG clock ===
The internal clock of the PPG PulseBlaster (used on MPET) is determined by an on-board clock chip, which is removed when the PPG is run with an external clock. This is the case for MPET, where the PPG is clocked with an external 100MHz clock. It cannot be switched between internal and external clock by software.

The PPG32 on the other hand can be switched between internal and external clock by software. It was designed to use a 20MHz internal or external clock, the actual frequency being programmed with divide-downs. The CPET PPG32 has been modified to use an external 100MHz clock (same clock as MPET). The EBIT PPG32 has not been modified, and currently runs with the internal clock programmed to produce 100MHz.
The maximum value supported by either board is 100MHz.

The correct PPG Clock Frequency must be stored in the ODB at <code>/Equipment/PPGCompiler/Settings/PPG clock (MHz)</code>, otherwise the timing of the output pulses will be incorrect, i.e.
{| style="text-align: left; width: 60%; background-color: white;" border="0" cellpadding="2" cellspacing="2"
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
! Input parameter name !! Value !! Type
|-
|PPG Clock (MHz)|| 100 || FLOAT
|}
<br><br>

=== Standard Pulse Widths ===
Other values are defined (also in the input parameter area) which the user can change as required:

{| style="text-align: left; width: 60%; background-color: white;" border="0" cellpadding="2" cellspacing="2"
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
! Input parameter name !! Value !! Type
|-
| standard pulse width (ms)|| 0.005 || DOUBLE
|}

* The ''standard pulse width'' is used by the STDPULSE blocks. Using a STDPULSE reduces the number of different delays that need to be generated to program the PPG.

== Optional features ==

=== Begin-of-run program ===

It is possible to run an extra program once at the start of a run, before running the "normal" program. This may be useful for resetting scalers or similar.

The begin-of-run program is enabled with the PPGCompiler setting 'Enable extra 1-time BOR program'. The program itself is stored in {{Odbpath|path=/Equipment/PPGCompiler/Programming BOR}}

=== Scanning parameters ===

The cycling framework allows for time offsets and pulse widths to be scanned during a run. If scanning is enabled, the experiment's frontend code sets the relevant parameters in the ODB blocks, then asks the compiler to re-produce the bytecode.

=== Specifying times with a formula ===

By default, the user specifies actual numbers for the time offsets and pulse widths. However, by setting '/Equipment/PPGCompiler/Settings/Enable formulae' to true, the user may specify variables and formulae for the timings.

User-specified variables are stored in the '/Equipment/PPGCompiler/Programming/Formula variables' directory. Formulae are stored in the 'time offset formula' and 'pulse width formula' keys of each PPG block. When the compiler is asked to re-compile the bytecode, it first evaluates the formulae, putting the results in the 'time offset (ms)' and 'pulse width (ms)' keys as appropriate. The rest of the compilation then proceeds as normal.

Formula evaluation is done in the python code in a safe way (using Abstract Syntax Tree parsing with a whitelist of allowed functions/variables, rather than simply calling 'eval()').

User-specified variables may be scanned during a run.

=== Adding an automatic loop ===

Normally we run the program specified by the user once per "cycle". In the cycling framework this means we do: start the PPG -> wait for cycle to finish -> do some work in software -> start the PPG again. Sometimes users want to run a program multiple times without any software delay between cycles. This is easily achieved by just wrapping the entire program in a loop. However, sometimes users don't want the "visual noise" of seeing the actual loop. So we allow an "automatic loop" to be added by the compiler. The user never sees the definition of this loop, but just says how many times to run the program before we do a software delay (e.g. to read out data, increase scan values etc).

Enabling the automatic loop is done with the '/Equipment/PPGCompiler/Settings/Wrap program in automatic loop' key, and the number of iterations to run each time we start the PPF is specified with the '/Equipment/PPGCompiler/Settings/Auto loop num iterations' key.

=== Muting blocks ===

Users may mute and unmute blocks to disable the output of a block without affecting the timing of a sequence. This is particularly useful for taking signal and background measurements with an RFQ pulse unmuted and muted, for example. Muted blocks appear with a red background on the webpage.

The cycling framework includes the ability to automatically toggle between muted and unmuted states during a run. You could configure it to run N cycles with a pulse muted, then N cycles unmuted, then increase a scan value, and start running N cycles with a pulse muted again etc... Multiple pulses can be muted/unmuted at the same time, and with opposite polarities if desired.

== Defined PPG Block Types ==
A number of fundamental building blocks (PPG Blocks) have been defined. Many act on one or more of the PPG Output signals. They are listed in Table 1 below. Click on each Block Type for more information.

{| style="text-align: left; width: 100%; background-color: white" border="3" cellpadding="2" cellspacing="2"
|+ TABLE 1 List of Block Types acting on PPG signals
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
! Block Type * <br> (click on links for definitions)
! Explanation
! style="text-align:left;color:#b300b3;font-style:italic;"|Example <br>Blockname
|-
|[[#Transition Block|'''TRA'''''NS'']]
| cause a channel '''transition''' (toggle between on and off, depending on the current state)
|style="text-align:left;color:#b300b3;font-style:italic;"| TRANS_EX
|-
|[[#Turnon Block|'''TURNON''']]
| ensure a channel is '''on'''
|style="text-align:left;color:#b300b3;font-style:italic;"| TURNON_EX
|-
|[[#Turnoff Block|'''TURNOFF''']]
| ensure a channel is '''off'''
|style="text-align:left;color:#b300b3;font-style:italic;"| TURNOFF_EX
|-
|[[#Pulse Block|'''PUL'''''SE'']]
|a '''pulse''' of user-defined width
|style="text-align:left;color:#b300b3;font-style:italic;"|pulse_dac
|-
|[[#Multi Pulse Block|'''MUL'''''TI'']]
|multiple '''pulses''' on the same channel a fixed time apart
|style="text-align:left;color:#b300b3;font-style:italic;"|multi_dac
|-
|[[#Stdpulse Block|'''STD'''''PULSE'']]
| a '''pulse''' of a standard width
|style="text-align:left;color:#b300b3;font-style:italic;"|stdpulse_5
|-
|[[#Pattern Block|'''PAT'''''TERN]]
| sets a '''bit pattern'''
|style="text-align:left;color:#b300b3;font-style:italic;"|PatFF0E
|-
|[[#Delay Block|'''DEL'''''AY]]
|'''Delay''' for a time with existing bit pattern unchanged
|style="text-align:left;color:#b300b3;font-style:italic;"|DEL10
|-
|[[#Time Reference Block|'''TIM'''''E_REF]]
| defines a time reference from which other blocks can be offset
|style="text-align:left;color:#b300b3;font-style:italic;"|timDacStart
|-
|[[#Begin Loop Block|'''BEGIN'''''_LOOP]]
|'''begin''' a loop
|style="text-align:left;color:#b300b3;font-style:italic;"|Begin_loop5
|-
|[[#End Loop Block|'''END'''''_LOOP]]
|rowspan="1"|'''end''' a loop
|style="text-align:left;color:#b300b3;font-style:italic;" |End_loop5
|-
|}

== PPG Signal Names ==
PPG Signal Names are '''required''' in PULSE, MULTI and TRANS PPG blocks. These blocks have a parameter ''PPG signal name'' which expects one of the defined PPG signal names, which are of the form "CH1", "CH2" etc (for channel 1/2). This name defines which PPG Output Channel is to be acted on by the PULSE or TRANS PPG block. Note that the PATTERN block acts on a bit pattern, not PPG signal names. For example, 0x2000 (EBIT) will act on PPG signal name TDCBLOCK (Channel 14). Setting a pattern of 0xFFFF will set all 32 outputs ON.

The user is able to specify human-readable names for each channel in the ODB at {{Odbpath|path=/Equipment/PPGCompiler/Programming/names}}.

== Time references & Sequence of the blocks: T0 ==
The time when the PPG starts running is defined as '''T0'''. All blocks are ultimately referenced in time to T0, and they will be sorted (by the ppg compiler) in order of time offset from T0 before processing into the PPG load file.

The ordering of the blocks is significant:

* If a block does not specify a time reference, it we default to starting as soon as the block before it ends.
* If a block appears between a begin_ and end_ of a loop, it will be part of that loop. Blocks within a loop may not use a time reference of a block outside the loop.

== Automatic and user-defined time references ==
Blocks automatically define at least one time reference. Variable-length blocks such as pulses and loops automatically define time references at the start and end of the block. Blocks such as transitions and patterns automatically define only one time reference since the start and end are identical.

Users can also define a time reference, using a [[#Time Reference Block]]. This provides a way to synchronize several blocks to start at one time, or to produce a delay before the next block if relying on the default time reference.

The automatic time reference names for variable-length blocks are of the form "_TSTART_<blockname>, "_TEND_<blockname>. For other blocks, they are mostly of the form "_T<blockname>" .
They are shown below in Table 3 for each of the defined blocks.

{| style="text-align: left; width: 100%; background-color: white" border="3" cellpadding="2" cellspacing="2"
|+ TABLE 3 Automatically generated time references for each block
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
! Block Type
! Example <br> Blockname
! Automatically defined <br> time reference names
! Example time<br> references
|-
|[[#Transition Block|Trans]]ition
| TRANS_EX
|style="color:#7733ff;font-style:italic;"| _T<span style="color:black;"><block name></span>
|style="color:#7733ff;font-style:italic;"|_T<span style=color:black>TRANS_EX</span>
|-
|[[#Turnon Block|Turnon]]
| TURNON_EX
|style="color:#7733ff;font-style:italic;"| _T<span style="color:black;"><block name></span>
|style="color:#7733ff;font-style:italic;"|_T<span style=color:black>TURNON_EX</span>
|-
|[[#Turnoff Block|Turnon]]
| TURNOFF_EX
|style="color:#7733ff;font-style:italic;"| _T<span style="color:black;"><block name></span>
|style="color:#7733ff;font-style:italic;"|_T<span style=color:black>TURNOFF_EX</span>
|-
|[[#Pulse Block|Pulse]]
|style="color:black"|pulse_dac
|style="color:#7733ff;font-style:italic;"|_TSTART_<span style="color:black;"><block name></span>,<br> _TEND_<span style="color:black;"><block name></span>
|style="color:#7733ff"|_TSTART_<span style=color:black>pulse_dac</span><br>_TEND_<span style=color:black>pulse_dac</span>
|-
|[[#Multi Pulse Block|Multi]]
|style="color:black"|multi_dac
|style="color:#7733ff;font-style:italic;"|_TSTART_<span style="color:black;"><block name></span>,<br> _TEND_<span style="color:black;"><block name></span>
|style="color:#7733ff"|_TSTART_<span style=color:black>multi_dac</span><br>_TEND_<span style=color:black>multi_dac</span>
|-
|[[#Stdpulse Block|Stdpulse]]
|stdpulse_5
|style="color:#7733ff;font-style:italic;"|_TSTART_<span style="color:black;"><block name></span>,<br> _TEND_<span style="color:black;"><block name></span>
|style="color:#7733ff"| _TSTART_<span style=color:black>stdpulse_5</span><br>_TEND_<span style=color:black>stdpulse_5</span>
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|[[#Pattern Block|Pattern]]
|PatFF0E
|style="color:#7733ff;font-style:italic;"|_T<span style="color:black;"><block name></span>
|style="color:#7733ff"|_T<span style="color:black">PatFF0E</span>
|-
|[[#Delay Block|Delay]]
|DEL10
|style="color:#7733ff;font-style:italic;"| _T<span style="color:black;"><block name></span>
|style="color:#7733ff;font-style:italic;"|_T<span style=color:black>DEL10</span>
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|[[#Time Reference Block|Time_Ref]]erence
|timDacStart
|style="color:#7733ff;font-style:italic;"| _T<span style="color:black;"><block name></span>
|style="color:#7733ff;font-style:italic;"|_T<span style=color:black>timDacStart</span>
|-
|[[#Begin Loop Block|BEGIN_LOOP]]
|Begin_loop5
|style="color:#7733ff;font-style:italic;"|_TBEG<span style="color:black;"><loop name></span>
|style="color:#7733ff;font-style:italic;"|_TBEG<span style=color:black>loop5</span>
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|[[#End Loop Block|END_LOOP]]
|rowspan="2" |End_loop5
|rowspan="1" style="color:#7733ff;font-style:italic;"|_TEND<span style="color:black;"><loop name></span>_ONE
|rowspan="1" style="color:#7733ff;font-style:italic;"|_TEND<span style=color:black>loop5_ONE</span>
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|style="color:#7733ff;font-style:italic;"|_TEND<span style="color:black;"><loop name></span>
|rowspan="1" style="color:#7733ff;font-style:italic;"| _TEND<span style=color:black>loop5</span>
|-
|}

== Definitions of PPG Blocks ==
=== Time Reference Block ===
The PPG time zero (T0) is defined as the time when the PPG starts running after receiving a start signal (either software or hardware). All blocks are offset ultimately from T0. The time reference T0 is defined '''automatically'''. A number of other time-references are defined automatically - see [[#Automatic and user-defined time references]].

The user may define other time references for convenience, using a ''TIME_REF'' PPG Block. User-defined time references, like automatic time references, can be used as time references for later PPG Blocks. A time reference block may define a reference from T0 or from any previously defined time reference.

When a TIME_REF Block is defined, the '''name''' of the time reference it defines is generated automatically. It is derived from the TIME_REF Block Name as indicated in [[#Automatic and user-defined time references|Table 3]], by adding the prefix ''_T''. See [[#example 1]] below.

Figure 1 shows two time references, T1 and T2, defined by the user using two time reference blocks.
[[Image:Timeref.png|frame|center|Figure 1: Defining a Time Reference]]
<br clear=all>

Time reference blocks take the following parameters (Table 4):
{| style="text-align: left; width: 80%; background-color: white;" border="3" cellpadding="2" cellspacing="2"
|+ Table 4 : Time Ref Block Parameters
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
!ODB Key Name !! Type !! Default Value !! Required/Optional
|-
|time offset (ms) || DOUBLE || 0 || Optional
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|time reference || STRING[20] || end of previous block || Optional
|}

All ''TIME_REF'' blocks in ODB must have the first 3 letters "tim", e.g. {{ppgblock|block=TIME_2}}, t{{ppgblock|block=ime_reference_define_t3}}, {{ppgblock|block=Time1}} are all acceptable. The block names must be unique, since no two time references can have the same name. Both parameters are optional. If not supplied, the default values will be used.

==== Example 1: Time Reference Blocks ====

The time references in Figure 1 (above) could be defined as PPG Blocks {{ppgblock|block=time_t1}} and {{ppgblock|block=time_t2}}, where {{ppgblock|block=time_t1}} is referenced to T0, and automatically defines the time reference {{timeref|ref=_TTIME_T1}} (see [[#Automatic and user-defined time references|Table 3]]). PPG Time Reference block {{ppgblock|block=time_t2}} is then referenced to {{timeref|ref=_TTIME_T1}} i.e.
$ odbedit>
[local:test]TITAN_ACQ>cd "/Equipment/Titan_acq/ppg cycle"
[local:test]TITAN_ACQ>ls ppg_cycle
time_t1
time_t2
[local:test]TITAN_ACQ>ls "ppg_cycle/time_t1" -lt
time offset (ms) 0.25
time reference T0
[local:test]TITAN_ACQ>ls "ppg_cycle/time_t2" -lt
time offset (ms) 0.75
time reference _TTIME_T1
Alternatively, {{ppgblock|block=time_t1}} could be referenced back to time T0, i.e.
[local:test]TITAN_ACQ>ls "ppg_cycle/time_t2" -lt
time offset (ms) 1.0
time reference T0
If these were the only blocks present, it would not be necessary to specify the time references in the first example, because by default each block is time-referenced from the previous block. The second example must include the time reference, because the time offset given is from T0, not from the previous block.

=== Transition Block ===
This block reverses the state of an output signal (Figure 2). Two transition blocks on the same PPG output signal is equivalent to a [[#Pulse Block]].

[[Image:Trans.png|frame|center|Figure 2: Two Transitions]]
<br clear=all>

Transition blocks take the following parameters (Table 5):
{| style="text-align: left; width: 80%; background-color: white;" border="3" cellpadding="2" cellspacing="2"
|+ Table 5 : Transition Block Parameters
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
!ODB Key Name !! Type !! Default Value !! Required/Optional
|-
|time offset (ms) || DOUBLE || 0 || Optional
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|time reference || STRING[20] || end of previous block || Optional
|-
| ppg signal name || STRING[15] || no default; must be supplied || Required
|-
|}

A Transition block automatically defines a ''time reference'' to the time when the transition occurs. This time reference may be used by subsequent blocks as their time reference. The name of the time reference is derived from the block's name by adding the prefix ''_T'', so that a block named {{ppgblock|block=TRANS_tdc4}} will define a time reference {{timeref|ref=_TTRANS_TDC4}}.
TRANSITION blocks must have unique names, with first 3 letters being '''TRA''', e.g. {{ppgblock|block=TRANS_2}}, {{ppgblock|block=transition_RFGATE1}}, {{ppgblock|block=TraX}} are all acceptable.

==== Example 2: Transition Block ====
This example shows a transition block with blockname {{ppgblock|block=TRANS_5}}
[local:test]TITAN_ACQ> cd "/Equipment/Titan_acq/ppg cycle"
[local:test]TITAN_ACQ> ls trans5
time offset (ms) 100
time reference T0
ppg signal name RFGATE2

This example reverses the state of the PPG output signal "RFGATE2" at an offset of 100ms from T0. A time reference {{timeref|ref=_TTRANS_5}} for this transition is automatically defined.

=== Turnon Block ===
This is exactly the same as a [[#Transition Block]], but ensures that a channel is ON (rather than toggling between on/off). If the channel was already on, the block has no effect (but can still be used as a time reference for other blocks).

=== Turnoff Block ===
This is exactly the same as a [[#Transition Block]], but ensures that a channel is OFF (rather than toggling between on/off). If the channel was already off, the block has no effect (but can still be used as a time reference for other blocks).

=== Pulse Block ===
This block defines a pulse of user-defined width. Figure 3 shows two pulses, one offset from T0, one offset from time reference T1. The state of the PPG output signal will be reversed for the pulse width duration.
Two [[#Transition Block]]s could perform the same function as a pulse block.

[[Image:Pulse.png|frame|center|Figure 3: Pulses]]
<br clear=all>

'''Pulse''' blocks take the following parameters (Table 6):
{| style="text-align: left; width: 80%; background-color: white;" border="3" cellpadding="2" cellspacing="2"
|+ Table 6 : Pulse Block Parameters
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
!ODB Key Name !! Type !! Default Value !! Required/Optional
|-
|time offset (ms) || DOUBLE || 0 || Optional
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|time reference || STRING[20] || end of previous block || Optional
|-
| pulse width (ms) || DOUBLE || minimal delay || Optional
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
| ppg signal name || STRING[15] || no default; must be supplied || Required
|-
|}

A Pulse block automatically defines two '''time references'''; one to the time when the pulse starts, the second to the time when pulse ends. This time reference may be used by subsequent blocks as their time reference. The name of the time reference is derived from the block's name by adding the prefixes "_TSTART_" and "_TEND_" so that a pulse block named {{ppgblock|block=PULSE_TDC}} will define the time references {{timeref|ref=_TSTART_PULSE_TDC}} and {{timeref|ref=_TEND_PULSE_TDC}}.
PULSE blocks must have unique names, with first 3 letters being '''PUL''', e.g. {{ppgblock|block=PULSE_2}}, {{ppgblock|block=pulse_RFGATE1}}, {{ppgblock|block=PulX}} are all acceptable.

==== Example 3: Pulse Block ====
This example shows a pulse block with blockname {{ppgblock|block=PULSE_3}}
[local:test]TITAN_ACQ> cd "/Equipment/Titan_acq/ppg cycle"
[local:test]TITAN_ACQ> ls pulse3
time offset (ms) 0.05
time reference _TTRANS_5
ppg signal name RFTRIG1
pulse width (ms) 0.005

This example reverses the state of the PPG output signal "RFTRIG1" at an offset of 0.05ms from time reference {{timeref|ref=_TTRANS_5}} for a time of 0.005ms. It is assumed that {{timeref|ref=_TTRANS_5}} has been defined by the transition block in Example 2. A time references {{timeref|ref=_TSTART_PULSE3}} and {{timeref|ref=_TEND_PULSE3}} for this pulse will be defined automatically.

=== Multi Pulse Block ===
This block defines a sequence of multiple pulses of user-defined width and a user-defined period. It simplifies programming if you need multiple periodic pulses, but a LOOP isn't appropriate (e.g. because a LOOP affects all channels, and you only need periodic output on one channel while the others to non-periodic things).

'''Multi''' pulse blocks take the following parameters (Table 7):
{| style="text-align: left; width: 80%; background-color: white;" border="3" cellpadding="2" cellspacing="2"
|+ Table 7 : Multi Pulse Block Parameters
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
!ODB Key Name !! Type !! Default Value !! Required/Optional
|-
|time offset (ms) || DOUBLE || 0 || Optional
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|time reference || STRING[20] || end of previous block || Optional
|-
| pulse width (ms) || DOUBLE || minimal delay || Optional
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
| ppg signal name || STRING[15] || no default; must be supplied || Required
|-
| rep count || INTEGER || no default; must be supplied || Required
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
| delay between reps (ms) || DOUBLE || no default; must be supplied || Required
|}

Note that "delay between reps" is the time between the START of each pulse, not the time between the end of one pulse and the start of the next!

A Pulse block automatically defines two '''time references'''; one to the time when the FIRST pulse starts, the second to the time when the LAST pulse ends. These time references may be used by subsequent blocks as their time reference. The name of the time reference is derived from the block's name by adding the prefixes "_TSTART_" and "_TEND_" so that a multi-pulse block named {{ppgblock|block=MULTI_TDC}} will define the time references {{timeref|ref=_TSTART_MULTI_TDC}} and {{timeref|ref=_TEND_MULTI_TDC}}.
Multi-pulse blocks must have unique names, with first 3 letters being '''MUL''', e.g. {{ppgblock|block=MULTI_2}}, {{ppgblock|block=multi_RFGATE1}}, {{ppgblock|block=MulX}} are all acceptable.

=== Stdpulse Block ===

This block defines a pulse of standard width ([[#Pulse Block|Figure 3)]]. A Stdpulse Block is the same as a [[#Pulse Block]] except the width is a fixed value which is defined in the odb (see [[#Standard Pulse Widths]]). The state of the output signal will be reversed for the pulse width duration.

Stdpulse blocks take the following parameters (Table 8):
{| style="text-align: left; width: 80%; background-color: white;" border="3" cellpadding="2" cellspacing="2"
|+ Table 8 : Pulse Block Parameters
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
!ODB Key Name !! Type !! Default Value !! Required/Optional
|-
|time offset (ms) || DOUBLE || 0 || Optional
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|time reference || STRING[20] || end of previous block || Optional
|-
| ppg signal name || STRING[15] || no default; must be supplied || Required
|-
|}

==== Example 4: Standard Pulse Block ====
This example shows a standard pulse block with blockname {{ppgblock|block=STDPULSE1}}
[local:test]TITAN_ACQ> cd "/Equipment/Titan_acq/ppg cycle"
[local:test]TITAN_ACQ> ls stdpulse1
time offset (ms) 3.4
time reference T0
ppg signal name CH5

This example reverses the state of the PPG output signal "CH5" at an offset of 3.4ms from time reference {{timeref|ref=T0}} for a time given by the [[#Standard Pulse Widths|standard pulse width]]. Time references {{timeref|ref=_TSTART_STDPULSE1}} and {{timeref|ref=_TEND_STDPULSE1}} for this pulse will be defined automatically.

=== Pattern Block ===
This block allows the user to set the PPG output signals to a '''bit pattern'''. It is be useful for example to set all the bits to zero at the end of the ppg cycle. Instead of 15 transition blocks, one pattern block could be used. Pattern blocks take the following parameters (Table 9):
{| style="text-align: left; width: 80%; background-color: white;" border="3" cellpadding="2" cellspacing="2"
|+ Table 9 : Pattern Block Parameters
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
!ODB Key Name !! Type !! Default Value !! Required/Optional
|-
|time offset (ms) || DOUBLE || 0 || Optional
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|time reference || STRING[20] || end of previous block || Optional
|-
| bit pattern || DWORD || no default; must be supplied || Required
|-
|}

==== Example 5: Pattern Block ====
[local:test]TITAN_ACQ> cd "/Equipment/Titan_acq/ppg cycle"
[local:test]TITAN_ACQ> ls pattern_test -h
time offset (ms) 120
time reference T0
bit pattern 0xF0F0

This example sets the PPG output signals to the bit pattern shown 120ms after [[#Time references & Sequence of the blocks: T0|T0]]. The time reference {{timeref|ref=_TPATTERN_TEST}} will be defined automatically.

=== Delay Block ===
This block allows the user to maintain a '''bit pattern''' for a certain amount of time. It may be useful when programming loops, which sometimes need a minimal delay as a separator.
Delay blocks take the following parameters (Table 10):
{| style="text-align: left; width: 80%; background-color: white;" border="3" cellpadding="2" cellspacing="2"
|+ Table 10 : Delay Block Parameters
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
!ODB Key Name !! Type !! Default Value !! Required/Optional
|-
|time offset (ms) || DOUBLE || 0 || Required??
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|time reference || STRING[20] || end of previous block || Optional
|-
|}
The length of the delay is given by the time offset parameter.

==== Example 6: Delay Block ====
[local:test]TITAN_ACQ> cd "/Equipment/Titan_acq/ppg cycle"
[local:test]TITAN_ACQ> ls delay_eoc
time offset (ms) 1.5
time reference _TENDSCLR

This example provides a delay of 1.5ms after the end of the SCLR loop (referenced from {{timeref|ref=_TENDSCLR}}). The bit pattern remains unchanged.

=== Begin Loop Block ===
This block is the start of a loop. A loop name must be provided (i.e. BEGIN <loopname>). It MUST occur in the [[#Naming PPG Blocks|Block List]] BEFORE its associated END <loopname> block.
Every BEGIN <loopname> block must have an associated END <loopname> block. The loop name must be unique for each loop in the block list. Every BEGIN <loopname> block must have an associated END <loopname> block. The loop name must be unique for each loop in the block list.

Begin Loop blocks take the following parameters (Table 11):
{| style="text-align: left; width: 80%; background-color: white;" border="3" cellpadding="2" cellspacing="2"
|+ Table 11 : Begin Block Parameters
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
!ODB Key Name !! Type !! Default Value !! Required/Optional
|-
|time offset (ms) || DOUBLE || 0 || Optional
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|time reference || STRING[20] || end of previous block || Optional
|-
|loop count || INT || 1 || Required
|-
|}

User must name BEGIN LOOP blocks in ODB with a unique loop name. The first 5 letters must be "begin", e.g. {{ppgblock|block=BEGIN_2, begin_loop0, Begin_hvlooping}} are all acceptable. The loop name (which is required in the PPG file sent to the compiler) will be taken from the block name by stripping off the letters "BEGIN_", e.g. {{ppgblock|block=begin_hvlooping}} would have "hvlooping" as the loop name.

=== Time Reference within the loop ===
All transitions within a loop should use the begin_loop time reference (L1 in Figure 4), or the end of a variable pulse within the loop. They should not use the T0 reference.

=== End Loop Block ===
This block ends a loop. The <loopname> must be provided, matching that of the BEGIN <loopname>. Every END <loopname> block must have an associated BEGIN <loopname> block. The loop name must be unique for each loop in the block list. END_LOOP blocks in ODB are named with the first 3 letters being "end", and the rest matching the begin loop block name. e.g. {{ppgblock|block=END_2, end_loop0, End_start}} are all acceptable provided there exists a block named {{ppgblock|block=BEGIN_2, begin_loop0}} or {{ppgblock|block=begin_start}}.

In Figure 4, the time reference for the begin loop occurs at label "L1". This time reference would actually be called {{timeref|ref=_TBEG<loopname>}}, where loopname is the name of the loop.

[[Image:Loop.png|frame|center|Figure 4: Diagram of a Loop]]
<br clear=all>

The END <loopname> block MUST occur in the list of blocks in the ODB AFTER its associated BEGIN <loopname> block.
The time offset of the END block is assumed to be the end of the first loop (or if not supplied, is assumed to be at the end of the previous block. Note that loops can be nested, but two END blocks must be separated by at least a minimal delay. This is also true for two BEGIN blocks.

The automatic time-references generated are {{timeref|ref=_TEND_<blockname>_ONE}} (at the end of ONE loop) and {{timeref|ref= _TEND_<blockname>}} is at the end of ALL loops (as calculated by the configuration program). This time is shown as "E0" in Figure 4. The time between the end of one loop and the end of all loops is designated the "RESERVED" time. Transitions occurring within the first loop are assumed to be within the loop - any transitions occurring within the "reserved" time during which the rest of the loops will be running is not allowed, and an error message will occur. Therefore do not use {{timeref|ref=_TEND_<blockname>_ONE}} as a time reference for another pulse or transition, or that transition may be in the reserved time, generating an error. {{timeref|ref=_TEND_<blockname>}} is generated for debugging purposes only.

;NOTE: Users must be careful when ending a loop directly following a transition if [[#TDBLOCK pulses]] are enabled. In that case, transitions generate automatic TDCBLOCK pulses whose trailing edge follows a transition, but which do not generate automatic time references. Therefore a delay must be added by the user between a transition and the end loop block, to allow time for the TDCBLOCK pulse, otherwise the trailing edge of the TDCBLOCK pulse will occur during the reserved time, generating an error.

End Loop blocks take the following parameters (Table 12):
{| style="text-align: left; width: 80%; background-color: white;" border="3" cellpadding="2" cellspacing="2"
|+ Table 12 : End Block Parameters
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
!ODB Key Name !! Type !! Default Value !! Required/Optional
|-
|time offset (ms) || DOUBLE || 0 || Optional
|- style="vertical-align: top; background-color: whitesmoke; font-weight: normal;"
|time reference || STRING[20] || end of previous block || Optional
|-
|}

For non-nested loops, the END<loopname> block should use the time-reference defined by the equivalent "BEGIN<loopname>" block (or one of the time-references defined within the loop). For nested loops, the time reference should be from the end of an inner loop.

An END<loopname> block automatically defines a time reference equivalent to the BEGIN<loopname> parameter. For example, if the BEGIN<loopname> defined {{timeref|ref=_TBEGL0}} the END<loopname> automatically defines {{timeref|ref=_TENDL0}}. This value is a time reference to the end of ALL the loops.
So placing transitions after the end of all loops is easy using {{timeref|ref=_TENDL0}} as the reference.
Any other transitions occuring within the time taken for all the loops is flagged as an error.

==== Example 6: A Loop using PPG Blocks ====

<span style="color:#e600e6; font-style:italic">end_ramp</span>

The following example shows the PPG Blocks making up a loop. The Blocks {{ppgblock|block=begin_ramp}} and {{ppgblock|block=end_ramp}} are the begin and end of the loop named "ramp". {{ppgblock|block=begin_ramp}} is [[#Time references & Sequence of the blocks: T0|referenced by default]] from the end of the previous block (or T0 if there is no previous block). The transition block {{ppgblock|block=trans14A}} and pulse block {{ppgblock|block=pulse25}} are both within the loop, referenced to the {{ppgblock|block=begin_ramp}} [[#Automatic and user-defined time references|automatic time reference]] {{timeref|ref=_TBEGRAMP}}. The {{ppgblock|block=end_ramp}} is referenced by default from the end of the previous block, i.e. from the automatic time reference {{timeref|ref=_TEND_PULSE25}}.
<pre>
[local:cpet:S]Titan_acq>ls /Equipment/Titan_acq/ppg_cycle_32
begin_ramp
trans14A
pulse25
end_ramp

[local:cpet:S]Titan_acq>ls /Equipment/Titan_acq/ppg_cycle_32/begin_loop1
time offset (ms) 20
loop count 20

[local:cpet:S]Titan_acq>ls /Equipment/Titan_acq/ppg_cycle_32/trans14a
time offset (ms) 0
time reference _TBEGRAMP
ppg signal name CH14

[local:cpet:S]Titan_acq>ls /Equipment/Titan_acq/ppg_cycle_32/pulse25
time offset (ms) 0.003
time reference _TBEGRAMP
pulse width (ms) 0.003
ppg signal name CH25

[local:cpet:S]Titan_acq>ls /Equipment/Titan_acq/ppg_cycle_32/end_loop2
time offset (ms) 1
time reference
</pre>

=== Names Block ===

This block has been defined for use with EBIT or CPET's custom web page. It is usually placed after a SKIP block at the end of the Block List.

{| style="text-align: left; width: 80%; background-color: white;" border="3" cellpadding="2" cellspacing="2"
|+ Table 16 : Name Block
|- style="vertical-align: top; background-color: aliceblue; font-weight: bold;"
!Parameter (ODB key name) !!Type !!Default!! Required/Optional !! Explanation
|-
|Names[32] || STRING[32] Array|| none || Optional|| User-defined names of PPG Signals for Custom Webpage. Array length should reflect number of PPG Output signals used (max 32).
|}

=== Example 10: Name Block ===
The following example shows the names array for ebit experiment :
<pre>
[local:ebit:R]/>ls "/Equipment/TITAN_ACQ/ppg_cycle_mode_1f/names"
names
RFQ extraction
TSYBL:XCB4 (Default INJ)
EBIT Beam Line(SL,Q,Y:Default EXT)
(not connected) DT6 -- default high
BNG
flexible trigger
DT4 -- default low
extra XCB4
evap AFG trigger
not used -- evap cooling
DT4
not used -- afg sweep top
TITAN EC time stamp
flexible 1
flexible
flexible
</pre>

=== Blocks added automatically ===
Some blocks are (or may be) added automatically.

* A pattern block at T0 is added to set all the inputs initially to zero. This block will be removed if the user defines a pattern or other transition block at T0. So if the user does not want all inputs to be automatically set to zero when the PPG starts, a pattern block or transition must be added at T0.
* A halt operation is added at the end of the program.

File:Loop.png

2024-01-09T23:41:18Z

Bsmith:

File:Pulse.png

2024-01-09T23:40:37Z

Bsmith:

File:Trans.png

2024-01-09T23:40:10Z

Bsmith:

Template:Timeref

2024-01-09T23:39:37Z

Bsmith: Created page with "<noinclude> == Purpose == Show timerefs in purple, italic font == Usage == The {{Timeref|ref=_TPULSE_5}} time reference ... </noinclude> <span style="color:#0099e6; font-style:italic;">{{{ref|<time_ref>}}}</span>"

<noinclude>
== Purpose ==
Show timerefs in purple, italic font
== Usage ==
The {{Timeref|ref=_TPULSE_5}} time reference ...
</noinclude>
<span style="color:#0099e6; font-style:italic;">{{{ref|<time_ref>}}}</span>