How-To: dm-unipz

Hinweise

Einleitung

Dies ist das How-To. Hintergrundinformation gibt es hier und hier. Das Gateway hat die Aufgabe, das zeitbasierte White Rabbit Timingsystem mit der eventbasierten UNILAC Pulszentrale (UNIPZ) zu verbinden. Bei UNIPZ wurde nichts geaendert, d.h. aus Sicht des UNILAC funktioniert die Kommunikation zwischen "UNILAC und SIS" wie bisher auch. Das Gateway dm-unipz verhaelt 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 Einstellmoeglichkeiten. 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.

Betrieb und Rufbereitschaft

Erste Diagnose

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

unipz-hkr-scope 2018-07-24.jpg
Abbildung: EVT_READY_TO_SIS (Ch3, magenta), TK Chopper (Ch2, cyan), SIS Bumper (Ch4, gruen), Strahltrafo (Ch1, gelb) und EVT_MB_TRIGGER (EXT, Triggereingang). Erklaerung 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.

  • Fuer eine Pruefung der erfolgreichen Synchronisation ist idealerweise eines beiden Signale - Chopper oder Bumper - erforderlich.
  • Stehen diese Signale nicht zur Verfuegung, 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 pruefen:
  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 unten)
  2. Diagnostic Logging: https://graylog.acc.gsi.de mit Suche nach "logsource:scuxl0223". Die Abbildung unten zeigt ein Beispiel.
  3. Diagnose UNIPZ siehe unten

dm-unipz logstash.jpg
Abbildung: Ausgabe in 'graylog'. 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

  • 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 Ausfuehrungen?
    • Werden verschiedene Patterns abwechselnd gespielt, so liegt dies moeglicherweise an unterschiedlichen Einstellungen fuer 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 naechsten Iteration gewartet werden.
    • die Quelle kann nicht auf Anforderung liefern, sondern kann nur periodisch in einem festgelegten Quellentakt liefern. Anmerkungen:
      • 'Quelle rechts' kann ausschliesslich 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 gehaengt wird. In diesem Fall entscheidet die Taktrate/Untersetzung der Quelle mit welcher maximalen Rate Strahl abgenommen werden kann
  • Warum muss gelegentlich laenger auf Strahl vom UNILAC gewartet werden (oder es gibt sogar einen Timeout)
    • Das liegt nicht an einer Schwebung zwischen SIS Zykluslaenge 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.
  • 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 pruefen, ob es dann besser wird
    • Es gibt komische Effekte, weil zusaetzlich noch ein anderer virtueller Beschleuniger periodisch in den TK geht. -> andere virtuellen Beschleuniger im TK nicht verwenden und pruefen, ob es dann besser wird
    • Der TK Chopper zuendet 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 muessen die Kollegen von LSA beheben
    • Die Ausfuehrung 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 unmittelbar nach Update und nicht erst nach 1 1/2 Tagen pruefen. Bei Fehler: Data Master auf alte Version zurueckrollen
  • Hilft bei Problemen ein Reboot/FPGA Reset/Powercycle des Gateway?
    • In der Vergangenheit hat das nie geholfen. Der Fehler lag immer woanders.

Weitere Diagnosemoeglichkeiten (auch fuer) Rufbereitschaft

Darstellung im Diagnostic Logging

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

