How-To: Gateway Data Master UNILAC Pulszentrale - Konfiguration und Rufbereitschaft

Hinweis Ein How-To zur Diagnose der UNILAC Pulszentrale gibt es hier.

Hintergrundinformationen

• here, focus auf UNIPZ
• 'Booster-Mode'
  • hier, Konzept
  • hier, Realisierung

A dedicated How-To is available here.

dm-unipz versus dm-unidm

'dm-unipz' is the interface between the White Rabbit based Data Master und the MIL-based UNILAC 'Pulszentrale'.

'dm-unidm' is hacky temporary interface betwenn the (Ring) Data Master and the (UNILAC) Data Master.

dm-unipz und dm-unidm unterscheiden sich nur durch die lm32 firmare, diese kann im nfs-init ausgewaehlt werden (siehe hier).

Einleitung

Das Gateway hat die Aufgabe, das zeitbasierte White Rabbit Timingsystem mit der eventbasierten UNILAC Pulszentrale (UNIPZ) zu verbinden. Bei UNIPZ wurde nichts geändert, d.h. aus Sicht des UNILAC funktioniert die Kommunikation zwischen "UNILAC und SIS" wie bisher auch. Das Gateway dm-unipz verhält sich aus Sicht der UNIPZ genauso wie die alte SIS Pulszentrale.

Logisch gesehen ist das Gateway ein Teil des Data Masters. Das Konzept des Gateway ist primitiv. Es gibt keine Einstellmöglichkeiten. Das Gateway nimmt nicht an der Solldatenversorgung teil und stellt keine Daten zur Verfuegung. Daten wie die Nummer des virtuellen UNILAC Beschleunigers sind Teil des LSA Schedules und werden zur Laufzeit vom Data Master verschickt. Das Gateway schreibt jedoch Daten ins Diagnostic Logging und sendet "opReady" Signale zum MASP.

Erste Diagnose

Fuer eine Diagnose kann - auch ohne Strahl - das Oszilloscope TEK2014 der Strahldiagnose im HKR links neben der SIS Konsole genutzt werden.

Abbildung: EVT_READY_TO_SIS (Ch3, magenta), TK Chopper (Ch2, cyan), SIS Bumper (Ch4, gruen), Strahltrafo (Ch1, gelb) und EVT_MB_TRIGGER (EXT, Triggereingang). Erklärung im Text.

Hier wird die komplette Kette der Synchronisation, beginnend vom EVT_READY_TO_SIS der UNILAC Pulszentrale, bis hin zu den Signalen von Chopper, Bumper und Strahltrafo dargestellt. Das obige Beispiel zeigt ein typisches Bild, jedoch ohne Strahl und Chopper. Vom Strahltrafo wird jedoch als Artifakt bereits das Signal des UNILAC Rahmenpulses aufgenommen. Weitere Details zur Timing der Injektion siehe hier.

• Für eine Prüfung der erfolgreichen Synchronisation ist idealerweise eines beiden Signale - Chopper oder Bumper - erforderlich.
• Stehen diese Signale nicht zur Verfügung, so kann das Oszilloscope mit Triggersource EXT getriggert werden. Der zeitliche Abstand zwischen EVT_READY_TO_SIS und dem Triggersignal muss bei erfolgreicher Synchronisation 10ms betragen.

Schnelltest Gateway

Kann kein Strahl vom UNILAC ins SIS transferiert werden, so ist Folgendes zu prüfen:

1. MASP, Nomen "U_DM_UNIPZ": Ist das Gateway 'ONLINE' sowie 'OP_READY'?
   • Ja: Gateway ist betriebsbereit.
     • Diagnose mit 'Diagnostic Logging' beginnen.
     • Diagnose UNIPZ beginnen.
   • Nein: Rufbereitschaft rufen; Powercycle: Problem behoben?
     • Ja: ok
     • Nein: Diagnostic Logging und entsprechend Fehlermeldung vorgehen (siehe hier)
