White Rabbbit UNILAC PZ (wr-unipz)

Introduction

"wr-unipz" is a component of the MIL-based UNILAC 'Pulszentrale' (UNIPZ). As a field-bus, it does not use the MIL 'Event' bus but a White Rabbit network. Logically, wr-unipz is identical and on the same level as the seven 'Pulszentralen' (PZ) of the UNILAC timing system. As for the other PZ, data supply and 50 Hz synchronization are provided through the 'Super Pulszentrale' (SPZ) of the UNILAC timing system. For technical and conceptual reasons, the UNILAC timing system and the GSI/FAIR General Machine Timing system (GMT) must use two distinct White Rabbit networks.

How-To

• WR-UNIPZ
  • operation - useful for collegues from operation, includes a list of error codes
  • coding, building and deployment - useful for developers
  • off-topic: some hints for Device Access - useful for newbies on the old control system, required info for modifying the Device Access part
• MIL-UNIPZ
  • some practical hints for diagnostics - explains also nomen for UNIPZ
• Users at UNILAC
  • identical interface as for the FAIR timing system
    • same timing receivers (SCU, Pexaria...)
    • same drivers, Etherbone tools, saftlib
  • differences
    • timing messages have a 'UNILAC dialect', see here
    • there are just UNILAC events and no such thing as CMD_SEQ_START ...

Documentation

• WR-UNIPZ
  • documentation
• MIL-UNIPZ
  • documentation by Peter Kainberger und Udo Krause (a bit out of date)
  • 'MIL timing': presentation by Udo Krause (consider this as an update to the documentation of UNIPZ)
  • how-to by DB

Overview

Figure: Integration of White Rabbit Pulszentrale into UNILAC Pulszentrale. Shown are the existing components Settings Management (grey box), Super Pulszentrale (light green box), Pulszentralen 1..7 (green boxes) and the new White Rabbit Pulszentrale (blue box). As well shown are MIL event bus lines (green arrows), a White Rabbit network (blue arrows) as well as connections from Super Pulszentrale to PZs (black arrows). Details see text.

Today (2020) the UNILAC is still operated using the 'old GSI control system' Device Access . The timing system is based on a so-called MIL Event Bus with a Pulszentrale (PZ) as master. UNILAC has seven timing areas with one PZ each. Thus, there are seven distinct MIL cables, one for each PZ. The seven PZs are coordinated via the Super Pulszentrale (SPZ), which has two tasks.

• It supplies the PZs with data. The data contain information for up to 16 independent virtual accelerators (VACC). For each VACC there are two distinct sets of data (called 'Kanäle'), one for normal operation and one for low intensity operation ('verkürzt', 'Profilgitterschutz'). In total the SPZ needs to provide 7 * 16 * 2 = 224 event sequences. Each sequence is a list of event data and a time offset relative to the beginning of a UNILAC cycle. SPZ transmits the data to the PZs using Device Access via the standard ACC network.
• SPZ and the PZs are interconnected via an internal MIL event bus. SPZ uses this internal bus for various purposes:
  • announce event: announces the virtual accelerator number that must be played for a specific PZ during the next cycle; there may be up to seven of these events per cycle (one for each PZ)
  • cycle start event: starts the next UNILAC cycle. Each cycle has a length of ~20ms (50 Hz); there is one event per cycle starting the event sequences at (up to) seven PZs simultaneously
  • service event: service events are played after the event sequence (at a PZ) has been completed, there is one event for each service event to be sent
  • synch data event: if new data have been supplied via Device Access, they will become active during the next cycle; this event is processed by all PZs

The White Rabbit PZ just behaves like the seven PZ. It is supplied via Device Access and is connected to the internal MIL Event Bus to receive the events from SPZ. There are two main difference to the seven PZs.

• there is only one White Rabbit network for all seven timing areas at UNILAC
• White Rabbit PZ uses the concept of an alarm based timing system unlike the seven PZs, that are event based

UNIPZ

Figure: Most simplified view on UNIPZ (upper part). It is a combination of a Super-UNIPZ and seven UNIPZ1..7. Shown are three UNILAC cycles A, B and C. Short red arrow: Beginning of a UNILAC cycle T1..T4. Blue arrows: MIL events from Super-UNIPZ. Green arrows and boxes: MIL events from UNIPZ1..7 to front-end computers. See text for more details.

