PPG Building Blocks
Links
Introduction
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 cycling_framework.
The structure of the user's PPG program is stored in the ODB as a set of sub-directories within /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, 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 /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 /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 /Equipment/PPGCompiler/Settings/PPG clock (MHz), otherwise the timing of the output pulses will be incorrect, i.e.
| Input parameter name | Value | Type |
|---|---|---|
| PPG Clock (MHz) | 100 | FLOAT |
Standard Pulse Widths
Other values are defined (also in the input parameter area) which the user can change as required:
| 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 /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.
| Block Type * (click on links for definitions) |
Explanation | Example Blockname |
|---|---|---|
| TRANS | cause a channel transition (toggle between on and off, depending on the current state) | TRANS_EX |
| TURNON | ensure a channel is on | TURNON_EX |
| TURNOFF | ensure a channel is off | TURNOFF_EX |
| PULSE | a pulse of user-defined width | pulse_dac |
| MULTI | multiple pulses on the same channel a fixed time apart | multi_dac |
| STDPULSE | a pulse of a standard width | stdpulse_5 |
| PATTERN | sets a bit pattern | PatFF0E |
| DELAY | Delay for a time with existing bit pattern unchanged | DEL10 |
| TIME_REF | defines a time reference from which other blocks can be offset | timDacStart |
| BEGIN_LOOP | begin a loop | Begin_loop5 |
| END_LOOP | end a loop | 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 /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.
| Block Type | Example Blockname |
Automatically defined time reference names |
Example time references |
|---|---|---|---|
| Transition | TRANS_EX | _T<block name> | _TTRANS_EX |
| Turnon | TURNON_EX | _T<block name> | _TTURNON_EX |
| Turnon | TURNOFF_EX | _T<block name> | _TTURNOFF_EX |
| Pulse | pulse_dac | _TSTART_<block name>, _TEND_<block name> |
_TSTART_pulse_dac _TEND_pulse_dac |
| Multi | multi_dac | _TSTART_<block name>, _TEND_<block name> |
_TSTART_multi_dac _TEND_multi_dac |
| Stdpulse | stdpulse_5 | _TSTART_<block name>, _TEND_<block name> |
_TSTART_stdpulse_5 _TEND_stdpulse_5 |
| Pattern | PatFF0E | _T<block name> | _TPatFF0E |
| Delay | DEL10 | _T<block name> | _TDEL10 |
| Time_Reference | timDacStart | _T<block name> | _TtimDacStart |
| BEGIN_LOOP | Begin_loop5 | _TBEG<loop name> | _TBEGloop5 |
| END_LOOP | End_loop5 | _TEND<loop name>_ONE | _TENDloop5_ONE |
| _TEND<loop name> | _TENDloop5 |
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 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.
Time reference blocks take the following parameters (Table 4):
| ODB Key Name | Type | Default Value | Required/Optional |
|---|---|---|---|
| time offset (ms) | DOUBLE | 0 | Optional |
| time reference | STRING[20] | end of previous block | Optional |
All TIME_REF blocks in ODB must have the first 3 letters "tim", e.g.
TIME_2, t
ime_reference_define_t3,
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 time_t1 and time_t2, where time_t1 is referenced to T0, and automatically defines the time reference _TTIME_T1 (see Table 3). PPG Time Reference block time_t2 is then referenced to _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, 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.
Transition blocks take the following parameters (Table 5):
| ODB Key Name | Type | Default Value | Required/Optional |
|---|---|---|---|
| time offset (ms) | DOUBLE | 0 | Optional |
| 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 TRANS_tdc4 will define a time reference _TTRANS_TDC4. TRANSITION blocks must have unique names, with first 3 letters being TRA, e.g. TRANS_2, transition_RFGATE1, TraX are all acceptable.
Example 2: Transition Block
This example shows a transition block with blockname 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 _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 Blocks could perform the same function as a pulse block.
Pulse blocks take the following parameters (Table 6):
| ODB Key Name | Type | Default Value | Required/Optional |
|---|---|---|---|
| time offset (ms) | DOUBLE | 0 | Optional |
| time reference | STRING[20] | end of previous block | Optional |
| pulse width (ms) | DOUBLE | minimal delay | Optional |
| 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 PULSE_TDC will define the time references _TSTART_PULSE_TDC and _TEND_PULSE_TDC. PULSE blocks must have unique names, with first 3 letters being PUL, e.g. PULSE_2, pulse_RFGATE1, PulX are all acceptable.
Example 3: Pulse Block
This example shows a pulse block with blockname 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 _TTRANS_5 for a time of 0.005ms. It is assumed that _TTRANS_5 has been defined by the transition block in Example 2. A time references _TSTART_PULSE3 and _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):
| ODB Key Name | Type | Default Value | Required/Optional |
|---|---|---|---|
| time offset (ms) | DOUBLE | 0 | Optional |
| time reference | STRING[20] | end of previous block | Optional |
| pulse width (ms) | DOUBLE | minimal delay | Optional |
| ppg signal name | STRING[15] | no default; must be supplied | Required |
| rep count | INTEGER | no default; must be supplied | Required |
| 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 MULTI_TDC will define the time references _TSTART_MULTI_TDC and _TEND_MULTI_TDC. Multi-pulse blocks must have unique names, with first 3 letters being MUL, e.g. MULTI_2, multi_RFGATE1, MulX are all acceptable.
Stdpulse Block
This block defines a pulse of standard width (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):
| ODB Key Name | Type | Default Value | Required/Optional |
|---|---|---|---|
| time offset (ms) | DOUBLE | 0 | Optional |
| 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 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
T0 for a time given by the standard pulse width. Time references
_TSTART_STDPULSE1 and
_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):
| ODB Key Name | Type | Default Value | Required/Optional |
|---|---|---|---|
| time offset (ms) | DOUBLE | 0 | Optional |
| 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 T0. The time reference _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):
| ODB Key Name | Type | Default Value | Required/Optional |
|---|---|---|---|
| time offset (ms) | DOUBLE | 0 | Required?? |
| 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 _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 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):
| ODB Key Name | Type | Default Value | Required/Optional |
|---|---|---|---|
| time offset (ms) | DOUBLE | 0 | Optional |
| 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. 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. 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. END_2, end_loop0, End_start are all acceptable provided there exists a block named BEGIN_2, begin_loop0 or begin_start.
In Figure 4, the time reference for the begin loop occurs at label "L1". This time reference would actually be called _TBEG<loopname>, where loopname is the name of the loop.
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 _TEND_<blockname>_ONE (at the end of ONE loop) and _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 _TEND_<blockname>_ONE as a time reference for another pulse or transition, or that transition may be in the reserved time, generating an error. _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):
| ODB Key Name | Type | Default Value | Required/Optional |
|---|---|---|---|
| time offset (ms) | DOUBLE | 0 | Optional |
| 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 _TBEGL0 the END<loopname> automatically defines _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 _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
end_ramp
The following example shows the PPG Blocks making up a loop. The Blocks begin_ramp and end_ramp are the begin and end of the loop named "ramp". begin_ramp is referenced by default from the end of the previous block (or T0 if there is no previous block). The transition block trans14A and pulse block pulse25 are both within the loop, referenced to the begin_ramp automatic time reference _TBEGRAMP. The end_ramp is referenced by default from the end of the previous block, i.e. from the automatic time reference _TEND_PULSE25.
[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
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.
| 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 :
[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
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.