2. Diagnostic Logging: https://logging.acc.gsi.de/ mit vordefinierte Suche "TOS PRO: Datamaster UNILAC Gateway" (host:scuxl0223). Die Abbildung unten zeigt ein Beispiel.
3. Diagnose UNIPZ für Experten siehe hier

Abbildung: Ausgabe in 'logging'. Die wichtigsten Infos sind eingekreist (1. virtueller Beschleuniger 2. Abstand EVT_READY_TO_SIS -> EVT_MB_TRIGGER, 3. Status). Bedeutung weiterer Werte siehe unten.

FAQ

• Neu für 2022: TK Chopper oder Bumper zünden nicht
  • Im Hinblick auf den Booster-Betrieb wurde das Zusammenspiel zwischen Solldatenversorgung, BSS und Gateway überarbeitet. Einige der Events vom Data Master wie zB die für Bumper und Chopper werden nun separat behandelt und nur dann gespielt, wenn tatsächlich Strahl (kann auch 'trockener' Strahl sein) vom UNILAC in den TK geliefert wurde.
  • 'Fehlen' diese Events, so ist zunächst zu prüfen, ob der gewünschte Beschleuniger an der UNILAC Pulszentrale entsprechend eingerichtet ist und läuft (Profilgitterschutz? Interlocks?).
• Neu für 2022: Nach Ausführung eines Booster-Patterns gibt es keinen Strahl für andere nachfolgende Pattern(s)
  • ein Fehler bei der Ausführung eines Booster-Patterns kann evtl Folgefehler für die Ausführung nachfolgender Patterns bewirken
  • zunächst Booster-Pattern anhalten, laufen dann die anderen Patterns wieder?
  • falls ja, liegt es vermutlich daran, dass der UNILAC für nicht für alle Anforderungen innerhalb des Booster-Patterns Strahl liefert
  • in diesem Fall muss entweder das Booster-Pattern 'repariert' oder auf die Ausführung des Booster-Patterns verzichtet werden
• Obwohl das Flag 'UNILAC kein Strahl' im ParamModi bzw. der Scheduling App nicht angewählt ist, läuft der Beschleuniger am UNILAC immer trocken
  • steht im Pattern der BEAM_MODE auf NO_BEAM?
  • falls ja: In diesem Beam Mode wird beim UNILAC Strahl immer trocken angefordert. Der Wert des Flags hat in diesem Fall keine Auswirkung.
• Wie kann man die Nummer des virtuellen Beschleunigers erkennen?
  • Diagnostic Logging -> Suche nach "logsource:scuxl0223" -> Abschnitt 'TRANS'. Sollwert und Istwert im obigen Beispiel: va( 4/ 4) .
• Wie kann man erfolgreiche Synchronisation erkennen?
  • Am Oscilloscope der Strahldiagnose im HKR, siehe oben.
  • Diagnostic Logging -> Suche nach "logsource:scuxl0223" -> Abschnitt 'INJ'. Istwert im obigen Beispiel -> 9.949)ms . Anmerkung: Sollwert [ms] = 10.000 - Chopper-Verzoegerung + UNILAC Verschiebung (Sollwerte werden in 'Paramodi' gesetzt).
• Warum 'springt' das Strahltrafosignal (bzw. der Wert im graylog) zwischen Ausführungen?
  • Werden verschiedene Patterns abwechselnd gespielt, so liegt dies möglicherweise an unterschiedlichen Einstellungen für Chopper-Verzoegerung und UNILAC Verschiebung in 'Paramodi'.
