ChopperControlInterface
0 Offene Fragen
- Wie können die Interlock Cups angesteuert werden?
1 Aufgaben des ChopperControlInterfaces
- Einsammeln der langsamen Interlocks
Das Einsammeln der langsamen Interlocks und Summenbildung zu Chaininterlocks geschieht via mini-masp, so wie schon jetzt am SIS. Es muss lediglich eine neue Schnittstelle von mini-masp zum ChopperControlInterface implementiert werden.
- Register der Choppersteuerung beschreiben, die zu deren Betrieb nötig sind (und bisher von PZUI versorgt wurden)
Die Choppersteuerung selbst wird nicht erneuert. Das ChopperControlInterface muss in jedem Puls Register der Choppersteuerung beschreiben. Wenn dies zu spät geschieht, dann schlägt ein watchdog in der Choppersteuerung an, und sorgt dafür, dass der Chopper kein Strahl durchläßt. Der Watchdog hat einen Timeout von 25ms.
- Ignorieren von Interlocks hinter eingefahrenen Cups
Wir erachten diese Funktion des alten Systems als "convenience" und die Umsetzung ist bis auf weiteres verschoben (jedenfalls nicht 2024). Anstatt Interlocks hinter eingefahrenen Cups zu ignorieren ist es möglich den Beschleuniger nur bis zur Cup zu planen.
- Einfahren von "Interlock-Cup" wenn der Chopper eine Fehlfunktion hat
Minimal für 2024 muss ein Interlock einer der Chopper zum Einfahren der entsprechenden Cup führen.
2 Schnittstellen Uebersicht
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
Nicht korrekt in dem Bild: PG/Emi-Schutz aktiv kommt nicht von LSA Datenversorgung.
In dem Bild sind die Schnittstellen des ChopperChopperControlInterface dargestellt. Komponenten, die zwar relevant sind, aber nicht direkt mit dem ChopperControlInterface kommunizieren, haben schraffierten Hintergrund. Bis auf die Ansteuerung der Interlock Cups sind die Schnittstellen klar. Die folgenden Kapitel behandeln die Schnittstellen zu den anderen Komponenten (im Uhrzeigersinn, angefangen bei Timing).
Das Bild zeigt ein leicht vereinfachtes Modell des Unilac. In einem Puls können bis zu 3 Strahlen beschleunigt werden. Nur zwei der drei können je einen der beiden Chopper, GUH2BC1L oder GUN3BC1L, passieren. Die Choppersteuerung benötigt also in jedem Puls die Information über den Strahlweg dieser beiden Strahlen.
Wenn das ChopperControlInterface auf WR-Timingevents in den Timinggroups der beiden Chopper reagiert kann aus dem jeweiligen Timingevent der Chainindex, der Chain, die momentan den jeweiligen Chopper passiert, extrahiert werden. Im folgenden wird, der Einfachheit halber, von "Chainindex des Choppers" gesprochen
Ausserdem muss dem ChopperControlInterface der Strahlweg aller eingeplanten Chains bekannt gemacht werden. Dafür wird von LSA eine Liste von Partricletransfers datenversorgt. Das ist ählich wie die Datenversorgung von mini-masp, der auch für jede Chain den Strahlweg (als Liste von Particle Transfers) mitgeteilt bekommt (allerdings ist die Situation weniger kompliziert als bei mini-masp, z.B. muss dem ChopperControlInterface nicht mitgeteilt werden, wenn eine Chain ausgeplant wird).
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
siehe unten: Zuerst war nicht klar, ob Chainmultiplexing oder Beamprocessmultiplexing benutzt wird. Entscheidend ist, daß es einen Index gibt über den der Strahl(weg) identifiziert werden kann. Auch unten ist weiter von Chains die Rede, auch wenn kein Chainmultiplexing benutzt wird.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Da die Register auch dann rechtzeitig beschrieben werden müssen wenn gar kein Strahl produziert wird, wird als trigger wird ein Event benötigt, das in jedem Puls gespielt wird. Das ist der Fall für Event #255.
Allerdings hat Event #255 kein NOBEAM Flag. Event #16 wird gespielt in allen Chains in denen Strahl sein kann und enthält das NOBEAM Flag. Event #16 kommt zuerst, kurz danach #255. (Besprechung mit H.H. am 12.08.: #255 hat doch das NOBEAM flag, siehe auch siehe auch
https://www-acc.gsi.de/wiki/ProjectMgmt/MappingWrMilSisEsrUnilac#A_5_Decision).
Die Abfolge der timing events ist hier zu sehen:
https://www-acc.gsi.de/wiki/pub/Machines/MachineUNILAC/UNILAC%20timig%20essentials%202023-02-27.pdf
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
ist das bild in dem pdf das richtige? aktuell?
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
In FESA hört ein Device nur auf Timingevents aus einer Timinggroup. Das ChopperControlInterface muss auf beide Events in den Timinggroups der beiden Chopper reagieren.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
In der aktuellen Saftlib 2 werden Software Callbacks von Events nicht unbedingt in der richtigen Reihenfolge abgearbeitet. In der Saftlib 3 ist die Reihenfolge garantiert, vorausgesetzt die Conditions sind in der gleichen Signalgroup (Info von MR). Die Reihenfolge der Ausführung der RTActions in FESA hängt noch von mehr Faktoren ab. Nachtrag: Das war relevant, als wir noch davon ausgegangen sind, daß das ChopperControlInterface sich auf mehrere Events registrieren muss und die Reihenfolge deren Abarbeitung entscheidend war. Das ist jetzt nicht mehr der Fall.
4 Bedeutung der einzelnen Bits
Im folgenden ist die Bedeutung der einzelnen Register beschrieben. Entscheidend für das ChopperControlInterface ist, wie die entsprechende Information (die im alten System an der Pulszentrale direkt verfügbar war) eingesammelt werden kann. Die tatsächliche Sortierung nach Hardware-Registern ist im letzten Abschnitt gezeigt.
Die Bezeichnung der Aus-/Eingänge im Code der Interlocksteuerung und im Code der Choppersteuerung stimmt glücklicherweise größtenteils überein. Um die Bits einfacher grep-bar zu machen, werden in den Tabellen trotzdem beide Benennungen aufgelistet (die ersten beiden Spalten; wichtig: die Namen im vhd-Code sind nicht case-sensitiv). Die dritte Spalte (Bedeutung) übernimmt den Kommentar aus dem Code der Interlocksteuerung. Einzelne Einträge sind zwar konsistent im Choppercontrol- und PZUI-Code, stimmen aber nicht mehr mit dem überein, was tatsächlich angeschlossen ist (z.B.
Maskierung Strahlanforderung UU
stimmt sicher nicht mehr).
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
Alle Einträge in den Tabellen nochmals prüfen sofern es Einfluss auf die Logik des ChopperControlInterface hat.
4.1 Strahlweg
Die Information über den Strahlweg geht in fast alle Bits ein. Die folgenden Bits hängen nur vom Strahlweg ab.
PZUI |
ChopperControl |
Bedeutung |
Register |
# |
Particle Transfer |
IQ_R_UH |
Qu_R_HSI |
beam from IQ-R to HSI |
StrahlwegReg |
0 |
|
IQ_L_UH |
Qu_L_HSI |
beam from IQ-L to HSI |
StrahlwegReg |
1 |
|
HSI_UA |
HSI_ALV |
beam from HSI to Alvarez |
StrahlwegReg |
2 |
|
HLI_UA |
HLI_ALV |
beam from HLI to Alvarez |
StrahlwegReg |
3 |
|
Mask_Anf_X0 |
Mask_Anf_X0 |
Maskierung Strahlanforderung X0 |
AnforderMaske |
0 |
|
Mask_Anf_X1 |
Mask_Anf_X1 |
Maskierung Strahlanforderung X1 |
AnforderMaske |
1 |
|
Mask_Anf_X2 |
Mask_Anf_X2 |
Maskierung Strahlanforderung X2 |
AnforderMaske |
2 |
|
Mask_Anf_X3 |
Mask_Anf_X3 |
Maskierung Strahlanforderung X3 |
AnforderMaske |
3 |
|
Mask_Anf_X4 |
Mask_Anf_X4_5 |
Maskierung Strahlanforderung X4 |
AnforderMaske |
4 |
|
Mask_Anf_X6 |
Mask_Anf_X6 |
Maskierung Strahlanforderung X6 |
AnforderMaske |
5 |
|
Mask_Anf_X7 |
Mask_Anf_X7 |
Maskierung Strahlanforderung X7 |
AnforderMaske |
6 |
|
Mask_Anf_X8 |
Mask_Anf_X8 |
Maskierung Strahlanforderung X8 |
AnforderMaske |
7 |
|
Mask_Anf_Y7 |
Mask_Anf_Y7 |
Maskierung Strahlanforderung Y7 |
AnforderMaske |
8 |
|
Mask_Anf_Z7 |
Mask_Anf_Z7 |
Maskierung Strahlanforderung Z7 |
AnforderMaske |
9 |
|
Mask_Anf_Z6 |
Mask_Anf_Z6 |
Maskierung Strahlanforderung Z6 |
AnforderMaske |
10 |
|
Mask_Anf_UU |
Mask_Anf_UU |
Maskierung Strahlanforderung UU |
AnforderMaske |
11 |
|
Mask_Anf_M1 |
Mask_Anf_M1 |
Maskierung Strahlanforderung M1 |
AnforderMaske |
12 |
|
Mask_Anf_M2 |
Mask_Anf_M2 |
Maskierung Strahlanforderung M2 |
AnforderMaske |
13 |
|
Mask_Anf_M3 |
Mask_Anf_M3 |
Maskierung Strahlanforderung M3 |
AnforderMaske |
14 |
|
Mask_Anf_SIS |
Mask_Anf_SIS |
Maskierung Strahlanforderung SIS |
AnforderMaske |
15 |
|
@ChopperControl
Damit schnelle Interlocks dem richtigen Chopper zugeordnet werden können, müssen - anders als vielleicht sonst üblich - Verzweigungen von Ziel in Richtung Quelle berücksichtigt werden. Zum Beispiel kommt Strahl im TK auf jeden Fall aus dem Alvarez. Strahl im Alvarez kommt entweder aus dem HSI oder HLI.
Außerdem verarbeitet die Choppersteuerung die Strahlanforderungen der Experimentierplätze. Die Mask_Anf_* bits werden von der Choppersteuerung mit dem Anforder-Register gefaltet, um zu ermitteln, ob vom tatsächlichen Strahlziel Strahl angefordert ist. D.h. es wird ein Summen-Anforderungsbit
Off_Anforderung_Out
gebildet. Das einzige Strahlziel, das nicht von Alvarez bedient wird, ist UU, dessen Anforderung + Maske gesondert in
Off_UU_Out
zusammengefasst sind.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
UU ist jetzt UCW. Das macht aber für die Logik keinen Unterscheid. Nach wie vor ist UCW das einzige Strahlziel in der Liste, das nicht von Alvarez bedient wird.
Die Bits können im voraus pro Chain berechnet werden und ergeben sich pro Puls aus der Kombination (ODER) von den beiden Chains, die die beiden Chopper passieren.
Pro Chain ergeben sich die ersten 4 bits aus Kombinationen von PTs. Kommt zum Beispiel in einer Chain ein PT aus dem HSI und ein PT aus dem Alvarez vor, dann ist für die Chain das Bit HSI_UA gesetzt. Die Mask_Anf_*-Bits werden gesetzt wenn in der Chain der entsprechende PT vorkommt.
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
PTs in die tabelle eintragen
In einer Chain kann nur maximal ein Mask_Anf_*-Bit gesetzt sein. HSI_UA und HLI_UA sowie IQ_R_UH und IQ_L_UH schliessen sich gegenseitig aus (sowohl pro Chain als auch pro Puls). Beim Kombinieren der Bits von den beiden Chains kann jedes der Bits nur in maximal einer der beiden Chains gesetzt sein. Diese Bedingungen können, müssen aber nicht, zur Konsistenzüberprüfung genutzt werden.
4.2 Strahl / kein Strahl
PZUI |
ChopperControl |
Register |
# |
IL_H |
INL_HSI_BL |
StrahlwegReg |
4 |
IL_N |
INL_HLI_BL |
StrahlwegReg |
5 |
Block_H |
Block_HSI |
StrahlwegReg |
6 |
Block_N |
Block_HLI |
StrahlwegReg |
7 |
@ChopperControl
Die IL_*- und Block_*-Bits sollen verhindern, dass der jeweilige Chopper den Strahl durchlässt. IL_* ist gesetzt, wenn der Strahl von einem langsamen Interlock verhindert wird. Block_* ist gesetzt, wenn das Pattern geplant ohne Strahl ausgeführt wird (z.B. in einem Puls ohne Strahl weil der Profilgitterschutz aktiviert ist, im alten System ist Block_* auch gesetzt während eines Datenversorgungsvorgangs um mit Strahl konsistente Datenversorgung zu gewährleisten). Langsame Interlocks haben keine Auswirkung auf Rahmen- oder Klemmpulse. Bei Ausführung geplant ohne Strahl werden von der Choppersteuerung keine Rahmenpulse erzeugt (aber Klemmpulse).
Langsame Interlocks werden von mini-masp erfasst und Summeninterlocks pro Chain werden an das ChopperControlInterface übermittelt. Die IL_* hängen vom Strahlweg ab, allerdings wird das Mapping von Chainindex zu Strahlweg schon von mini-masp vorgenommen. Aus dem Chainindex des jeweiligen Choppers ergibt sich direkt welcher Interlock, der von mini-masp gemeldet wird, auf welchen Chopper wirkt.
Dabei kommt in der PT-Liste der entsprechenden Chain immer die PT des entsprechenden Choppers vor. Dies kann als Konsistenzüberprüfung benutzt werden.
Wenn das Pattern geplant ohne Strahl ausgeführt wird, ist das NOBEAM Flag in den Timingevents gesetzt.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Über mini-masp wirken langsame Interlocks auch auf das NOBEAM flag in den Timingevents (mini-masp meldet den Interlock auch an BSS). Die Reaktion auf den langsamen Interlock ist nicht unbedingt synchron in BSS und im ChopperControlInterface. Wenn mini-masp einen Interlock meldet, kann es passieren, dass IL_H/N gesetzt ist, aber Block_H/N noch nicht (ChopperControlInterface hat den langsamen interlock verabeitet, BSS noch nicht), oder Block_H/N gesetzt aber IL_H/N noch nicht. Im letzten Fall berücksichtigt das ChopperControlInterface die Information von mini-masp zwar nicht direkt, aber indirekt über das Flag im Timing. In jedem Fall lässt der Chopper kein Strahl durch, nur die Rahmen- und Klemmpulse sind davon beeinflußt. Vermutlich ist die Verzögerung, die auftritt, bis ein langsamer Interlock überhaupt auf die Choppersteuerung wirkt, kritischer als die Konsistenz der beiden Bits.
4.3 PG/Emi-Schutz Masken
PZUI |
ChopperControl |
Bedeutung |
Register |
# |
Controls-DB: GROUP_NAME |
PG-Abschnitt |
Dis_UH4DT4P |
Mask_UH4DT4P |
Maskierung Gitterschutz UH4DT4P |
StrahlwegMaske |
0 |
GUH2BC1L _TO_GUS3MK1 |
UH |
Dis_US_DT_E |
Mask_US_DT_E |
Maskierung Emitanzschutz US_DT_P |
StrahlwegMaske |
1 |
|
|
Dis_US4DT7P |
Mask_US4DT7P |
Maskierung Gitterschutz US4DT7P |
StrahlwegMaske |
2 |
GUS4MK6 _TO_GUT1MK0 |
UA |
Dis_UA_DT_E |
Mask_UA_DT_E |
Maskierung Emitanzschutz UA_DT_P |
StrahlwegMaske |
3 |
|
|
Dis_UT1DT0P |
Mask_UT1DT0P |
Maskierung Gitterschutz UT1DT0P |
StrahlwegMaske |
4 |
GUS4MK6 _TO_GUT1MK0 |
UA |
Dis_TK_DT_E |
Mask_TK_DT_E |
Maskierung Emitanzschutz TK_DT_P |
StrahlwegMaske |
5 |
|
|
Dis_TK3DT4P |
Mask_TK3DT4P |
Maskierung Gitterschutz TK3DT4P |
StrahlwegMaske |
6 |
GTK3MV4 _TO_GTK7BC1L |
TK4 |
Dis_TK3DT3P |
Mask_TK3DT3P |
Maskierung Gitterschutz TK3DT3P |
StrahlwegMaske |
7 |
GTK3MV1 _TO_GTK3MV3 |
TK3 |
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
die fehlenden Einträge in der Tabelle ergänzen
@ChopperControl
Bei aktiviertem PG/Emi-Schutz blockiert die Choppersteuerung den Strahl, falls die SVÜ einen entsprechenden Strahlalarm meldet. Der PG/Emi-Schutz kann pro Abschnitt aktiviert werden.
Bei aktiviertem PG/Emi-Schutz wird ausserdem der Strahlpuls verkürzt und nur jeder x-te Puls mit Strahl geplant. Beides hat, wenn überhaupt, nur indirekt Auswirkungen auf das ChopperControlInterface (z.B. wird Block_H/N entsprechend gesetzt, siehe oben).
Die Information über Aktivierung des PG/Emi-Schutzes kommt derzeit von der Emergency-App. Synchronisierung verschiedener Systeme, die auf PG/Emi-Schutz reagieren, ist denkbar, hätte aber keinen direkten Einfluß auf das ChopperControlInterface (z.B. könnte man damit warten, Strahl zu produzieren, bis die betroffenen Systeme die Aktivierung umgesetzt haben).
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
Ich bin nicht sicher, ob die masken nur von der aktivierung abhängen, oder ob der Strahlweg auch mit eingeht. Entweder in PZUI code oder Peter oder Peter fragen. Oder man siehts auch im Choppercontrol code, ob es mit am watchdog hängt
4.4 TK Rahmen & Klemmpulse
PZUI |
!ChopperControl |
Bedeutung |
Register |
# |
requSIS |
Request_SIS |
TK von SIS angefordert |
StrahlwegReg |
8 |
TK9DC9 |
TK9DC9 _out |
TK9DC9 -Cup ist drin |
StrahlwegReg |
9 |
enableTK |
Enable_TK |
Rahmenpuls-TK erzeugen |
StrahlwegReg |
10 |
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
PZUI code sagt Bit 9 ist "cup is drin", ChopperControl code sagt "_out" und ausserdem
TK9DC9_out ist 0-Aktiv. Was ist das richtige?
@ChopperControl
Verschiedene Betriebsmodi für Strahl im TK erfordern relativ komplizierte Logik um enstprechende Rahmen- und Klemmpulse zu erzeugen (siehe chopcontk im Anhang). Je nachdem, ob Strahl vom SIS angefordert ist, die Cup TK9DC9 eingefahren ist, und ob der TK7 Chopper benutzt wird, werden die Rahmen- und Klemmpulse im TK vor und hinter dem TK7 Chopper angepasst.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Im Wet-Run November 2024 ist es nicht vorgesehen Strahl in den SIS zu injizieren.
requSIS
Dem Masterschedule ist die Information im Prinzip bekannt. Allerdings gibt es kein entsprechendes Timingevent oder Bit im Payload der Timingevents. Vorerst sollte das ChopperControlInterface eine Property anbieten, über die das Bit geschaltet werden kann.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Bisher keine valide Lösung.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Die Property ist vorerst, der Einfachheit halber, nicht multiplexed. Für die richtige Lösung wird es voraussichtlich multiplexed sein.
TK9DC9
Ob die TK9DC9 eingefahren ist, ist mini-masp bekannt. Mini-masp wird die Information zusätzlich zu den langsamen interlocks an das ChopperControlInterface übermitteln.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
Strengenommen ist der Interlock am mini-masp nur Endlage aussen: ja/nein. Wenn die Cup nicht in der Endlage aussen ist, ist sie nicht unbedingt eingefahren, .... oder doch?
enableTK
Das Bit gibt lediglich an, ob eine der Chains durch den TK geht. Für jede Chain kann das vorab ermittelt werden, indem überprüft wird ob die entsprechenden PTs in der Chain vorkommen, oder nicht.
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
wie heissen die TK PTs?
4.5 Register Übersicht
Je nachdem, wie oft sich die Werte der Bits ändern (können), lassen sie sich einteilen in
- Globale (langsame) Bits, die nicht abhängig davon sind, welche Chain gerade läuft. Das sind z.B TK9DC9 oder die PG/Emischutz-Bits.
- PT, Bits die pro Chain einmal gesetzt werden und sich danach nicht ändern, d.h. sie hängen nur von der Liste der PTs ab.
- C, Bits die sich nur langsam ändern und pro Chain ausgewertet werden müssen, z.B. IL_*
- WR, Bits die sich erst aus den Timingevents ergeben, z.B. ob eine Chain mit oder ohne Strahl ausgeführt wird.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Die Einträge in der letzten Spalte in der Tabelle beziehen sich auf das, was in den vorherigen Abschnitten beschrieben ist und nicht unbedingt auf die fertige Lösung (zb
requSIS
).
PZUI |
ChopperControl |
Bedeutung |
Register |
# |
G/PG/PT/C/WR |
source |
IQ_R_UH |
Qu_R_HSI |
beam from IQ-R to HSI |
StrahlwegReg |
0 |
PT |
Setting |
IQ_L_UH |
Qu_L_HSI |
beam from IQ-L to HSI |
StrahlwegReg |
1 |
PT |
Setting |
HSI_UA |
HSI_ALV |
beam from HSI to Alvarez |
StrahlwegReg |
2 |
PT |
Setting |
HLI_UA |
HLI_ALV |
beam from HLI to Alvarez |
StrahlwegReg |
3 |
PT |
Setting |
IL_H |
INL_HSI_BL |
|
StrahlwegReg |
4 |
C |
mini-masp |
IL_N |
INL_HLI_BL |
|
StrahlwegReg |
5 |
C |
mini-masp |
Block_H |
Block_HSI |
|
StrahlwegReg |
6 |
WR |
WR |
Block_N |
Block_HLI |
|
StrahlwegReg |
7 |
WR |
WR |
requSIS |
Request_SIS |
TK von SIS angefordert |
StrahlwegReg |
8 |
G |
Setting |
TK9DC9 |
TK9DC9 _out |
TK9DC9 -Cup ist drin |
StrahlwegReg |
9 |
G |
mini-masp |
enableTK |
Enable_TK |
Rahmenpuls-TK erzeugen |
StrahlwegReg |
10 |
PT |
Setting |
Dis_UH4DT4P |
Mask_UH4DT4P |
Maskierung Gitterschutz UH4DT4P |
StrahlwegMaske |
0 |
G |
Setting |
Dis_US_DT_E |
Mask_US_DT_E |
Maskierung Emitanzschutz US_DT_P |
StrahlwegMaske |
1 |
G |
Setting |
Dis_US4DT7P |
Mask_US4DT7P |
Maskierung Gitterschutz US4DT7P |
StrahlwegMaske |
2 |
G |
Setting |
Dis_UA_DT_E |
Mask_UA_DT_E |
Maskierung Emitanzschutz UA_DT_P |
StrahlwegMaske |
3 |
G |
Setting |
Dis_UT1DT0P |
Mask_UT1DT0P |
Maskierung Gitterschutz UT1DT0P |
StrahlwegMaske |
4 |
G |
Setting |
Dis_TK_DT_E |
Mask_TK_DT_E |
Maskierung Emitanzschutz TK_DT_P |
StrahlwegMaske |
5 |
G |
Setting |
Dis_TK3DT4P |
Mask_TK3DT4P |
Maskierung Gitterschutz TK3DT4P |
StrahlwegMaske |
6 |
G |
Setting |
Dis_TK3DT3P |
Mask_TK3DT3P |
Maskierung Gitterschutz TK3DT3P |
StrahlwegMaske |
7 |
G |
Setting |
Mask_Anf_X0 |
Mask_Anf_X0 |
Maskierung Strahlanforderung X0 |
AnforderMaske |
0 |
PT |
Setting |
Mask_Anf_X1 |
Mask_Anf_X1 |
Maskierung Strahlanforderung X1 |
AnforderMaske |
1 |
PT |
Setting |
Mask_Anf_X2 |
Mask_Anf_X2 |
Maskierung Strahlanforderung X2 |
AnforderMaske |
2 |
PT |
Setting |
Mask_Anf_X3 |
Mask_Anf_X3 |
Maskierung Strahlanforderung X3 |
AnforderMaske |
3 |
PT |
Setting |
Mask_Anf_X4 |
Mask_Anf_X4_5 |
Maskierung Strahlanforderung X4 |
AnforderMaske |
4 |
PT |
Setting |
Mask_Anf_X6 |
Mask_Anf_X6 |
Maskierung Strahlanforderung X6 |
AnforderMaske |
5 |
PT |
Setting |
Mask_Anf_X7 |
Mask_Anf_X7 |
Maskierung Strahlanforderung X7 |
AnforderMaske |
6 |
PT |
Setting |
Mask_Anf_X8 |
Mask_Anf_X8 |
Maskierung Strahlanforderung X8 |
AnforderMaske |
7 |
PT |
Setting |
Mask_Anf_Y7 |
Mask_Anf_Y7 |
Maskierung Strahlanforderung Y7 |
AnforderMaske |
8 |
PT |
Setting |
Mask_Anf_Z7 |
Mask_Anf_Z7 |
Maskierung Strahlanforderung Z7 |
AnforderMaske |
9 |
PT |
Setting |
Mask_Anf_Z6 |
Mask_Anf_Z6 |
Maskierung Strahlanforderung Z6 |
AnforderMaske |
10 |
PT |
Setting |
Mask_Anf_UU |
Mask_Anf_UU |
Maskierung Strahlanforderung UU |
AnforderMaske |
11 |
PT |
Setting |
Mask_Anf_M1 |
Mask_Anf_M1 |
Maskierung Strahlanforderung M1 |
AnforderMaske |
12 |
PT |
Setting |
Mask_Anf_M2 |
Mask_Anf_M2 |
Maskierung Strahlanforderung M2 |
AnforderMaske |
13 |
PT |
Setting |
Mask_Anf_M3 |
Mask_Anf_M3 |
Maskierung Strahlanforderung M3 |
AnforderMaske |
14 |
PT |
Setting |
Mask_Anf_SIS |
Mask_Anf_SIS |
Maskierung Strahlanforderung SIS |
AnforderMaske |
15 |
PT |
Setting |
5 Schnittstelle Interlock Cup(s)
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Wir unterscheiden zwischen einem Interlock von dem Choppernetzteil einerseits und allen anderen zusätzlichen Fehlern, die am Chopper auftreten können, andererseits (z.B. Pulsform wird von Choppersteuerung überwacht und meldet im alten System Fehler an die PZUI, die dann die Cup einfährt).
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Eine "richtige" Lösung ist noch nicht in Sicht. Die Minimallösung für 2024 sollte auf einen Interlock vom Chopper reagiern und die Cup einfahren, notfalls alles via Software.
Mini-masp überwacht Interlocks der Chopper und kann entweder selbst oder via ChopperControlInterface die Cup einfahren. Falls Chopper-Interlock und das Einfahren der Cup Hardware-mässig direkt verdrahtet werden können, wäre das zu bevorzugen.
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
S.R. fragen ob er eine "gute Idee" dazu hat.
6 Schnittstelle mini-masp
Das ChopperControlInterface benötigt von mini-masp folgende Informationen:
- Chain-Interlocks (siehe 4.2)
- Position TK9DC9 (siehe 4.4)
- Chopper-Interlocks (siehe 5)
Zur Übertragung der Daten von mini-masp an das ChopperControlInterface wird der Association-Mechanismus von FESA benutzt. Dazu wird am masp folgende (nicht multiplexed) Acquisition Property angelegt:
Property |
Item |
Datatype |
Comment |
BeamPermit |
chainIndices |
array of int |
alle "aktiven" Chains (nicht nur UNILAC) |
chainBeamPermit |
array of bool |
|
GTK9DC9_P_END_POS_OUT |
bool |
|
GUH2BC1L_is_ok |
bool |
|
GUN3BC1L_is_ok |
bool |
|
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Alle Information, die von mini-masp an das ChopperControlInterface übertragen werden muss, in eine nicht-multiplexte Property zu packen ist das, was am einfachsten erscheint. Später könnten die Daten anders sortiert werden.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Der Name
_is_ok
soll andeuten, dass nicht nur der interlock (an mini-masp
INTERLCK
(sic)) ausgewertet wird, sondern daß außerdem,
POWER_ON
,
OP_READY
,
ONLINE
, und
REMOTE
OK sein müssen. Insbesondere, kann es passieren, dass
_is_ok =
false auch wenn am Gerät keine Probleme anliegen (falls z.B. die Übermittlung der Statusinformation an mini-masp gestört ist).
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Vorerst wird die Property immer genotified (wenn die StatusChangedRTAction aufgerufen wird, notified property: automatic). Falls sich das als zu oft herausstellt kann es geändert werden.
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
Auch GTK9DC9_P kann offline sein. Sollte dann end pos out = OK oder NOT_OK angenommen werden? Jetzt ist das item einfach nur END_POS_OUT=OK. Außerdem: siehe Kommentar oben.
Subscription @ RT-Action:
https://www-acc.gsi.de/wiki/FESA/FESA700_CodeSnippets#OnSubscription_Payload
Beispiel für Association:
https://git.acc.gsi.de/fesa-classes/ElectroStatQuad
7 Setting Properties
Property |
Item |
Datatype |
Comment |
Setting (bp-multiplexed) |
particletransfers |
|
LSA |
ProfileGridProtectionRequested |
UH |
bool |
Emergency-App ? Requested -> Enabled ? |
UN |
bool |
|
UT2 |
bool |
|
UX |
bool |
|
UY |
bool |
|
UZ |
bool |
|
UM |
bool |
|
TK1 |
bool |
|
TK3 |
bool |
|
TKD |
bool |
|
TK4 |
bool |
|
TK8 |
bool |
|
ExpertSetting |
requSIS |
bool |
|
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
namen der Properties & Items checken
8 Implementierung
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
beschreibe 2 Alternativen: "Echtzeit"-Fesa oder Echtzeit-hardware, beides hat vor/nachteile, wir machen jetzt "Echtzeit"-FESA
Im Bild ist dargestellt, wie der Wert des StrahlwegReg für jeden Puls ermittelt wird. Der Ablauf für die beiden anderen Register ist analog (aber viel einfacher).
- Daten versorgung via LSA
-
Chainindex
: Die Datenversorgung von LSA ist Beamprocess-multiplexed. Allerdings gibt es nur einen BP pro Chain. Es ist also nur entscheidend welcher Index benutzt wird um den Datensatz zu identifizieren. Die langsamen Interlocks von mini-masp benutzten den Chainindex. Um das Mapping vom BP-index zum Chainindex zu realisieren wird intern bei zu jedem Satz Setzwerten der Chainindex aus dem Selektor gespeichert (in einem BP-gemultiplextem Setting Feld).
-
StrahlwegReg_PT
: Die Bits, die nur vom Strahlweg abhängen (siehe 4.1) können schon beim Versorgen der Setzdaten ermittelt und intern in einem BP-gemultiplextem Settin Feld gespeichert werden.
- "Globale Bits"
-
StrahlwegReg_G
: Die Bits TK9DC9
und requSIS
ändern sich nicht von Puls zu Puls (requSIS eigentlich schon, siehe
oben). Beide gehen ein in StrahlwegReg_G
, das ...
wann wird das geupdated? In der SetAction? Ondemand RT-Action?
- Reaktion auf #255
- blabal
- Wenn beide ...
-
fertig schreiben
8.2 Zeitgenaues beschreiben der Register
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
Frage an SR: Was passiert nachdem der Watchdog angeschlagen hat? Wenn der watchdog einmal angeschlagen hat ist ja quasi jedes nächste beschreiben der register "in time". Und: Werden alle 3 register von dem Watchdog überwacht?
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
Messen und Ergebnisse hier einfügen.
8.3 FESA RT-Actions via WR-Timing Events
In FESA kann ein Device nur auf Timingevents einer Timinggroup reagieren. Damit auf Timingevents in 2 unterschiedlichen Timinggroups reagiert werden kann, werden 2 FESA Devices angelegt. Von den beiden Instanzen bekommt nur eine die korrkte Nomenklatur, und die andere eine "fake-nomenklatur". Nur die "richtige" Instanz wird mit Settingdaten versorgt und produziert Acquisition daten. Die zweite Instanz ist lediglich um von WR-Timingevents FESA-RT-Actions anzustossen. Beide Instanzen teilen sich die implementierung der RT-Action (siehe dazu
https://www-acc.gsi.de/wiki/FESA/FESA3WhiteRabbit700#Working_With_Devices_in_different_Timing_Groups).
8.4 NOBEAM Flag vom WR-Payload @ FESA RT-Action
Das Format der Timing Messages ist hier beschrieben:
https://www-acc.gsi.de/wiki/Timing/TimingSystemEvent.
Der Param Teil, in dem das NOBEAM flag steht ist in FESA nicht direkt verfuegbar. Man kann allerdings das 64bit wort wieder zusammensetzen aus getBeamProductionChainTimestamp()
und getBeamProductionChainIndex()
. Das Flag ist
ReqNoBeam
und ist in FESA verfügbar via
uint32_t TimingContextWR::getReserved()
.
![TODO](/wiki/pub/System/DocumentGraphics/todo.png)
ist das das richtige flag? Nein, siehe:
https://www-acc.gsi.de/wiki/ProjectMgmt/MappingWrMilSisEsrUnilac#A_5_Decision
8.5 Zeiten vom WR-Payload @ FESA RT-Action
const fesaGSI::TimingContextWR* contextWR = dynamic_cast<const fesaGSI::TimingContextWR*>(pEvt->getMultiplexingContext());
uint64_t acquisitionstamp=contextWR->getAcquisitionTimeStamp();
uint64_t eventtimestamp=contextWR->getEventExecutionTimeStamp();
timespec sourcetime = contextWR->getEventsourceExecutionTimeStamp();
uint64_t sourcetimestamp = (sourcetime.tv_sec*1000000000)+sourcetime.tv_nsec;
timespec nowclock;
clock_gettime(CLOCK_REALTIME, &nowclock);
uint64_t nowtimestamp = (nowclock.tv_sec*1000000000)+nowclock.tv_nsec;
uint64_t event_to_eventsource_delay = sourcetimestamp - eventtimestamp
uint64_t event_to_action_delay = nowtimestamp - eventtimestamp
8.7 Test Setup
Test Setup
9 Meeting Notes
9.1 Datenversorgung via LSA - Meeting 6.8.: Chain vs BP multiplexing & 1 Device in 2 Timinggroups
Im Meeting vom 6.8. (R.M./A.S.) wurde festgehalten, dass das ChopperControlInterface BP-Multiplexed ist. Die Settings sind zwar pro Chain, können aber trotzdem pro Beam Process versorgt werden. Tatsächlich gibt es am Unilac nur einen Beamprocess pro Chain. Ausserdem, ist es in FESA einfacher den BP-index aus dem WR-Timingevent zu bekommen anstatt den Chain index. Die Interlocks von mini-masp haben zwar den Chainindex als Key, aber über die Datenversorgung von LSA, die immer den kompletten Selektor mitgibt, kann das mapping BPIndex -> Chainindex erstellt werden.
Ausserdem wurde besprochen wie damit umgegangen wird, daß das ChopperControlInterface Settings zu 2 Timinggroups braucht. Settings in LSA sind immer in einer Timginggroup verortet. Bis auf weiteres muss in LSA eine Sonderbehandlung implementiert werden. Für die Zukunft wurden verschiedene Alternativen in Betracht gezogen (FESA Composition / kein Composition, aber trotzdem 2 Devices / Nameserver alias).
10 Allgemeine Notizen
![alert](/wiki/pub/System/DocumentGraphics/alert.png)
Falls nötig wären Änderungen an dem ChopperControl VHDL code möglich (Info von S.R), allerdings muss dabei bedacht werden, dass Um- und Rückbau einfach möglich sein muss.
- yocto fesa remote debugging:
- gdb -ex "set sysroot /common/usr/embedded/yocto/fesa/current/sdk/sysroots/core2-64-ffos-linux" -ex "target remote scuxl0646:46697" -ex "set solib-search-path ./ChopControlInterface/build/lib/yocto" -s ./ChopControlInterface_DU/build/bin/yocto/ChopControlInterface_DU
- ^ stimmt irgendwas nicht mit :/ solib-search-path scheint nicht zu stimmen
- Definition of Timing Groups: https://www-acc.gsi.de/wiki/pub/FAIR/CCT/Minutes120117/DefinitionOfTimingGroups.pdf
- Timing events:
- Unilac particle transfers
- Pulszentrale:
- Choppersteuerung:
- Chopper
- Ist normales Netzgereat, wie andere auch
- Interlocküberwachung:
- Dev acc fuer dummies: https://pad.acc.gsi.de/HfuCmO4zTOatxttzCssfuQ?view
- Begriffe in der Doku des alten Systems:
- Pulsunterdrückung vs Pulsabbruch: entspricht der Reaktion auf langsame / schnelle Interlocks. Der Chopper reagiert entweder erst auf den nächsten Puls oder sofort.
- Trafo-Interlocksignale / Trafomesssysteme, es wird unterschieden zw. Strahlverlustmessung und Strahlleistungsmessung: das ist unter SVÜ zusammengefasst
--
TobiasHabermann - 26 Jul 2024