The above figure shows a simple overview on UNIPZ. Each cycle has a length of approximately 20 ms (50 Hz). Cycles are synchronized to the 50 Hz mains frequency (not shown). A hardware logic follows the variation in the mains frequency slowly, thus UNILAC cycles may differ in length. In the figure above this is depicted as '50 Hz jump' (this will be important later).

UNIPZ consists of seven "Pulszentralen" PZ 1..7. Each is dedicated to a specific section in UNILAC and controls real-time activity in that section be sending so-called 'timing-events' over the 'MIL event bus'. The overall coordination of PZ 1..7 is controlled via the so-called 'Super PZ' (SPZ). For this, PZ 1..7 are connected to the SPZ via an internal MIL event bus and SPZ controls PZ 1..7 by sending events (over that internal bus).

PZ 1..7 get supplied with schedule data in a two-step process. First, schedule data is loaded 'offline' into shadow registers of PZ 1..7 (not shown). Second, schedule data in a shadow register is activated from SPZ by sending a 'synch_data' event to the relevant PZ.

Let's look at UNILAC cycle C in the above figure. As UNILAC supports up to 15 virtual accelerators and different settings for the beam chopper, this must be announced in the previous cycle B via an event 'PZ_1..7 (+ chop)' on the internal bus. Note, there is a separate event for each of the seven PZ 1..7. A UNILAC cycle is started, once SPZ sends a '50Hz_synch' event to the seven PZ 1..7; there is only one event for all PZs. This event is sent for each UNILAC cycle at a time indicated by short red arrows T1..4. Each of the seven PZ 1..7 immediately sends out an event 'prep_next_acc' to its section. Shortly after beginning of cycle C, the events are not time-critical and call for preparation of things happening in this cycle (left green box). Events later in the cycle are time-critical to about 1us (right green box).

While a cycle is running, SPZ may send 'service events' to one or more of PZ 1..7. Such service events will be played after the schedule in a PZ has been played. An exception is a service event for the so-called QQ cavity, which must be sent out immediately. There is only one service event per cycle and PZ (but I am not sure if a 'QQ service event' may be played additionally)

Concept of wr-unipz

The main conceptual problem is the following: What must be achieved is the transition from an event based to an alarm based system. But ...

An event based system triggers actions to happen now, whereas an alarm based system schedules actions to be executed in the future.

... this can't work out of the box.

At UNILAC however, the schedules are known prior to execution. Thus, a White-Rabbit-style Data Master is well suited, once it knows the schedule as the seven PZ 1..7 do, if (!) the time is known when a UNILAC cycle starts. Unfortunately, this is not known beforehand, as the start of each cycle is triggered by the '50Hz_synch' of the SPZ on-time. The solution is shown in the following figure.

Figure: Concept of wr-unipz (lower part). Dark orange boxes indicate when wr-unipz sends timing messages to the White Rabbit network. Dark orange arrows indicate how far in the future wr-unipz schedules actions. Pink arrows and boxes: Actions triggered by 'timing events'. See text for more details.

Let's assume the length dT of UNILAC cycles is unknown but constant over the three cycles A, B and C. In a time based system it is easy to timestamp T1 and T2. Then the time of the start of cycle C can be predicted

T3 = T2 + dT.

Now, wr-unipz is able to schedule the event 'prep_nxt_acc' and the non-critical events as soon as the SPZ sends the events 'PZ_1..7' via the internal event bus. This happens already in cycle B (left orange box). The remaining time critical events are sent once the event '50Hz_synch' is received from SPZ (right orange box). When wr-unipz schedules, it broadcasts timing messages via the White Rabbit network. The messages are received by the Timing Receivers (TR), where the messages are filtered and forwarded to ECA channels and stored. On-time, the TR generates timing events (pink boxes). For a description off the ECA, see here and article.

Scheduling of service events by wr-unipz is also straight forward as the length of the schedule received from SPZ is known. Only the 'QQ service event' suffers a small delay (see below).

Pitfalls

The concept presented has a few caveats shown in the following figure.

Figure: Potential coneptual problems. Caveats are indicated by orange text. Grey boxes indicated activity in the othe cycles A and B. Explanation see text.

50 Hz Jump (black text)

