ChopperControlInterface

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 Übersicht

Nicht korrekt in dem Bild: PG/Emi-Schutz aktiv kommt nicht von LSA Datenversorgung. Siehe unten fuer aktuelles Bild.

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

Zuerst war nicht klar, ob Chain-, Beamprocess- oder Sequence-multiplexing 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 strenggenommen der ChainIndex nicht direkt für das Multiplexing 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 (nicht unbedingt aktuell): https://www-acc.gsi.de/wiki/pub/Machines/MachineUNILAC/UNILAC%20timig%20essentials%202023-02-27.pdf

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

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	#
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 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 Particletransfers (PT). 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.

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 dry Flag in den Timingevents gesetzt.

Über mini-masp wirken langsame Interlocks auch auf das dry 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,UM,UX,UY,UZ,UT2,TK1
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,TK8
Dis_TK3DT3P	Mask_TK3DT3P	Maskierung Gitterschutz TK3DT3P	StrahlwegMaske	7	GTK3MV1 _TO_GTK3MV3	TK3,TKD

Emitanzschutz bits werden noch nicht gebraucht, richtig? (->PG?)

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

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 in Endlage Aussen ist, ist mini-masp bekannt. Mini-masp wird die Information zusätzlich zu den langsamen interlocks an das ChopperControlInterface übermitteln.

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.

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.

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.

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 und in dem Fall ist GTK9DC9_P_END_POS_OUT = false. Ist das richtig so? Außerdem: 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?

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 (seq-multiplexed)	particleTransfers	string array	LSA
ProfileGridProtectionEnabled	UH	bool	Emergency-App
	UN	bool
	UA	bool
	UT2	bool
	UX	bool
	UY	bool
	UZ	bool
	UM	bool
	TK1	bool
	TK3	bool
	TKD	bool
	TK4	bool
	TK8	bool
ExpertSetting	requSIS	bool

8 Implementierung

8.1 Übersicht: Input -> Strahlwegregister

Im Bild sind die Schnittstellen des ChopperControlInterface dargestellt. Der FESA-Serverteil ist in gelb und er FESA-Realtimeteil in blau dargestellt. Die Rechtecke stellen Settingfelder dar. Nur für die Setzdaten der Setting Property wird (Sequence-) Multiplexing verwendet. Die langsamen Interlocks werden in 2 parallelen Listen (Beampermit und Chainindex) verwaltet, da mini-masp Chain-multiplexed ist. Um das Mapping vom Sequence-index zum Chainindex zu realisieren wird intern bei zu jedem Satz Setzwerten der Chainindex aus dem Selektor gespeichert (in einem Sequence-gemultiplextem Setting Feld).

Die Bits, die nur vom Strahlweg abhängen (siehe 4.1) können schon beim Versorgen der Setzdaten ermittelt und intern in einem gemultiplextem Setting Feld gespeichert werden. Beide Gereate registrieren sich auf das #255 Command event und mit dem Kontext des Timingevents (Sequenz-id für die Settingdaten (FESA-Multiplexing), und Chainindex aus den Settingdaten) werden die vorbereiteten Registerwerte ausgelesen und in nicht-multiplexed Speicher vorgehalten, bis das zweite Gerät (entweder HLI oder HSI) das Event abgearbeitet hat, um dann die 16-bit Worte der beiden Geräte zu kombinieren und in das Register der Choppersteuerung zu schreiben.

Die gleichen Datenfelder in einer RT-Action schreiben und lesen, ist nur möglich, wenn für diese Felder der FESA-Synchronisierungsmechanismus ausgeschaltet wird (data-consistency=false). Die betroffenen RT-Actions sollten dann in dem selben Thread laufen. Das ist der Fall für die langsamen Interlocks, die von mini-masp kommen, und alle Felder die in der #255-RT-Action von einem Gerät geschrieben und vom anderen gelesen werden.

8.2 Liste von Particletransfers -> Strahlziel & Strahlweg

