How-To: White Rabbit UNILAC PZ (wr-unipz) - Betrieb

Betrieb und Rufbereitschaft

Kurzversion

• keine Einstellungen fuer Betrieb notwendig
• nach SCU Reset evtl Neuversorgung via MIL Pulszentrale (click).

Einleitung

WR-UNIPZ ist ins alte Kontrollsystem integriert. Dies bedeutet, dass die Schnittstelle nicht FESA, sondern eine Device Access Klasse ist. Hinweis: Die Nomen in Device Access sind hier beschrieben.

WR-UNIPZ wird weder von den Operateuren noch von der Datenversorgung/LSA direkt bedient oder versorgt. Das bedeutet:

• eine Datenversorgung durch den Betrieb / Operateure ist nicht notwendig. Einzige Ausnahme: Einmalige Neuversorgung nach Neustart des Frontends (siehe unten)
• WR-UNIPZ wird ausschliesslich und direkt von der UNILAC Superpulszentrale mit Daten versorgt (analog zu den MIL Pulszentralen 1..7).

Neuversorgung Erzwingen

Grundsätzlich wird wr-unipz immer durch die Super-Pulszentrale mit Daten versorgt und auf dem aktuellen Stand gehalten. Ein Sonderfall ist eine Neuversorgung, welche zB nach dem Neustart der SCU erforderlich ist. Eine solche Neuversorgung kann durch das Ausfuehren der Call-Property 'cupdpzud' an der Super-Pulszentrale vorgenommen werden.

Abbildung: Im Ausnahmefall kann eine Neu-Versorgung von wr-unipz über die Super-Pulszentrale ausgeführt werden.

Status: Diagnostic Logging

1. diagnostic logging aufrufen, --> "All Messages"
2. Oben rechts bei "Saved Searches" --> "DB UNIPZ (WR)" auswählen

Abbildung: Ausgabe in 'graylog'. Es werden die Meldungen aus Device-Access sowie Fehlermeldungen des Frontends angezeigt (falls es Fehler gibt).

Status: Prophelper

Anstelle des FESA Explorers wird also der Prophelper verwendet; letzterer muss auf einer ASL Maschine gestartet werden, z.B. [user@asl735 ~]$ prophelper & . Die Nomen entsprechen denen der sieben MIL-Pulszentralen, lediglich der letzte Buchstabe 'C' muss durch ein 'D' ersetzt werden. Beispiel: GUR_ZC (MIL) -> GUR_ZD (WR).

Abbildung: wr-unipz mit dem Prophelper. Interessant ist die Standard-Property rstatus (blau) sowie die Property rdiag (rot). Beschreibung siehe Text.

Die obige Abbildung zeigt die zwei relevante Properties

• rstatus
  • bit 0..7 sollen auf Standardwerten sein; zeigt bit 6 'HW Error' einen anderen Wert als 'no', so liegt ein schwerer Fehler vor
  • bit 8, sollte den Wert '1' haben
  • bit 9..32 sollten den Wert '0' haben
  • bit 8..32 entsprechen den status bits 0..24 aus der Tabelle unten; Beispiel: Bit 8 gesetzt = 'OK'
• rdiag
  • nCycles: Anzahl der ausgeführten UNILAC Zyklen; ein Zyklus hat eine Laenge von etwa 20ms
  • fUni: aktuelle Zyklusfrequenz des UNILAC [Hz]; der Wert sollte in etwa 50Hz betragen
  • fMsg: aktuelle Rate der Event Messages fuer alle Timingbereiche [Hz]; im normalen Betrieb werden Raten von ~ 2-3 kHz beobachtet
  • nLate: late messages; Anzahl der Timingnachrichten, die nicht mer rechtzeitig versendet werden konnten; der Wert sollte 0 betragen (bzw. sich nicht ändern)
  • dtMin: minimale Zeit zwischen Versenden der Timingnachricht und der gewünschten Ausführungszeit [us]; der Wert sollte 500us nicht unterschreiten
  • dtMax: maximale Zeit zwischen Versenden der Timingnachricht und der gewünschten Ausführungszeit [us]; der Wert sollte ~19ms betragen
  • cycJmpMin: minimale Abweichung zwischen dem erwarteten und gemessenen Zeitpunkt der UNILAC Zyklen; der Wert sollte im einstelligen negativen Mikrosekundenbereich liegen
  • cycJmpMax: maximale Abweichung zwischen dem erwarteten und gemessenen Zeitpunkt der UNILAC Zyklen; der Wert sollte im einstelligen positiven Mikrosekundenbereich liegen
  • Anmerkung: die Werte cycJmpMin und cycJmpMin beschreiben die Drift der UNILAC Pulszentrale von Zyklus zu Zyklus aufgrund von Schwankungen der 50 Hz Netzfrequenz

Weitere Diagnosemöglichkeiten (auch fuer) Rufbereitschaft

Darstellung CLI im Diagnostic Logging