The 50 Hz synchronisation has the task of following the 50 Hz mains frequency. Thus, UNILAC cycles vary in length. This is indacted by the '50 Hz jump' in the figure above. The hampers the prediction for T3 as the model for prediction assumes constant length. This has the following consequences

• 'prep_nxt_acc' and non-critical events in White Rabbit based timing will have an offset to the MIL events sent by the seven PZ 1..7
• the time difference between the last non-critical and the first time critical event differs from the original schedule and is not exactly predictable

This is not a principle problem but must be kept in mind when checking coincidene between timing events between White Rabbit timing and MIL timing (otherwise this will drive you crazy).

Event Misorder due to 50 Hz Jump (orange text)

The model assumes that timing events at UNILAC are well separated. As a strict requirement, the time difference between the last non-critical and the first time-critical event shall be larger than the '50 Hz jump'. If not, the order of events is jeopardized.

At present it is assumed that all events < 2ms after the start of cycle are non time critical.

Magnitude of 50 Hz Jump

According to Ralph, the magnitude of the 50 Hz jump should be in the order of 1 us. The present (February 2019) firmware does simple diagnostics. Amongst other values, it records the maximum and minimum value of the '50 Hz jump'. After about 10 days of operation in the test setup (Programmentwicklungsraum) the values

• min: -109 us
• max: +140 us

have been recorded. This might be smaller in the production system. Still, this is a potential issue. See section measurements below.

Remark: Based on the observation above, the prediction algorithm has been changed and is now based on the average of the past 4 cycles.

Fire and Forget - Issue with Skipped 50 Hz Cycles.

wr-unipz begins scheduling timing messages ('prep_nxt_acc' and non-critical) for the relevant PZ 1..7 as soon as the corresponding event 'PZ_1..7' has been received from SPZ. This means, that event 'PZ_1..7' are a point of no return and all decisions for cycle C must have been taken as soon as the event has been received from SPZ (with exception of the service events).