• Warum liefert der UNILAC den Strahl nicht unmittelbar nach der Anforderung durch das SIS
  • es dauert mindestens einen UNILAC Takt (20ms) bis die Pulszentrale eine Anforderung auswerten und entsprechend reagieren kann
  • der angeforderte virtuelle Beschleuniger steht nicht auf Anforderung, sondern ist stattdessen periodisch eingerichtet. In diesem Fall muss bis zur nächsten Iteration gewartet werden.
  • die Quelle kann nicht auf Anforderung liefern, sondern kann nur periodisch in einem festgelegten Quellentakt liefern. Anmerkungen:
    • 'Quelle rechts' kann ausschließlich periodisch gefahren werden
    • 'Quelle links' kann auch auf Anforderung gefahren werden
    • es kommt durchaus vor, dass ein virtueller Beschleuniger auf Anforderung an eine periodisch Quelle gehängt wird. In diesem Fall entscheidet die Taktrate/Untersetzung der Quelle mit welcher maximalen Rate Strahl abgenommen werden kann
• Warum muss gelegentlich länger auf Strahl vom UNILAC gewartet werden (oder es gibt sogar einen Timeout)
  • Das liegt nicht an einer Schwebung zwischen SIS Zykluslänge und Periode des Quellenpulses. Ursache ist vielmehr die Benutzung von Konditionierungsmaschinen z.B. in den UNILAC Bereichen HLI oder HSI. Diese Konditionierungsmaschinen haben selbst nach erfolgreicher Reservierung des TK immer Vorrang vor der Strahlanforderung der Experimentmaschinen zum SIS (wobei es hier wieder eine Besonderheit im Zusammenhang mit dem A4 gibt).
• Welche Fehler gab es in der Vergangenheit?
  • In der Scheduling App wurde kein oder ein falscher Virtueller Beschleuniger eingetragen. -> richtigen Wert eintragen
  • Es gibt komische Effekte, weil der entsprechende virtueller Beschleuniger am UNILAC nicht auf Anforderung sondern periodisch eingerichtet ist. -> auf Anforderung stellen und prüfen, ob es dann besser wird
  • Es gibt komische Effekte, weil zusätzlich noch ein anderer virtueller Beschleuniger periodisch in den TK geht. -> andere virtuellen Beschleuniger im TK nicht verwenden und prüfen, ob es dann besser wird
  • Der TK Chopper zündet nicht, weil dieser aufgrund eingefahrener Diagnoselemente (z.B. Gitter) verriegelt ist -> Gitter aus dem Strahl fahren
  • Im LSA Schedule ('dot file') steht der falsche Wert vabs="false" . -> das muss von LSA Kollegen auf "true" gesetzt werden
  • Im LSA Schedule hat der wartende Block vor dem flexwait einen Timeout < 10s -> das müssen die Kollegen von LSA beheben
  • Die Ausführung der Patterns im Data Master ist durcheinander geraten -> Data Master neu starten ('init' via FESA Explorer)
  • Beim Update des Data Masters vor zwei Tagen wurde ein neuer Fehler eingebaut ->
    • Funktion des Transfers immer unmittelbar nach Update prüfen und nicht erst nach 1 1/2 Tagen.
    • Bei Fehler: Data Master schnell auf alte Version zurückrollen und sofort prüfen, ob der Fehler damit wieder verschwindet.
• Hilft bei Problemen ein Reboot/FPGA Reset/Powercycle des Gateway?
  • In der Vergangenheit hat das nie geholfen. Der Fehler lag immer woanders.

Weitere Diagnosemoeglichkeiten

Darstellung im Diagnostic Logging

Die Darstellung im Diagnostic Logging entspricht der Ausgabe des Kommandozeilentools im 'Snoop-Modus'. Für eine Beschreibung des Ablaufs sowie Definition der Zeiten siehe unten.