Die Pulszentralen-SCU ermittelt kontinuierlich Diagnosedaten und schreibt diese ins Graylog. Diese kann man sich im graylog zB ueber den Suchstring "message:wrunipz" anzeigen lassen.

Die Darstellung im Diagnostic Logging entspricht der Ausgabe des Kommandozeilentools im 'Snoop-Modus'.

wr-unipz:        cycles      virtAcc        PZ   |         DIAGNOSIS      |                 INFO           
wr-unipz: STATUS      n 0....5....A....F 0.....6 |     fUni  fMsg nLate T |   state      nchng stat   nchng
wr-unipz: ST 0054834398 0010010111000011 1111111 |DG 49.972 02335 00000 0 | OpReady    (     0), status 0x00000001 (     0)
                      '                '       ' |        '     '     ' ' |       '          '                   '       ' 
                      '                '       ' |        '     '     ' ' |       '          '                   '       '- # of 'bad status' incidents
                      '                '       ' |        '     '     ' ' |       '          '                   '- status value ('1' is OK)
                      '                '       ' |        '     '     ' ' |       '          '- # of state changes
                      '                '       ' |        '     '     ' ' |       '- state
                      '                '       ' |        '     '     ' '- '1': transaction in progress
                      '                '       ' |        '     '     '- # of late messages
                      '                '       ' |        '     '- average message rate [Hz]
                      '                '       ' |        '- average UNILAC cycle rate [Hz]
                      '                '       '- '1': PZ is active
                      '                '- '1': vacc is played
                      '- # of UNILAC cycles

Fehlermeldungen, Ursachen und Massnahmen

Status Bits	Meldung	Ursache
0	OK	Die letzte Aktion wurde erfolgreich ausgefuehrt. Alles gut.
1	an error occured	generische Fehlermeldung. Deutet auf einen schweren Fehler hin. Reboot oder Powercycle SCU
2	a timeout occured	timeout. Falls das Problem dauerhaft besteht: Meldung im Diagnostic Logging analysieren.
3	some value is out of range	ein Wert ist außerhalb des gueltigen Bereichs. Falls das Problem dauerhaft besteht: Meldung im Diagnostic Logging analysieren.
4	an Etherbone error occured	ein Schreib- oder Lesebefehl via Etherbone schlug fehl. Gibt es Netzwerkfehler (gmt-status Webseite, Icinga)? Powercycle SCU. Evtl Lösung erst durch Spezialist am Folgetag.
5	DHCP request via WR network failed	Keine IP via dem White Rabbit Netzwerk erhalten. Nach beheben der Ursache: Reboot SCU.
6	IP received via DHCP does not match local config	Die eigene IP Adresse ist anders als erwartet. Möglicherweise läuft die Firmware auf der 'falschen' SCU?
7	EB read via WR network timed out	Lesen via Etherbone dauert länger als 2s. Gibt es Netzwerkfehler (gmt-status Webseite, Icinga)? Powercycle SCU. Evtl Lösung erst durch Spezialist am Folgetag.
8	White Rabbit: not in 'TRACK_PHASE'	White Rabbit nicht in 'TRACK_PHASE'. Schwerer Fehler. Rufbereitschaft: WR Kabel gesteckt, WRS ok, etc.
9	trying auto-recovery from state ERROR	Die Firmware befindet sich im Fehlerzustand und versucht selbständig wieder in den Zustand opReady zu gelangen. Das klappt nur, wenn die Fehlerursache verschwindet.
10..15	reserved
16	a timing messages is not dispatched in time	eine 'timing message' konnte nicht rechtzeitig ins White Rabbit Netzwerk gesendet werden. Tritt der Fehler häufig auf, sollte die Ursache erforscht werden (fehlerhafte Eventtabelle etc.)
17	a timing messages is dispatched unreasonably early (dt > UNILACPERIOD)	eine 'timing message' wurde > 20ms vor deren Ausführungszeitpunkt ins White Rabbit Netzwerk geschickt. Das ist unerwartet.
18	transaction failed	das Laden einer aktualisierten Eventtabelle in die Firmware ist fehlgeschlagen
19	an error on MIL hardware occured (MIL piggy etc...)	die MIL Hardware konnte nicht richtig konfiguriert oder angesprochen werden. SCU ohne MIL-Piggy? Falsche Gateware?
20	no MIL events from UNIPZ	es werden keine MIL Events vom internen Bus der Super Pulszentrale (SPZ) empfangen, auch kein '50 Hz Sync'. Kabelbruch? SPZ außer Funktion?
21	received MIL Event with wrong virt acc number	die Nummer des auszuführenden virtuellen Beschleunigers macht keinen Sinn
22	violation of safety margin for sending message to the timing network	die 'timing message' kann möglicherweise nicht mehr rechtzeitig zugestellt werden
23	received a MIL event via MIL FIFO but not via TLU -> ECA	ein MIL event wurde auf dem MIL Piggy empfangen, aber die Zeitstempelung schlug fehl. Prüfen ob kurzes LEMO Kabel zwischen MIL Piggy 'I/O 1' und Eingang 'B1' gesteckt ist.
24	TS from TLU->ECA does not coincide with MIL Event from FIFO	es besteht keine Korrelation zwischen empfangen MIL Event und dem Ergebnis der Messung des Zeitstempels; irgendwas ist durcheinander
25	TS from TLU->ECA and MIL Events are out of order	der Zeitstempelung fand statt bevor das dazugehörende MIL Event empfangen wurde; irgendwas ist durcheinander

