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.