Usage: dmunipz-ctl [OPTION] <etherbone-device> [COMMAND]
...
When using option '-s<n>', the following information is displayed
dm-unipz:                  TRANSFERS                |                        INJECTION                                | DIAGNOSIS  |                    INFO   
dm-unipz:              n    sum(tkr)  set(get)/noBm | multi/boost(r2s/sumr2s)  sum( init/bmrq/r2sis->mbtrig)          | DIAG margn | status         state      nchng stat   nchng
dm-unipz: TRANS 00057399,  5967( 13)ms, va 10(10)/0 | INJ 00006/00000(06/06),  964(0.146/   0/ 954 -> 9.979/17.512)ms | DG 1.453ms | 1 1 1 1 1 1 1 1, OpReady    (     0), OK (     4)
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' ' ' ' ' ' '        '          '    '       ' 
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' ' ' ' ' ' '        '          '    '       ' - # of 'bad status' incidents
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' ' ' ' ' ' '        '          '    '- status
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' ' ' ' ' ' '        '          ' - # of '!OpReady' incidents
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' ' ' ' ' ' '        '- state
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' ' ' ' ' ' '- beam (request) released
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' ' ' ' ' '- beam request succeeded
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' ' ' ' '- beam requested
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' ' ' '- beam preparation (request) released
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' ' '- beam preparation requested
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' ' '- TK (request) released -> transfer completed
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | ' '- TK request succeeded
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '   | '- TK requested
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '    - STATUS info ...
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |        '- remaining budget for data master and network  [ms] (> 1ms)
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '    |- DIAGNOSTIC info ...
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '      '- offset CMD_UNI_TCREL -> EVT_MB_TRIGGER [ms] (~16ms) 
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '        '- offset EVT_READY_TO_SIS -> EVT_MB_TRIGGER [ms] (~10ms) 
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '    '- offset beam request <-> EVT_READY_TO_SIS [ms] (< 2000ms)
          |            '      '   '         '  '  ' |         '     '  '  '      '     '    '- period required for acknowledgement of beam request at UNILAC [ms] (~20ms)
          |            '      '   '         '  '  ' |         '     '  '  '      '     '- period required for init of beam request ('DM Schnitzeljagd', ~0.2ms)
          |            '      '   '         '  '  ' |         '     '  '  '      '- total period required for injection [ms]
          |            '      '   '         '  '  ' |         '     '  '  '- # of received EVT_READY_TO_SIS since last sequence (should equal number of injections; if larger, another virtAcc to TK at UNILAC is present)
          |            '      '   '         '  '  ' |         '     '  '- # of received EVT_READY_TO_SIS during transfer (should equal the number of injections)
          |            '      '   '         '  '  ' |         '     '- # of booster injections within transfer
          |            '      '   '         '  '  ' |         '- # of multi-multi injections within transfer
          |            '      '   '         '  '  '  - INJECTION info ...
          |            '      '   '         '  '  '- 'no beam' flag
          |            '      '   '         '  ' # of virtAcc delivered by UNILAC (get value)
          |            '      '   '         '- # of virtAcc requested from UNILAC (set value)
          |            '      '   '- period required for acknowledgement of TK request at UNILAC [ms] (< 210ms)
          |            '      '- period required for transfer [ms] (including all injections)
          |            '- # of transfers
           - TRANSFER info ...

When using command 'debug_on', the following data is injected into the local ECA
FID: 0xc GID: 0x0afe EVTNO: 0x0fa0 - 'deadline': requested execution time stamp @DM, 'Other': address of TS @ DM
FID: 0xc GID: 0x0afe EVTNO: 0x0fa1 - 'Other': address of control register @ DM     , 'Param': data written to CR
FID: 0xc GID: 0x0afe EVTNO: 0x0fa2 - 'deadline': valid time of command    @ DM     , 'Other': address of command @ DM, 'Param': command data (first part)
FID: 0xc GID: 0x0afe EVTNO: 0x0fa3 - 'Other': address of write index @ DM          , 'Param': write index

Report software bugs to <d.beck@gsi.de>
Version 0.8.12. Licensed under the LGPL v3.

Fehlermeldungen, Ursachen und Massnahmen

Status Bits	Meldung	Ursache
0	OK	Die letzte Aktion (z.B. TK Reservierung) wurde erfolgreich ausgefuehrt. Alles gut.
1	an error occured	generische Fehlermeldung. Deutet auf einen schweren Fehler hin. Reboot oder Powercycle Gateway
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 ausserhalb 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 Data Master. Evtl Loesung 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 Gateway.
6	IP received via DHCP does not match local config	Die eigene IP Adresse ist anders als erwartet. Moeglicherweise laeuft das Gateway auf der 'falschen' SCU?
7	EB read via WR network timed out	Lesen von Data Master dauert laenger als 2s. Gibt es Netzwerkfehler (gmt-status Webseite, Icinga)? Powercycle Data Master. Evtl Loesung 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	Das Gateway befindet sich im Fehlerzustand und versucht selbstaendig wieder in den Zustand opReady zu gelangen. Das klappt nur, wenn die Fehlerursache verschwindet.
10..15	reserved
16	UNILAC refuses TK request	der angeforderte virtuelle Beschleuniger kann vom UNILAC nicht bedient werden. UNILAC: Interlock durch Diagnoseelemente. Scheduling App: falsche Wert fuer virtueller Beschleuniger
17	UNILAC TK request timed out	Timeout bei der Vorbereitung des TK. Der angeforderte virtuelle Beschleuniger am UNILAC ist vermutlich auf 'inaktiv' eingestellt.
18	UNILAC refuses beam request	der angeforderte virtuelle Beschleuniger kann vom UNILAC nicht bedient werden.
19	UNILAC refuses to release TK request	Fehler bei der Ruecknahme der TK Anforderung
20	UNILAC refuses to release beam request	Fehler bei der Ruecknahme der Strahlanforderung
21	something went wrong with write/read on the MIL devicebus	Schreib/Lesefehler beim MIL Devicebus zwischen BG2 und LSB6. Devicebuskabel gesteckt? Powercycle Gateway probieren. Sonst: Diagnose UNIPZ durch FEE, Diagnose Devicebus durch HEL.
22	UNILAC signals 'request not ok'	siehe "UNILAC refuses TK request".
23	UNILAC beam request timed out	Strahlanforderung wird vom UNILAC nicht bestaetigt.
24	received EVT_READY_TO_SIS with wrong virt acc number	von UNIPZ wurde ein Strahl mit falscher Beschleunigernummer geliefert. Unklare Situation: Fehlersuche zusammen mit Experten der UNILAC Pulszentrale. Evtl Loesung erst durch Spezialist am Folgetag.
25	violation of safety margin for data master and timing network	Schreiben auf Data Master dauert laenger als 500us. Falls das Problem dauerhaft besteht, WR Netzwerk pruefen.
26	received EVT_READY_TO_SIS in MIL FIFO but not via TLU -> ECA	Zeitstempelung des Events schlug fehl. Pruefen ob kurzes LEMO Kabel zwischen MIL Piggy 'I/O 1' und Eingang 'B1' gesteckt ist.
27	TS from TLU->ECA does not coincide with MIL Event from FIFO	Zeitstempelung des Events nicht eindeutig. Pruefen, ob das Problem auch dann noch besteht, wenn nur noch ein virtAcc auf Anforderung in den TK geht.
28	Data Master: Q not empty	Kommando Queue das Gateway ist nicht leer. Data Master oder Schedule kaputt. Data Master neu starten ('init' via FESA Explorer). Schedule pruefen.
29	received 'late event' from Data Master	'late event' von Data Master. Data Master oder Schedule sind kaputt. Data Master neu starten ('init' via FESA Explorer.)
30	TK is not reserved	Das ist nur eine Warnung der Diagnose. Das Gateway selbst ist bzgl des Transfers stateless. Tritt das staendig auf, so ist das ein moeglicher Hinweis auf 'Data Master oder Schedule kaputt'. Data Master neu starten ('init' via FESA Explorer). Schedule pruefen.
31	beam request did not succeed within 10s timeout at DM	Strahl konnte nicht rechtzeitig angefordert/geliefert werden. Falls das Problem dauerhaft besteht: Data Master neu starten ('init' via FESA Explorer).
32	t(EVT_MB_TRIGGER) - t(EVT_READY_TO_SIS) = 10ms	Synchronisation scheint nicht geklappt zu haben. Operateure: Einstellung UNILAC pruefen; Rufbereitschaft: graylog auf vorausgegangene Fehler pruefen; Data Master neu starten ('init' via FESA Explorer); Diagnose UNIPZ vornehmen.
33	timeout while waiting for EVT_READY_TO_SIS	trotz erfolgreicher Strahlanforderung kommt kein Event von UNIPZ. Unklare Situation: Fehlersuche zusammen mit Experten der UNILAC Pulszentrale. Evtl Loesung erst durch Spezialist am Folgetag.
34	t(EVT_MB_TRIGGER) - t(CMD_UNI_BREQ) < 10ms	EVT_MB_TRIGGER kommt frueher als erlaubt: Data Master oder Schedule kaputt. Pruefen, ob im Schedule 'vabs=true' (LSA Kollegen) oder der wartende Block einen Timeoutwert von 10 Sekunden hat (LSA Kollegen). Sonst Data Master neu starten ('init' via FESA Explorer).
35	unexpected event	unerwartets Event: Data Master oder Schedule sind kaputt. Rufbereitschaft: Data Master neu starten ('init' via FESA Explorer). Schedule pruefen.
36	invalid address of block for Data Master	'dynpar0/1' Adressen evtl ungueltig. Data Master oder Schedule sind kaputt. Rufbereitschaft: Data Master neu starten ('init' via FESA Explorer).
37	Data Master unreachable	Data Master kann vom Gateway nicht erreicht werden. Evtl Fehlkonfiguration der Switche im White Rabbit Netzwerk. Konfiguration des Gateway pruefen (Kommandozeilentool '-c'), Nach beheben der Ursache: Reboot Gateway.

Tabelle: Statusmeldungen, moegliche Fehlerursachen, Vorschlaege.

Gateway SCU in BG2

Abbildung: I/O1 ist als TIF konfiguriert und generiert bei EVT_READY_TO_SIS einT TL Signal welches via Lemo Kabel auf Eingang B1 gelegt wird. Wurde ein EVT_READY_TO_SIS mit der korrekten 'Beschleunigernummer; gempfangen, wird via Software eine Diagnosepuls auf Ausgang I/O2 generiert. Das OLED dient zur primitiven Statusanzeige: State "opReady", status "OK" virtueller Beschleuniger "6", Zahl der bisherigen Transfers "1481" und status des laufenden Transfers "1 1 0 1 1 1" (die Bits haben die gleiche Bedeutung wie im Kommdozeilentool).

Hintergrundinformation

SIS 18 Timing der Injektion

Abbildung: Timing der SIS18 Injektion. Schwarze durchgezogene Pfeile: Abhaengigkeit der Zeitberechnung. Farbige gestrichelte Pfeile: 'Delay' aufgrund von Setzwerten, wird auf Geraeteebene realisiert. Blitzsymbole markieren den Zeitpunkt des Beginns einer Aktion eines Frontends, welches durch ein Event angestossen wird.

Ablauf Synchronisation

Abbildung: Dargestellt von links nach rechts ist der Ablauf der Synchronisation, mit 'Reservierung TK', 'Strahlanforderung', 'Synchronisation' und 'Pruefung'. Events im neuen Timingsystem (MIL Timing) sind mit durchgezogenen blauen (roten) Pfeilen gekennzeichnet. Kommunikation via White Rabbit Netzwerk (MIL Device Bus) ist mit gestrichelten blauen (roten) Pfeilen dargestellt. Der magentafarbene Pfeil deutet den Synchronisationsvorgang selbst an und der gelbe Kasten den Moment des Strahltransfers. Im oberen Teil sind die Zeitdauern markiert, welche vom Gateway ins 'Diagnostic Logging' geschrieben werden.

Hinweis: EVT_READY_TO_SIS (rot/magenta) sowie der Strahltransfer (gelb) sind mit der gleichen Farbkodierung auf dem Oscilloscope im HKR zu bewundern.

Kommandozeilentool

Das Kommandozeilentool ist auf der SCU des Gateways verfuegbar.

Hilfe siehe dmunipz-ctl -h

Bewaehrt hat sich dmunipz-ctl dev/wbm0 -s1

Aber: Es handelt sich um das selbe Binary wie das, welches das Logging macht. D.h. Das Binary beinhaltet den MASP Emitter. Das kann zu Problemen beim MASP fuehren, weil das MASP das Vorhandensein zweier MASP Emitter zum selben Geraet als Fehler erkennt. Folgende Optionen.

1. Anstatt das Kommandozeilentool zu nutzen, im Diagnostic Logging schauen; https://logging.acc.gsi.de/ -> Load -> TOS PRO: Datamaster UNILAC Gateway . Das Ausgabe ist die selbe wie im Kommandozeilentool. Die Spalten sind unten erklaert.
2. Das Gateway aus dem MASP rauszunehmen. Entweder
   1. Tobias Habermann bitten, den Check auf 'doppelte Emitter' fuer das Gateway zu deaktivieren, oder
   2. den HKR bitten, dass Gateway im MASP vorruebergehend zu maskieren.

Ich persoenlich schaue eigentlich nur noch ins Diagnostic Logging (siehe oben).

NFS-Init

Below are examples for nfs-init configurations for the SL7 ramdisk. In both cases, dm-unidm is used. Changing between dm-unidm and dm-unipz only requires the rename the link 30_.....-config.

INT

ll 
total 4
lrwxrwxrwx 1 me    bel 49 Sep  5  2023 10_timing-rte -> ../global/timing-rte-tg-fallout-v6.2.0-no-graylog
lrwxrwxrwx 1 me    bel 29 Feb  6  2023 20_dmunipz-dev_dmunipz-tools -> ../global/timing-rte-db-yocto
lrwxrwxrwx 1 me    bel 29 Jun 10 08:43 30_dmunipz-dev_dmunidm-fel0090-int-config -> ../global/timing-rte-db-yocto
                                          ^^^^^^^^^^^      ^^ ^^^^^^^ ^^
                                                    |        |       |   |
                                                    |        |       |   |- environment
                                                    |        |       |- (Ring) Data Master node
                                                    |        | - two options, a: 'dmunidm' communication with UNILAC DM' b: 'dmunipz' communication with legacy UNIPZ
                                                    |- path where nfs-init will find stuff 
lrwxrwxrwx 1 me    bel 29 Feb  6  2023 40_dmunipz-dev_dmunipz-int-systemd -> ../global/timing-rte-db-yocto

PRO

ll 
total 4
lrwxrwxrwx 1 me       bel 49 Sep  5  2023 10_timing-rte -> ../global/timing-rte-tg-fallout-v6.2.0-no-graylog
lrwxrwxrwx 1 me       bel 29 May 24  2023 20_dmunipz_dmunipz-tools -> ../global/timing-rte-db-yocto
lrwxrwxrwx 1 me       bel 29 Nov  7  2023 30_dmunipz_dmunidm-tsl017-pro-config -> ../global/timing-rte-db-yocto
lrwxrwxrwx 1 me       bel 29 May 24  2023 40_dmunipz_dmunipz-pro-systemd -> ../global/timing-rte-db-yocto

Code, Build, Deployment

Code is here: bel_projects/tree/.../modules/dm-unipz

For branch and hash of the current version check the logbook

For building and deployment check the comments given at the top of the 'Makefile'

Example for building and deployment for PRO (assuming target system runs SL7 ramdisk)

