ChopperControlInterface

0 Offene Fragen

• Wie können die Interlock Cups angesteuert werden?

1 Aufgaben des ChopperControlInterfaces

1. 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.
2. 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.
3. 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.
4. 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

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

3 Timing & Strahlweg Information

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

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.

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

ist das bild in dem pdf das richtige? aktuell?

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.

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

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.

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.

Inputs

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.

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

Inputs

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.

Ü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

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

Input

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

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

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.

Im Wet-Run November 2024 ist es nicht vorgesehen Strahl in den SIS zu injizieren.

Input

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.

Bisher keine valide Lösung.

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.

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.

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.

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)

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

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.

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

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.

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

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.

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

namen der Properties & Items checken

8 Implementierung

beschreibe 2 Alternativen: "Echtzeit"-Fesa oder Echtzeit-hardware, beides hat vor/nachteile, wir machen jetzt "Echtzeit"-FESA

8.1 Übersicht: Input -> Strahlwegregister

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

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?

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().

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

nomen	Timing Group / Particle Transfer	(Accelerator Zone)
GUN3BC1L	GUN3BC1L _TO_GUN6MU2#624	GUN3BC1L_TO_GUN4BR1
GUH2BC1L	GUH2BC1L_TO_GUS3MK1#609	GUH2BC1L_TO_GUH2BR2

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:
  • https://www-acc.gsi.de/wiki/pub/Machines/MachineUNILAC/UNILAC%20timig%20essentials%202023-02-27.pdf
  • https://www-acc.gsi.de/wiki/Timing/TimingSystemEventNumbers
  • https://www-acc.gsi.de/wiki/Timing/TimingSystemHowSaftDm
  • @fesa https://pad.acc.gsi.de/tkJbuFpFRuOQIswmPZ3l6w#
  • Position "no beam"-Flag im Reserved-Teil der EventID: https://www-acc.gsi.de/wiki/ProjectMgmt/MappingWrMilSisEsrUnilac#A_5_Decision
• Unilac particle transfers
  • https://www-acc.gsi.de/wiki/pub/Machines/MachineUNILAC/UNILAC%20Schema%20Abschnitte%20Strahlwege%20V0_99e_ohneMILtimingabschnitte.pdf
  • curl -X 'GET' 'http://lsapro00a.acc.gsi.de:52330/accelerators/gsi/particle-transfer-relations' -H 'accept: */*' | jq | grep Unilac
• Pulszentrale:
  
  • gu__zz
  • eqmodel_pz: https://git.acc.gsi.de/devacc/eqmodel_pz
  • https://www-acc.gsi.de/data/documentation/eq-models/pzus/gm-pzu.pdf
• Choppersteuerung:
  • F700.800 - https://www-windows.gsi.de/belab/FG_DB/
  • https://github.com/GSI-CS-CO/bel_projects/blob/fallout/top/fg45041x/chopper_m1/chopper_m1_logic.vhd
  • https://github.com/GSI-CS-CO/bel_projects/blob/master/top/fg45041x/chopper_m2/chopper_m2_logic.vhd
• Chopper
  • Ist normales Netzgereat, wie andere auch
• Interlocküberwachung:
  • gu__si
  • F700.510 - \ACOGroup\Group_HEL\MANUALS\BAUGRUPPEN_Geraete\F700\51x\510\Doku
  • mil event doku (input für milmon) - https://git.acc.gsi.de/devacc/eqmodel_pz/src/branch/master/pzui/src/pzuiMil.txt
• 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