Die Liste von Particletransfers, die für jeden Strahl datenversorgt wird, wird benutzt um den Strahlweg und das Strahlziel zu bestimmen. Das Strahlziel wird gebraucht für die Anfordermaske und der Weg für das Strahlwegregister. Dazu wird der Unilac in Abschnitte eingeteilt: Quellen, HSI, HLI, Alvarez, TK und die Unilac-Experimentierplätze. Die komplette Liste ist hier definiert https://git.acc.gsi.de/fesa-classes/ChopControlInterface/blame/commit/f714ee49ea7746136a15369ff55c0066f2112687/src/ChopControlInterface.design#L738, wobei die ersten 16 Einträge genau den 16 Bits der Anfordermaske entsprechen. Jedem Abschnitt ist mindestens eine Particletransfer zugeordnet (siehe https://git.acc.gsi.de/fesa-classes/ChopControlInterface/src/branch/master/src/ChopControlInterface/Common/ParticleTransferMapping.h). Es hat sich herausgestellt, dass pro Abschnitt ein "Key-Particletransfer" ausreicht, um den Strahlweg eindeutig zu bestimmen (H.H.,P.G.).

8.3 Zeitgenaues beschreiben der Register

Die zeitlichen Anforderungen ergeben sich aus dem Watchdog der Choppersteuerung, der verhindern soll, dass der Chopper Strahl durchlässt bevor die Register mit den Informationen für den aktuellen Puls beschrieben worden sind. Wenn der Watchdog anschlägt, dann setzt die Choppersteuerung beide Block_* Bits. Das nächste Beschreiben des Strahlweg Registers setzt den Timer wieder zurück auf 25 ms (so wie sonst auch). Bei einer Pulslänge von 20ms bleibt also ein 5ms breites Zeitfenster um das Register zu beschreiben.

Die Vorbereitung der Registerwerte wird in dem FESA-User code vorgenommen, wie oben beschrieben. Das eigentliche Schreiben der Register, wird über ein Zeit-event realisiert, das an der ECA injeziert wird um in der Folge das zeitlich genaue Beschreiben anzustossen:

• https://www-acc.gsi.de/wiki/Timing/TimingSystemHowUniChop.
• saft-ctl code: https://github.com/GSI-CS-CO/saftlib/blob/master/src/saft-ctl.cpp
• saft-ctl doku: https://www-acc.gsi.de/wiki/Timing/TimingSystemHowSaftCtl

Die Dauer von der Deadline des Command-events bis zum injezieren des Events in der ECA ist in dem Histogram dargestellt. Wenn die Dauer 7ms ueberschreitet, dann wird ein Event injeziert dessen Deadline in der Vergangenheit liegt, in dem Fall werden die Register der Choppersteuerung nicht beschrieben und der Watchdog schlaegt an. Der offset von 7ms ist so gewaehlt, dass danach genuegend Zeit bleibt um noch vor dem Strahlpuls 5ms zu "warten" (5ms ist der timeout des Watchdogs).

Bei 7ms offset wird in ca 0.01% der Pulse das Register zu spaet beschrieben.

Der Unterschied zwischen dem late counter der Firmware (~0.01%) und dem late counter der FESA RT-Action (keine Events zu sehen in dem histogram oben) ist noch nicht verstanden. Zb im selben Zeitraum, in dem die RT-Action nur 145 Faelle zaehlt, in denen die Deadline schon abgelaufen ist, gibt es 1902 late events.

Spaeter wurde das fesa flag noRTSched benutzt. Die resultierende Dauer der RT-Action ist in dem histogram unten dargestellt (gemessen im integrationsystem).

Nach dem wetrun hat sich ploeztlich das zeitliche Verhalten geaender (nach Neustart am Montag 11.11.) und in sehr vielen Faellen wird das timing event aus der RT-Action zu spaet injeziert (gemessen im Produktivsystem):

8.4 RT-Actions In 2 verschiedenen Timinggroup Contexten via 2 Fesa Devices

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

• Das FESA-Gerät, das mit Datenversorgt wird ist CCI_HSI. Das CCI_HLI Gerät kann auf die Setting Felder von CC_HSI zugreifen.
• Das "Master"-Device CCI_HSI wird eine andere Nomenklatur bekommen. Der Name CCI_HLI hat ausser intern keine Relvanz (kann deswegen intern benutzt werden).
• CCI_HSI ist konfiguriert für die TimingGruppe 609. Multiplexte Settings müssen den entsprechenden Selektor angeben (oder -1)
• Exception wenn CCI_HLI settings gesetzt werden.

8.5 dry-Flag vom WR-Payload @ FESA RT-Action

Das Format der Timing Messages ist hier beschrieben: https://www-acc.gsi.de/wiki/Timing/TimingSystemEvent. Das dry flag ist wie hier beschrieben https://www-acc.gsi.de/wiki/ProjectMgmt/MappingWrMilSisEsrUnilac#A_5_Decision in den Reserved Bits der EventId zu finden.

Es handelt sich dabei weder um das ReqNoBeam- noch um das BeamIn- Flag.

Siehe auch https://git.acc.gsi.de/FESA3-FWK/framework/src/branch/master/fesa-core-gsi/src/fesa-core-gsi/RealTime/TimingEventSourceWR.h (FESA EventID Bitmasken)

8.6 Zeiten vom WR-Payload @ FESA RT-Action

const fesaGSI::TimingContextWR* contextWR =  dynamic_cast<const fesaGSI::TimingContextWR*>(pEvt->getMultiplexingContext());

uint64_t acquisitionstamp=contextWR->getAcquisitionTimeStamp();                 // "soll zeit" von dem Event
uint64_t eventtimestamp=contextWR->getEventExecutionTimeStamp();                // ausgang ECA (kann delayed sein, dh = soll + delay)
timespec sourcetime = contextWR->getEventsourceExecutionTimeStamp();            // FESA-Eventsource feuert event
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;          // NOW / JETZT 

uint64_t event_to_eventsource_delay = sourcetimestamp - eventtimestamp
uint64_t event_to_action_delay = nowtimestamp - eventtimestamp

8.7 Acquisition & Logging

Zum testen und debuggen werden Acquisitiondaten als Liste formatierter Strings produziert. In einem Rollingbuffer wird bei jedem Aufruf der RT-Action eine Zeile des Rollingbuffer beschrieben. Der Rollingbuffer hat 100 Einträge. Wenn der letzte Eintrag beschrieben wurde wird die Acquisition Property genotified. Ausserdem kann man via Get den derzeiten Stand abrufen, der neueste Eintrag sollte sich über Timestamps identifizieren lassen. Ein skript zum auslesen der Property ist hier https://git.acc.gsi.de/fesa-classes/ChopControlInterface/src/branch/master/Tests/parse (keine Subskription, dh der neueste Eintrag ist nicht der letzte in der Liste).
Wenn in der RT-Action eine Exception geworfen wird, fehlt die entsprechende Zeile in den Acquisitiondaten.

Log Einträge werden bei jeden Aufruf der SetSetting, SetExpertSetting und OnSubscription erstellt, so das alle Inputs nachvollziehbar sein sollten (wie üblich via https://logging.acc.gsi.de).

Logeintraege die zb bei jedem Aufruf einer Server-Action gemacht werden, werden als INFO geloggt. Damit diese tatsaechlich geloggt werden muss eine custom log Konfiguration benuzt werden ( /opt/nfsinit/global/fesa_yocto aufrufen mit zusaetzlichem argument --custom, damit die Konfiguration in /etc/fesa/custom/ChopControlInterface_DU/ benutzt wird anstatt /etc/fesa/)

Die Sequence-Start Zeit ist immer 0, weil in den 4xx Timinggruppen kein Sequence-Start-Event gespielt wird. Sonst hat das keine Auswirkungen, die Zeilen von den einzelnen Ausfuehrungen in der Ausgabe koennen auch ueber den WR-Timestamp korreliert werden.

8.8 Interlock Cup

Vorerst wird die Interlock Cup, die sich vor dem HSI-Chopper befindet, durch eine Sequenz eingefahren. Der Sequencer startet die Sequenz, sobald masp an den Sequencer meldet, dass der HSI Chopper einen Interlock hat (bzw OK = kein interlock, remote, power on, op ready, online).

Die Kommunikation ist nicht fail-safe. Die Sequenz wird nur gefahren, wenn masp NOT_OK meldet. Wenn zb masp gar nicht mehr sendet, wird die Cup nicht eingefahren.

8.9 TODO

Aus wetrun:

• conflicts: ECA conditions zu Events die gleichzeitig feuern sollen führen zu conflicts und sind zu vermeiden. Wenn die beiden Command events nicht mehr "gleichzeitig" ankommen muss die Synchronisierung mit dem Timing in der fesa-rt-action sichergestellt werden (bei ersten Tests mit offset von 9ns auf einem der Events, waren die Registerwerte nicht mehr synchron mit dem was tatsächlich läuft. In die Register wurde Kobination aus HLI Strahlweg aus dem letzten Puls und HSI Strahlweg aus dem aktuellen Pulse geschrieben. Ohne offset tritt das nicht auf.)
• initial registerwerte: Alle registerwerte sollten so in die RT-Action transportiert werden, dass der Initialwert der geschrieben wird solange keine Datenversorgen von LSA vorliegt "sicher" ist. Es sollten Block und Interlock bits gesetzt sein. (Fälschlicherweise wurde angenommen, dass eine 0x0000 Anfordermaske dafür sorgt, das der Chopper keinen Strahl produziert, ausser alle Strahlziele würden anfordern (was nicht der Fall war). Allerdings bedeuted 0x000 Anfordermaske, dass irgendein Strahlziel anfordern kann. Dementsprechend gibt es keine "sichere" Anfordermaske, was aber kein Problem ist, weil Strahl durch das Strahlwegregister verhindert werden kann).
• zu dem letzten Punkt: für S=14/15 wird nie Strahl produziert und keine Strahlweginformation oder Sequence-Chain-Zuordnung wird benötigt. Die derzeitige Implementierung versucht trotzdem anhand der Sequence-Chain-Zuordnung zu ermitteln ob ein langsamer interlock vorliegt. Das ist aber nie der Fall für S=14/15 Chains (tatsächlich werden wahrscheinlich solche Kontexte in Zukunft mini-masp gar nicht mehr bekannt sein.)
• ProfileGridProtectionEnabled Property: Die namen der Items sind nicht so wie vereinbart war. Quick-fix war die namen vorerst an der Applikation zu ändern.
• Subscription auf mini-masp-interlocks: Es ist unklar, was passiert, wenn die Subcription unterbrochen wird. Wenn die Information ueber langsame interlocks von mini-masp nicht verfuegbar ist, sollte angenommen werden, dass die Chains nicht ausgefuehrt werden koennen (anstatt den letzten bekannten Chain permit anzunehmen).
• "exception: acquisitionContext has no data" Die exception trat auf bei Subscription auf CCI Acquisition Property, es ist unklar wieso. Eigentlich sollte das acquisitionContext item immer Daten haben.
• log etc:
  • log-nachrichten (und auswertung der acquisition-debug daten) sollten von den registerwerten nur die schon gueltigen anzeigen (zb in Setaction noch kein interlock bit)
  • PG-enabled: setzwerte fehlem im log (steht als "todo" im dry/wet wiki, ist das schon gemacht?)
• klaeren welche out-register noch vom Chopperinterface zu lesen sind (anforderung? strahlalarm? etc ?)
• Interlock cup via sequencer: war nur fuer wetrun.

Alt:

• wann genau sollen die register beschrieben werden ? CMD+5 -> viele late events / CMD + 10 -> fast gar keine late events
  • -> Hanno, info von Stefan, PeterK und PZUI Doku: Ende puls (20ms) - (200us + 500us + 60us + 10ms (max quellenpuls) + 40us + 5ms (watchdog)) =~ 4ms bzw mit 7ms quellenpuls -> ~7ms so wie jetzt konfiguriert
• timestamps in acqusition aufräumen. Wichtig sind eigentlich nur receiver->now und die deadline (und der evt timestamp damit man die beiden RT-ACtions zuordnen kann)
• register-schreibe-offset als configuration im instance file (derzeit fix 5ms)
• interlocks von masp: behalten den letzten wert wenn irgendwas schieft geht, sollten stattdessen alle in interlock gehen
• timinggroups nochmal checken, bisher nur "koennte vermutlich sein"
• exception wenn subscription auf Acquisition Property: No set before get acquisitionContext, sollte aber gesetzt sein vor der notification -> rolling buffer depth 10 -> 30 (instance file) scheint geholfen zu haben
• Setzen von Settings am falschen Gerät sollte Exception werfen

8.10 Tests / Integration / Dry- & Wetrun

• Test Setup
• Tests

9 Stand wetrun 11/2024: Übersicht

10 scuxl0685

• Mit noRTSched hat der Server thread oefters einen timeout. Im log zb:
  previous server dispatcher loop too slow: took 216ms (timeout=100ms)
• Einfaches monitoring via tmux session:
  while true; do awk 'NR==3 {print $3}' /proc/timer_list; top -b -d 1 -n 2; done

11 Meeting Notes

11.1 Datenversorgung via LSA - Meeting 6.8.2024: 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).

Nachtrag: Beamprocess multiplexing ist doch nicht möglich (siehe 9.2).

11.2 Injector Controls Upgrage 21.8.2024: BP multiplexing vs Sequence Multiplexing und VirtAcc 14/15

Das ChopperControlInterface kann doch nicht BP-Multiplexing benutzten, weil gleiche BP-indices in den beiden Timinggruppen für verschiedene BPs benutzt werden (BP-index ist nur eindeutig innherhalb einer Timinggruppe). Der Sequence Index ist eindeutig wenn man nur Unilac Sequenzen betrachtet. Der Sequence-Index ersetzt quasi die VirtAcc nummer. Das bleibt nicht unbedingt so, ist aber für 2024 vorerst ok.

Die Datenversorgung via LSA versorgt nicht, wie bisher angenommen, die Strahlwege für alle eingeplanten Patterns, sondern nur Unilac Patterns.

Sequence 14 und 15 werden benutzt für Pulse in denen nie Strahl ist. Dafür gibt es keinen Strahlweg und keinen "richtigen" Chain Index. Das entsprechende Block_HSI/HLI kann dann immer gesetzt werden. In den Timingevents ist das dry-flag für diese Pulse (noch) nicht gesetzt. In Sequenzen 14 und 15 wird auch nie von mini-masp verhindert, dass Strahl produziert wird, deswegen braucht das ChopperInterface für die beiden Sequenzen keinen Chainindex im Selektor.

Es kam nochmal die Frage auf, ob #255 in jeden Pulse gespielt wird und ob das dryflag enthalten ist. Bis auf S=14/15, in denen das dryflag (noch) nicht gestzt wird, ist das der Fall.

Nachtrag: Beam-process multiplexing wäre möglich wenn die zwei FESA-Geräte für HSI und HLI separat mit Daten versorgt werden würden (dh nicht die selben Settingfelder für Settingdaten für 2 verschiedene Timinggroups benutzt würden). Die Teilnehmer waren sich einig vorerst dabei zu bleiben, nur eines der Geräte mit Daten zu versorgen. Für ein eventuelles Redesign, sollte nochmal überlegt werden ob es einfacher wäre CCI_HSI und CCI_HLI getrennt mit Daten zu versorgen.

12 Allgemeine Notizen

• ICU https://www-acc.gsi.de/wiki/pub/Machines/UnilacControlsRoadmap2024to2026/icu_control_timing_system_integrated_milestone_overview_2024-2026_v2.pdf
• https://www-acc.gsi.de/wiki/pub/Machines/MachineUNILAC/UNILAC%20Schema%20Abschnitte%20Strahlwege%20V0_99e.svg
• Instanzen: int: scuxl0646 // pro: scuxl0685

nomen	Timing Group / Particle Transfer	(Accelerator Zone)	FESA-Device Name	Unilac TimingGroup
GUN3BC1L	GUN3BC1L _TO_GUN6MU2#624	GUN3BC1L_TO_GUN4BR1	CCI_HLI (nur intern benutzt)	451
GUH2BC1L	GUH2BC1L_TO_GUS3MK1#609	GUH2BC1L_TO_GUH2BR2	CCI_HSI (vorläufig)	452

• FESA
  • systemctl stop "fesa*"
  • https://www-acc.gsi.de/wiki/FESA/FESA3YoctoBuildProcedure
  • sdk mit association & asan:
    • unset LD_LIBRARY_PATH; source /home/bel/dday/lnx/scratch/sdk-asan/environment-setup-core2-64-ffos-linux
    • yocto-fesa3 -c ChopControlInterface -d ChopControlInterface _DU -a /home/bel/thaberm/lnx/workspace9/MASP/src/MASP.design -f scuxl0646 gen
  • 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
  • DB: https://websvcint.acc.gsi.de/groups/cscosv/vue/? oder int->pro fuer pro
• Definition of Timing Groups: https://www-acc.gsi.de/wiki/pub/FAIR/CCT/Minutes120117/DefinitionOfTimingGroups.pdf
• Timing events:
  • https://pad.acc.gsi.de/tkJbuFpFRuOQIswmPZ3l6w#
  • 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#
  • https://www-acc.gsi.de/wiki/Timing/Saftlib2MigrationGuide#Changes
• 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/
  • "Chopper Info Interface" https://www-acc.gsi.de/wiki/pub/Machines/UnilacControlsRoadmap2024to2026/icu_control_timing_system_integrated_milestone_overview_2024-2026_v2.pdf
  • 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
• 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 für dummies: https://pad.acc.gsi.de/HfuCmO4zTOatxttzCssfuQ?view

-- TobiasHabermann - 26 Jul 2024