make clean                                                                  // clean
make MASP=YES ENV=pro SYSENV=ACC7 PREFIX= all                               // builds software, firmware and generate nfs-init scripts
make PREFIX= SYSENV=ACC7 STAGING=/common/export/timing-rte/dmunipz deploy   // copies stuff to location where nfs-init will find it

Expert Knowledge

Configuration via Startup Script

The entire configuration of the is contained in a script named dm-unipz_start.sh. That script performs the following.

• bring possibly resident firmware into a safe state and clean up ECA
• ...
• upload new firmware to the user lm32 and setup ECA
• ...
• configure the MAC and IP addresses of DM and gateway on the White Rabbit network
• ...

N.B. If a Data Master is replaced, the Startup Script must be changed. Presently (2024) this is implemented by selecting the startup script via nfs-init (see here).

Example Configuration

[ruth@scuxl0815 ~]# dmunipz-ctl dev/wbm0 -c
dm-unipz: the values below are applied if the gateway becomes 'CONFIGURED'
dm-unipz: flexOffset 1500000 ns, uniTimeout 2000 ms, tkTimeout 210 ms
dm-unipz: EB Master (DM   ): mac 0x00267b00abcd, ip 192.168.123.123

Oscilloscope

EVT_READY_TO_SIS to WR Timing

Figure: Jitter measurement including the full stack. Shown are TTL signals from the MIL event decoder (yellow, SCU I/O1), the firmware generated TTL signal (purple, SCU I/O2) and a TTL signal from a White Rabbit Timing Receiver (cyan) that is generated upon an event from the Data Master. For details see text.

The figure above shows a measurement of a the "full stack" relevant here. The sequence is the following:

1. a VDHL generated TTL signal from the MIL decoder is emitted at I/O1 instantly, if a MIL Event "READY_TO_SIS" from UNIPZ is received (yellow signal). Ramark: Use a LEMO 'Y-Piece' to split the signal. At the scope, set termination to 1 M-Ohm.
2. the TTL signal is routed to input B1 where it is timestamped by the Time Stamp Latch unit (TLU) and the Event Condition Action unit (ECA) of the SCU (not shown)
3. internally, the gateway adds 1.5ms to this timestamp and sends this time via an Ethernet frame to the Data Master via the White Rabbit network (not shown)
4. in case of 'no error', the SCU emits a pulse on I/O2 (purple signal)
5. the Data Master continues scheduling events starting at the time embedded in the Ethernet frame (not shown)
6. here, the Data Master schedules one event exactly 8.5 later (not shown)
7. a White Rabbit based Timing Receiver has been configured to emit a TTL signal upon the event scheduled by the Data Master (cyan)
8. (the requirement is, that the cyan signal is generated 10 ms after the yellow signal with a precision of 1 us).
9. the oscilloscpe measures the skew between the cyan and yellow signals
   • mean value
     • set-value: 10000.000us
     • get-value: 10000.134us
     • diff: 0.134us
   • min/max value
     • min: 10 ms - 5 ns
     • max: 10 ms + 205 ns
     • window: 0.210ns
   • standard deviation is 88 ns

EVT_READY_TO_SIS to MIL Timing

Figure: Jitter measurement including the full stack and including MIL Timing. Shown are two signals from MIL TIFs, EVT_READY_TO_SIS (magenta) and EVT_MB_TRIGGER (yellow).

'Tk Chopper' and 'Bumpers' play an important role for SIS18 injection. Both devices are triggered via MIL Timing, which is generated from White Rabbit timing. The measurement shown has been done in the main control room 'HKR' using a fixed installation of two MIL TIF modules. The following is observed.

• mean value
  • set-value: 9980.0us ('Paramodi')
  • get-value: 9984.1us (this measurement)
  • diff: 4.1us
• min/max value
  • min: 9981.6us
  • max: 9986.8us
  • windows: 5.2us
• standard deviation is 1.2us

Summary: The values are ok, but signifcantly worse than the ones observed using WR timing only. Needs to be investigated. Suggest re-measurement in BG2.

-- DietrichBeck - 14 November 2024