Tabelle: Statusmeldungen, mögliche Fehlerursachen, Vorschläge.

SCU bei LSB6

Abbildung: I/O1 ist als TIF konfiguriert und generiert beim Empfang von MIL Events ein TTL Signal welches via Lemo Kabel auf Eingang B1 gelegt wird. Wurde ein MIL Event detektiert, wird via Firmware eine Diagnosepuls auf Ausgang I/O2 generiert.

Diagnose auf ACO Frontends

Normale Frontends (SCU oder Digitizer als Timing Receiver)

Hier kann das Kommandozeilenwerkzeug saft-uni auf einer beliebigen (am WR-Netzwerk angeschlossenen) SCU verwendet werden. Beispiele:

[ruth@scuxl0815-snooper ~]# saft-uni tr0 usnoop 1
   # cycle:      QR      QL      QN     HLI     HSI      AT      TK
        21:       6    (IQ)       2      S2       6      S2        
        22:    (IQ)                    (HF)                        
        23:    (IQ)               5      N5                        
        24:       6                    (HF)       6                
        25:    (IQ)               2     NS2             NS2        
        26:    (IQ)                    (HF)                        
        27:       6               5      N5       6                
        28:    (IQ)                    (HF)                        
        29:    (IQ)               2     NS2             NS2        
...

[ruth@scuxl0815-snooper ~]# saft-uni tr0 snoop 2
..................
vacc   QR   QL   QN   HLI  HSI  AT   TK  rate flags
   0                                    
   1                                    
   2              X    X         X      24.50 
   3                                    
   4                                    
   5              X    X                 1.00 N
   6                                    
   7    X                   X            1.75 
   8              X    X         X      24.50 
   9         X              X    X    X  1.00 H
  10                                    
  11                                    
  12                                    
  13                                    
  14    X                               23.25 
  15                                

White Rabbit UNILAC Pulszentrale

Hier kann das Kommandozeilenwerkzeug wrunipz-ctl verwendet werden.

Die Benutzung dieses Werkzeugs kann die Performance von WR-UNIPZ beeinflussen und darf nur von den Experten benutzt werden.

[ruth@scuxl4711-wrunipz ~]# wrunipz-ctl dev/wbm0 diag
common: diags ...                                             // (allgemeiner Teil..., identisch fuer alle Firmware Projekte von Dietrich)
firmware boot at      : 2020-04-17 15:17:45 TAI               // Zeitpunkt des Firmware boot
diagnostics reset at  : 2020-04-24 02:32:13 TAI               // Zeitpunkt des letzten Reset der Diagnose
version               : 000104                                // Firmware Version, hier 00.01.04
mac                   : 0x00267b000384                        // White Rabbit MAC
ip                    : 192.168.000.101                       // White Rabbit IP
used shared mem [byte]: 21948                                 // Groesse des benutzten Bereiches im Dual Ported RAM (Maximalgroesse kann z.B. via 'eb-info -w dev/wbm0' ermittelt werden)
state (# of changes)  : OpReady    (0)                        // aktueller Betriebszustand (in Klammern: wie of sich der Zustand geaendert hat)
# of transfers        : 000000000000                          // N/A
# of injections       : 000000000000                          // N/A
status of act transfer: 0x0                                   // N/A
sum status (# changes): 0x1 (0)                               // Summenwort der Status Bits (in Klammern: wie of sich das 'OK-Bit' geaendert hat)
overall status        : OK                                    // Beschreibung der gesetzten Bits (hier ist nur das Bit '0' gesetzt: OK)

wr-unipz: statistics ...                                      // (wr-unipz spezifischer Teil, auch via PropHelper verfuegbar)
# of cycles           : 0023632874                            // Anzahl der ausgefuehrten UNILAC Zyklen
# of messages         : 0842275657                            // Anzahl der gesendeten Messages
# of late messages    : 0000000000                            // Anzahl der Messages, die zu spaet versendet wurden
dt min [us]           : 000519.8                              // Minimale Differenz zwischen Versandzeitpunkt und Ausfuehrungszeitpunkt [us]
dt max [us]           : 019265.0                              // Maximale Differenz zwischen Versandzeitpunkt und Ausfuehrungszeitpunkt [us]
cycle jump min [us]   : -00005.5                              // Minimal Differenz zwischen erwartetem und tatsaechlichen Zeitpunkt eines Zyklusstarts [us]
cycle jump max [us]   : 000006.5                              // Maximale Differenz zwischen erwartetem und tatsaechlichen Zeitpunkt eines Zyklusstarts [us]

Background and Further Reading

"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

-- DietrichBeck - 17 November 2021