dm-unipz:                  TRANSFERS                |                   INJECTION                     | DIAGNOSIS  |                    INFO   
dm-unipz:              n    sum(tkr)  set(get)/noBm | n(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 06(06/06),  964(0.146/   0/ 954 -> 9.979)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 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 injections withing 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 ...

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. Konfiguration des Gateway pruefen (Kommandozeilentool '-c'), Nach beheben der Ursache: Reboot Gateway.
Tabelle: Statusmeldungen, moegliche Fehlerursachen, Vorschlaege.

Kommandozeilentool

Das Kommandozeilentool ist auf der SCU des Gateways verfuegbar. Bewaehrt hat sich dmunipz-ctl dev/wbm0 -s1
Usage: dmunipz-ctl [OPTION] <etherbone-device> [COMMAND]

  -h                  display this help and exit
  -c                  display configuration of gateway
  -e                  display version
  -i                  display information on gateway
  -s<n>               snoop gateway for information continuously
                      0: print all messages (default)
                      1: as 0, but without info on ongoing transfers
                      2: as 1, but without info on transfers
                      3: as 2, but without info on status

  ebmdm    <mac> <ip> command sets DM WR MAC and IP for EB master (values in hex)
  flex     <offset>   command sets offset [ns] added to timestamp of READY_TO_SIS event (default 1500000 ns)
  uni      <timeout>  command sets timeout [ms] value for UNILAC (default 2000ms)
  tk       <timeout>  command sets timeout [ms] value for TK (via UNILAC, default 210 ms)
  IMPORTANT: values set by the above commands get applied by the 'configure' command

  configure           command requests state change from IDLE or CONFIGURED to CONFIGURED
  startop             command requests state change from CONFIGURED to OPREADY
  stopop              command requests state change from OPREADY to STOPPING -> CONFIGURED
  recover             command tries to recover from state ERROR and transit to state IDLE
  idle                command requests state change to IDLE

  reltk               command forces release of TK request at UNILAC
  relprep             command forces release of preparation request at UNILAC
  relbeam             command forces release of beam request at UNILAC

  diag                shows statistics and detailled information
  cleardiag           command clears FW statistics

Use this tool to control the DM-UNIPZ gateway from the command line
Example1: 'dmunipz-ctl dev/wbm0 ebmdm 0x00267b000401 0xc0a80a01' set MAC and IP of Data Master
Example2: 'dmunipz-ctl -i dev/wbm0' display typical information
Example3: 'dmunipz-ctl -s1 dev/wbm0 | logger -t TIMING -sp local0.info' monitor firmware and print to screen and to diagnostic logging
When using option '-s<n>', the following information is displayed
dm-unipz:                  TRANSFERS                |                   INJECTION                     | DIAGNOSIS  |                    INFO   
dm-unipz:              n    sum(tkr)  set(get)/noBm | n(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 06(06/06),  964(0.146/   0/ 954 -> 9.979)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 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 injections withing 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 ...
Report software bugs to <d.beck@gsi.de>
Version 0.7.1. Licensed under the LGPL v3.

Gateway SCU in BG2

dm-unipz scu-fp.jpg

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

SIS18 Injection Timing.jpg
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

dm-unipz sketch.jpg
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.

Expertenwissen

GIT

The gateway must follow the Data Master very closely. Thus, it typically resides in a branch that stems from the current data master branch.
  • Convention: branch is named dm-unipz_dietrich_< YYYY-MM-DD >
  • Example from May 2018: dm-unipz_dietrich_2018-may-22

Configuration

There is no FESA class. Everyting is done via a startup script. The script relies on the CLI dmunipz-ctl , that is available on the SCU (see above).

Configuration via Startup Script
There are three possibilities to modify the startup script dm-unipz_start.sh
  • recommended: via the git repo. Check //.../bel_projects/modules/dm-unipz/dmunipz-x86. Requires new deployment and reboot of host system.
  • for testing: on the ASL cluste. Check some path like /common/export/timing-rte/... . Requires reboot of host system.
  • hackish: on the SCU. Directly change script at /usr/bin/dm-unipz_start.sh. Just call the script to apply changes. This is not boot safe.

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

Very important: Change of Data Master (or PEXARIA in Data Master) requires a change of the configuration
Data Master via startup script
Edit the script and look for a line containing ebmdm

dmunipz-ctl dev/wbm0 ebmdm 0x00267b000455 0xc0a80b01

and change accordingly.

Via CLI dmunipz-ctl
Experts may modify everything during run-time on the SCU via the CLI dmunipz-ctl.
  • try dmunipz-ctl -h
  • try dmunipz-ctl dev/wbm0 -c to view the current settings. Before continuing, you may want to remember the output.
  • dmunipz-ctl dev/wbm0 stopop stops operation of the gateway
  • dmunipz-ctl dev/wbm0 < command > < value > ... sets new value(s)
  • dmunipz-ctl dev/wbm0 configure activates the new values
  • dmunipz-ctl dev/wbm0 startop brings the gateway back to state OPREADY

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

Build and Deployment

This recipe descripes how things work on the ASL cluster. There are two steps. First, building of binaries (firmware and CLI). Second, prepare 'nfsinit' for a specific SCU.

Remark: There is no dedicated FPGA image, the gateway uses the default SCU image of the current release. The startup script (called during nfsinit) replaces the firmware of the user lm32 during run-time.

Building and Copying
  1. checkout the relevant branch of bel_projects, see here
    • 2018-06-13: branch dm-unipz_dietrich_2018-may-22, commit 96eb89e
  2. here is the Makefile //.../bel_projects/modules/dm-unipz/Makefile
  3. try head Makefile to check the parameters of the Makefile
  4. build the Firmware and Software
    • DEV : try make MASP=YES PRO=NO PREFIX= all
    • PRO : try make MASP=YES PRO=YES PREFIX= all
    • (just in case: building on a non-ASL environment is as easy as for other eb-tools when using MASP=NO)
  5. deploy Firmware, Gateware and scripts
    • DEV : try make MASP=YES PRO=NO PREFIX= STAGING=/common/export/timing-rte/dmunipz-dev deploy
    • PRO : try make MASP=YES PRO=YES PREFIX= STAGING=/common/export/timing-rte/dmunipz deploy

nfsinit
  1. cd to the nfsinit folder of the relevant SCU
  2. create the relevent symbolic link
    • DEV try 30_dmunipz -> ../global/timing-rte-dmunipz-dev
    • PRO try 30_dmunipz -> ../global/timing-rte-dmunipz
    • note the target of the symbolic link and the folder names above

White Rabbit Console

This is not recommended for production.
[ruth@scuxl0815 ~]# eb-console dev/wbm0

Oscilloscope
EVT_READY_TO_SIS to WR Timing

dm-unipz jitter.jpg

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

dm-unipz jitter-mil.jpgFigure: 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 Januar 2021
Topic attachments
I Attachment Action Size Date Who Comment
SIS18_Injection_Timing.jpgjpg SIS18_Injection_Timing.jpg manage 101 K 01 Aug 2018 - 10:06 DietrichBeck Timing SIS18 Injetion
WREventAndMILEventsJPG.jpgjpg WREventAndMILEventsJPG.jpg manage 341 K 04 Jul 2017 - 12:08 DietrichBeck latency jitter of WR node
dm-unipz_MILReaction.JPGJPG dm-unipz_MILReaction.JPG manage 368 K 29 May 2017 - 12:37 DietrichBeck latency jitter of lm32 firmware
dm-unipz_jitter-mil.jpgjpg dm-unipz_jitter-mil.jpg manage 384 K 02 Aug 2018 - 08:40 DietrichBeck dm-unipz jitter via MIL TIFs
dm-unipz_jitter.jpgjpg dm-unipz_jitter.jpg manage 451 K 23 May 2018 - 14:31 DietrichBeck dm-unipz jitter
dm-unipz_logstash.jpgjpg dm-unipz_logstash.jpg manage 27 K 23 Jul 2018 - 13:30 DietrichBeck check logstash
dm-unipz_scu-fp.jpgjpg dm-unipz_scu-fp.jpg manage 72 K 23 May 2018 - 14:00 DietrichBeck SCU front panel
dm-unipz_sketch.jpgjpg dm-unipz_sketch.jpg manage 112 K 23 Jul 2018 - 14:02 DietrichBeck transfer timing
unipz-hkr-scope_2018-07-24.jpgjpg unipz-hkr-scope_2018-07-24.jpg manage 1 MB 02 Aug 2018 - 08:33 DietrichBeck HKR: Scope for Synchronization UNILAC->SIS
wrAndMilEvents_produciton.JPGJPG wrAndMilEvents_produciton.JPG manage 458 K 04 Jan 2018 - 14:45 DietrichBeck latency jitter of WR node in production system
Topic revision: r43 - 14 Jan 2021, DietrichBeck
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback