PPG Building Blocks

Links

• TITAN page
• TITAN DAQ General Documentation
• PPG ODB Block Structure

Introduction

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

TABLE 1 List of Block Types acting on PPG signals

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.

TABLE 3 Automatically generated time references for each block

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.

Figure 1: Defining a Time Reference

Time reference blocks take the following parameters (Table 4):

Table 4 : Time Ref Block Parameters

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.

Figure 2: Two Transitions

Transition blocks take the following parameters (Table 5):

Table 5 : Transition Block Parameters

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.

Figure 3: Pulses

Pulse blocks take the following parameters (Table 6):

Table 6 : Pulse Block Parameters

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

Table 7 : Multi Pulse Block Parameters

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

Table 8 : Pulse Block Parameters

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

Table 9 : Pattern Block Parameters

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

Table 10 : Delay Block Parameters

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

Table 11 : Begin Block Parameters

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.

Figure 4: Diagram of a 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):

Table 12 : End Block Parameters

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.

Table 16 : Name Block

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.