However, the 50 Hz trigger module FX 202.021 measures the interval between consecutive 50 Hz triggers, which must be larger than 19.8 ms (see doc, section 'Der 50 Hz-Generator'. In case the value is smaller than 19.8 ms, UNIPZ skips the following 50 Hz cycle and the already announced virtual accelerator will be executed one 50 Hz cycle later.

This leads to the potential issue for timing events that are played based on the prediction from previous cycles. In the White Rabbit based timing system, these events will be scheduled about 20 ms earlier compared to the MIL based UNIPZ.

Potential 'Synch Data' Issue

A 'synch_data' event from SPZ activates inactive schedules in shadow registers. This is a potential problem, if the 'synch_data' event happens after the 'PZ1..7' events, as wr-unipz is an alarm based system and the Timing Receivers have already received the timing messages for the next cycle. Thus, if SPZ commits a virtual accelerator ('synch_data') in cycle A and schedules the same virtual accelerator already in cycle B, cycle B is messed up: It contains old 'prep_nxt_acc' and non-critical events but new time-critical events at the same time.

'QQ and A4 Lateness'

SPZ expects immediate execution of a service events for the QQ cavity and the Alvarez A4 section. But as White Rabbit provides an alarm based system, this is impossible. There are two options.

• wr-unipz schedules the timing message as soon as the service event is received. As a consequence it will be processed by the TRs ECA as quickly as possible. But there will be
  • an unknown delay < 1ms
  • the timing event at the front-end will be 'late' thus triggering an error condition
• wr-unipz schedules the timing message as soon as possible, but without causing a 'late event'. Then, there will be
  • a known offset = 500us
  • no error at the TR

As a fist solution, wr-unipz schedules the execution of these service events with an additional offset of 500us.

A More Complete View

Figure: A more complete view (but still not complet).

The figure above shows a more complete view, especially in cycle C. Gray boxes and arrows indicate part of other activity going on. Please note that the 'synch_data' activity shown in cycle A could also happen in cycle B or C. But I tried to avoid that complexity in that figure.

Proof-of-Pinciple Implementation

Status

A simple White Rabbit based timing system for UNILAC has been setup in 'Programmenttwicklungsraum'. It consists of the following:

• a White Rabbit switch
• an SCU as Data Master
• another SCU as TR lisening to UNILAC event on White Rabbit

With respect to the figures above, the firmware is implemented and feature complete and implements PZ1..7. There is a simple control program on the host system which allows to control and monitor vital properties.

A real schedule has been extracted from UNIPZ using a python script and written to a file. The schedule can be loaded to the firmware which listens to the internal MIL event bus.

Timing Messages are sent to the White Rabbit network and received via an SCU where they can be checked using the 'saft-ctl' CLI. A quick manual comparison to the original event tables of UNIPZ shows agreement, considering the '50 Hz jump' shifts all events within the first 2ms by a few us (compared to the events > 2ms).

Mapping

To get started, the following mapping from UNILAC properties to a timing message has been used.

UNILAC Property	Timing Message	Value	Remark
N/A	FID	same as GSI/FAIR
PZ 1..7	GID	448..454
evt number	EvtNo	ident
N/A	flags		don't use
virt acc	SID	ident
N/A	BPID		don't use
N/A	reserved		don't use
N/A	request no beam		don't use
N/A	virt acc		already in SID
flags Super PZ	parameter field (hi bits)	ident	bits no chopper (0x1), short chopper (0x2)
event data	parameter field (lo bits)	ident	bits rigid/hoch B_rho (0x2), dry (0x4), high current (0x8)

Table: Conversion of UNILAC properties to White Rabbit timing.

This mapping should be subject to a CCT & Hanno decision. However, it is very charming as it allows to use present tools for development without modification.

Measurements

Figure: Measurement setup. Color codes: hardware boxes (blue), outputs of 50 Hz synch unit (yellow), VME-TIFs (green) and WR (pink) and an oscilloscope (gray). HW boxes: FX 202.021 (50 Hz trigger unit synched to mains frequency), PZU ('Steuereineiten', SE), VME-TIF (MIL decoder in VME form factor), White Rabbit enabled hardware 'wr-...' (SCU). See text for details.

In the following measurements at the test system (Programmentwicklungsraum) are presented. For comparison, the timing section 'Alvarez' (PZU6) has been used.

Prediction of UNILAC Cycle Length

DEV
Statistics of the period of UNILAC cycle lengths has been measured using a scope connected to output '50 Hz 1' (FX 202.021) and '50 Hz 2a' (VME TIF).

Signal	Max [us]	Min [us]	Window [us]	sdev [us]
50 Hz 1	20051	19964	87	18
50 Hz 2a	20056	19972	84	18
'50 Hz jump'	--	--	109	--

Table: Variation of UNILAC cycle length and standard deviation. Data are taken within a few seconds (but not simultaneously). Details see text.

Figure: Variation of cycle length as function of cycle number (DEV). Red: Difference from the average cycle length. Blue: Difference between two consecutive cycles. Details see text.

Mean values of UNILAC cycle length variation are shown in the table above. As can be seen, the variation happens in a window of about 100us.

The figure above show individually recorded values based on the '50HZ-sync' event on the internal MIL bus. While the deviations of individual cycles from the mean value shown in red is 'small' it is interesting to note, that a positive deviation is frequently followed by a negative deviation in the next cycle (and vice versa). This might be due to a control loop mainly based on a differential algorithm. This leads to even higher cycle-to-cycle variation shown in blue. Unfortunately, this increases the uncertainty when predicting the start of the next UNILAC cycle (which is important for wr-unipz!).

As first counter-measure, wr-unipz predicts the start of previous cycles not only on the past, but on the average of the past four cycles. The variation of the prediction is in the same order as for the hardware signals, but slightly increased.

To conclude, UNILAC cycle-to-cycle length variation of up to 100 us is common feature and thus limits the predictive power. As a consequence the timing precision of all events within the first 2 ms of wr-unipz ist limited to about 50-100 us. However, the situation is different in the production system (see below).

PRO

Figure: Variation of cycle length as function of cycle number (PRO). Red: Difference from the average cycle length. Blue: Difference between two consecutive cycles.

As shown in the figure above, observed variations in cycle length in the production system (PRO) are much smaller than the ones observed in the developement system (DEV, see previos paragraph).

Precision of Timing System

Measurement	Signal I	Signal II	Offset [us]	Min [us]	Max [us]	Window [us]	sdev [us]	Comment
A	50 Hz 1 (HW)	50 Hz 2a (MIL)	+30.02	+29.49	+30.56	2.07	0.291
B	50 Hz 2a (MIL)	50 Hz 2b (MIL)	-2.30	-2.38	-2.28	0.10	0.024	(note the negative number)
C	50 Hz 2a (MIL)	evt 3a (MIL)	+28.03	+27.06	+28.94	1.88	0.402	EVT_PREP_NEXT_ACC (note the non-zero offset)
D	50 Hz 2a (MIL)	evt 3b (WR)	+25.80	-21.30	+73.20	94.50	19.960	EVT_PREP_NEXT_ACC (based on prediction of only one preceeding cycle)
E	50 Hz 2a (MIL)	evt 4a (MIL)	+13264.305	+13262.878	+13265.598	2.720	0.478	EVT_BEAM_ON
F	50 Hz 2a (MIL)	evt 4b (WR)	+13264.365	+13264.316	+13264.418	0.102	0.024	EVT_BEAM_ON
G	evt 4b (WR)	evt 4a (MIL)	-0.065	-1.43	+1.23	2.67	0.470	EVT_BEAM_ON

Table: Statistics of 'Signal I' compared to 'Signal II' measured using an oscilloscope. Details see text.

Measurements A
The Super-PZ is connected to the FX 202.021 hardware modules and distributes '50 Hz Sync' Events on the internal MIL bus. These events indicate the start of a UNILAC cycle. A VME TIF is connected to that internal bus.

• the '50 Hz sync' event is decoded ~30us later than the hardware pulse
• Super-PZ follows the signals from FX 202.021 closely and precisely
• window width ~2us

Measurements B
This is basically the same measurement as A, but taking the signal from the VME TIF at the internal bus as reference and using a MIL piggy on an SCU as TIF

• the MIL piggy decodes the signal ~2.3 us earlier than the VME TIF
• window width 100ns

Measurements C and D
Again the VME TIF on internal bus as reference. Here, the event EVT_PREP_NXT_ACC is used. This event is played at the beginning of each cycle. Thus, the timing of the WR system is limited by the predictive power of the UNILAC cycle, leading to a lousy precision of the events from the WR system.

• VME TIF in 'Alvarez' section
  • MIL transport and decoding takes ~28us
  • window width ~1.9us
• WR Timing Receiver
  • huge window width of ~100us
  • (this is due the limited predictive power of UNILAC cycle length)

Measurements E and F
Again the VME TIF on internal bus as reference. Here, the EVT_BEAM_ON is used which is late in the cycle. Thus, the precision of the WR system is based on precise timestamping of the 50 Hz events.

• VME TIF in 'Alvarez' section
  • window width ~ 2.7 us
• WR Timing Receiver
  • window width ~ 0.1 us

Measurement G
Here the EVT_BEAM_ON of the WR and MIL system are directly compared to each other. The result is consistent with the one of measurements E and F.

Conclusion

• in DEV, strong fluctuation of about 100 us are observed in the UNILAC cycle-to-cycle length
• in PRO, the observed fluctuations are significantly smaller
• precision
  • events at the beginning of a cycle (< 2ms): WR @ UNILAC is hampered by the limited predictive power of the UNILAC cycle length. It is assumed that precise timing is not required early in a UNILAC cycle: Maybe this is ok.
  • events later in the cycle (> 2ms): here the precision of the WR system seems to be more than an order of magnitude better than of the MIL timing system

Bits and Bites

PZ Numbers and Nomen

#	Nomen	Type	Name	Abbreviate	Description
1	GUR_ZZ	MIL	Quelle Rechts (Nord)	QR	Source feeding into HSI
1	GUR_ZD	WR	Quelle Rechts (Nord)	QR	Source feeding into HSI
2	GUL_ZZ	MIL	Quelle Links ( Süd )	QL	Source feeding into HSI
2	GUL_ZD	WR	Quelle Links ( Süd )	QL	Source feeding into HSI
3	GUN2ZZ	MIL	Quelle HLI	QN	Source feeding into HLI
3	GUN2ZD	WR	Quelle HLI	QN	Source feeding into HLI
4	GUN_ZZ	MIL	Hochladungsinjektor	HLI	one injector bevore Alvarez
4	GUN_ZD	WR	Hochladungsinjektor	HLI	one injector bevore Alvarez
5	GUH_ZZ	MIL	Hochstrominjektor	HSI	another injector bevore Alvarez
5	GUH_ZD	WR	Hochstrominjektor	HSI	another injector bevore Alvarez
6	GUA_ZZ	MIL	Alvarez (tanks)	AT	Alvarez
6	GUA_ZD	WR	Alvarez (tanks)	AT	Alvarez
7	GTK_ZZ	MIL	Transferkanal	TK	transfer from UNILAC to SIS18
7	GTK_ZD	WR	Transferkanal	TK	transfer from UNILAC to SIS18

Table: List of timing sections of UNILAC.

Events UNIPZ Internal Bus

The Super-PZ sends events to the seven PZ1..7 on an internal MIL bus.

• bit 0..7: special event numbers, see below
• bit 8..15: meaning depends on event number, see below

0xEvtNo	EvtName	Description	Format
0x1..7	UNIPZ_EVT_PZ1..7	announce or service event; the event number designates the PZ	see tables below
0x32	UNIPZ_EVT_SYNCH_DATA	commit event; a previously transferred event table becomes active	see table below
0x33	UNIPZ_EVT_50HZ_SYNCH	50 Hz trigger; the next UNILAC cycle starts NOW	see table below

Table: List of event numbers used on the internal bus of UNIPZ

Bits	Value	Description
15	0	THIS is an announce event
14	don't care	short chopper pulse, presently unused; implemented via concept of 'Kanäle', see bit 12
13	0..1	no chopper pulse
12	0..1	# of 'Kanal'; one bit is enough as we only have two 'Kanäle'
8..11	0..15	# of virtual accelerator
0..7	UNPZ_EVT_PZ1..7	# of 'Pulszentrale'; counting starts at '1'

Table: Format of announce events. This event type is used to announce what shall be played during the next cycle.

Bits	Value	Description
15	1	THIS is a service event
12..14	111 (bits 12..15: 0xf)	send service event EVT_MAGN_DOWN after the other events withing the same cycle
12..14	110 (bits 12..15: 0xe)	send service event EVT_AUX_PRP_NXT_ACC after the other events withing the same cycle
12..14	101 (bits 12..15: 0xd)	send service event EVT_AUX_PRP_NXT_ACC NOW (very special case for QQ @ 2019)
12..14	100 (bits 12..15: 0xc)	send service event EVT_UNLOCK_ALVAREZ NOW (very special case for A4 @ 2020)
8..11	0..15	# of virtual accelerator
0..7	UNPZ_EVT_PZ1..7	# of 'Pulszentrale'; counting starts at '1'

Table: Format of service events. This event type instructs the PZ to play a special additional event during a cycle.

Bits	Value	Description
8..15		don't care
0..7	UNIPZ_EVT_SYNCH_DATA

Table: Format of synch data events.

Bits	Value	Description
8..15		don't care
0..7	UNIPZ_EVT_50HZ_SYNCH

Table: Format of 50 Hz trigger events.

Events UNIPZ (User)

UNILAC uses event numbers in the range 0..255 (8 bit). Please have a look here (evt no 0..255).

Bits	Value	Description
15	0..1	'high current', 'Hochstrom' - correction in rf-systems needed
14	0..1	'dry' - UNILAC cycle runs without beam
13	0..1	'Hoch-B_rho', 'rigid beam' - low charge state; set power supplies for high magnet current
12		don't care
8..11	0..15	# of virtual accelerator
0..7	0..255	event number

Table: Format of 'timing events'.

Beam info

The previous section mentions some bits that give information on the current beam.

Info	Provided via	Source	real-time	Configured in Schedule	Description
No Chopper	Super PZ	PZU Interlock	x		prevents opening of chopper [1]
Short Chopper	Super PZ	via PZU Interlock	x		length of chopper pulse is reduced [2]
		(Operator selects 'Profilgitter')		(x)	implemented by switchig to a 2nd 'Kanal' that must be pre-configured by data supply
Hoch-B_rho	Schedule	Operator		x	rigid beam (info required for power supplies)
No-Beam	Schedule	Operator		x	UNILAC runs dry
High Current	Schedule	Operator		x	beam loading (info required for RF systems)

Table: Some information on beam properties. I (db) am not 100% sure this is correct.

[1] Another source for 'no chopper' is probably the modulbus interface to SIS18 (dry-run-flag).
[2] The operator selects the 'Profilgitterschutz-Taster'. Via MIL bus, this is transmitted to the interlock unit. The interlock status is analyzed by the Super PZ prior to each cycle.

-- DietrichBeck - 18 Aug 2020