Scheduling App Info: On-call duty / Rufbereitschaft
Collection of information about the Scheduling App that might come in handy for people doing APP On-call duty (e.g. new features that might lead to questions, stumbling blocks, ...). The contents are updated when there is relevant new functionality etc. .
This page is deliberately written in German to reduce the possibility of misunderstandings because of the language. If an English version is needed, please contact Anne.
Sammlung von Informationen über die Scheduling App, die im Rahmen der APP-Rufbereitschaft nützlich sein können (z.B. nachfrageträchtige neue Features, Stolperfallen, ...). Die Inhalte werden ergänzt, wenn es relevante neue Funktionen etc. gibt.
Die Seite ist bewusst auf Deutsch gehalten, um Missverständnisse aufgrund der Sprache möglichst auszuschließen. Bitte bei Anne melden, falls eine englische Übersetzung benötigt wird.
- Ändern des Schedules (PatternGroups)
- Anlegen neuer Patterns
1.1 Screen 1: Ändern des Schedules (PatternGroups)
- Änderungen am Schedule vornehmen, dann oben rechts "Versorgen/Supply" drücken => LSA versorgt Geräte und BSS!
- Supply passiert unter der Haube in mehreren Schritten:
- Patterns resident machen + Drive der zugehörigen Settings zu Geräten
- Pattern Groups aktualisieren (Patterns raus, Patterns rein/Reihenfolge ändern, leere Pattern Groups löschen)
- Patterns non-resident machen
- Bei Fehlern beim Supply oder beim Abbruch durch User bei Drive-Fehlern wird versucht, den vorherigen Schedule-Zustand wiederherzustellen (="Undo-Supply").
Hier könnten typischerweise Fehler auftreten, die mit
LSA und den
BSS-Komponenten zu tun haben.
Achtung:
- Pro Pattern Group können maximal 4 Patterns eingeplant werden.
- Es können im gleichen Schritt alte Patterns aus- und neue eingeplant werden.
- Aber: Am ESR dürfen maximal 15 "VirtAccs" (= Sequence Ids in LSA) gleichzeitig in Benutzung sein.Dies prüft LSA schon beim resident machen eines Patterns und wirft ggf. eine entsprechende Fehlermeldung. Es ist daher nicht möglich, ein weiteres ESR-Pattern einzuplanen, wenn dazu (auch nur temporär) mehr als 15 VirtAccs benutzt werden müssten. In diesem Fall muss erst ein eingeplantes Pattern ausgeplant werden, und danach in einem separaten Schritt das neue Pattern eingeplant werden.
1.1.1 Interessanter Code
1.1.1.1 bzgl. Supply
-
ScheduleManagementController#handleSupply
- anstoßen des Versorgungsvorgangs aus GUI
-
SupplyScheduleChangesTask
- Schritte beim Supply, Loggen in die Anwendungskonsole, Handhaben von"Undo-Supply"
-
SupplyHelper
- Details der einzelnen Schritte, insbesondere #updatePatternGroups ist etwas komplexer
1.1.2 Tipps im Fehlerfall
1.1.2.1 Was tun, wenn Probleme beim Ändern des Schedules/Versorgen auftreten?
- Alle Patterns auf einmal ausplanen (alle aus Schedule entfernen, Supply drücken)
- Im SnoopTool kontrollieren, das nichts mehr läuft (SCU ZT00ZM01 oder alternativ ZT00ZM02)
- Gewünschte Patterns wieder einplanen
Wenn die Schritte nicht möglich sind oder in Schritt 2 festgestellt wird, dass noch Events gespielt werden, obwohl alle Patterns erfolgreich ausgeplant wurden, liegt höchstwahrscheinlich ein Problem mit BSS vor (-> Fehlermeldungen anschauen).
NUR in Absprache mit der Services-Rufbereitschaft: Vollständiger oder teilweiser
Reset von BSS und LSA.
Falls der Generator/Data Master nicht resettet wurde (Services-RB fragen!), könnte es sein, dass anschließend noch Events gespielt werden, das ist in diesem Fall ok.)
1.1.2.2. Makerule-Fehler beim Non-Resident-Machen
Prinzipiell können Makerule-Fehler beim Resident- und Non-Resident von Patterns machen dadurch entstehen, dass bei (Non-)Resident machen Informationen z.B. über die verwendeten Chain- und Sequence-Indizes in die Timing-Events (bzw. die Timing-Event-Tabellen) hineingetrimmt werden: Bei resident werdenden Patterns werden diese Informationen den Events hinzugefügt, bei non-resident werdenden Patterns werden diese Informationen entfernt.
Normalerweise sollten bei beiden Trims (für Resident und für Non-Resident) die gleichen Fehler auftreten. Wenn es zu einer Makerule-Änderung kommt (d.h. inklusive LSA-Server-Release und -Rollout), während ein Pattern bereits eingeplant (und damit resident) ist, kann es jedoch sein, dass diese Fehler erst auffallen, wenn später jemand versucht, ein Pattern auszuplanen.
Dies lässt sich dann meist am besten dadurch lösen, dass jemand das Pattern mit einer 2-Tier-SchedulingApp aus dem Workspace heraus ausplant. Dazu kann dann temporär eine ältere (meist die vorletzte) Version von
lsa-server-gsi
eingebunden werden. Mit dieser Anwendungsinstanz sollten wegen der Verwendung einer veralteten LSA-Version über das Ausplanen hinaus keine weiteren Operationen (wiedereinplanen, trimmen, ...) durchgeführt werden! Wenn möglich, kann man die Aufgabe des Ausplanens an der/dem für die fehlschlagende Makerule bzw. den betroffenen Beschleuniger zuständige:n Modellierer:in überlassen. (SIS18: Holger Liebermann, ESR: Sergey Litvinov, Cryring: Ingrid Kraus))
(Idealerweise sollten bei Timing-betreffenden Makerule-Änderungen übrigens die potenziell betroffenen Patterns zuvor ausgeplant werden. Wird aber gern vergessen.
)
1.1.2.3 Was tun, wenn für eine PatternGroup kein Timing läuft (keine Events gespielt werden)?
Manchmal hilft es, ein einzelnes Pattern aus der betroffenen PatternGroup aus- und wieder einzuplanen. Damit wird der betroffene Timing-Core neu versorgt.
1.1.2.4 Ein Pattern, das im ParamModi-Expert-Tab zu sehen ist, ist nicht bei den verfügbaren Patterns zu sehen
Patterns, die aus den verfügbaren Patterns "entfernt" werden, werden normalerweise nicht gelöscht, sondern sind eben nur in der Scheduling App nicht mehr verfügbar.
Gelöscht werden Patterns von der Scheduling App höchstens dann, wenn sie z.B. noch nie eingeplant waren. Ausschlaggebend ist die ContextCategory. Die Patterns, die im ParamModi sichtbar sind, sind normalerweise ContextCategory.OPERATIONAL und werden von der Scheduling App nie gelöscht, wenn sie "entfernt" werden.
Um ein "nicht verfügbares" Pattern wieder "verfügbar" zu machen:
Kleiner Pfeil auf Schaltfläche "Hinzufügen" => "Pattern aus vorhandenen Patterns auswählen" => Gewünschtes Pattern auswählen.
1.1.2.5 In der Pattern Library fehlen Patterns oder gelöschte werden weiterhin angezeigt, Pattern-Umbenennungen werden nicht in die Kontext-Anzeige übernommen, Informationen innerhalb der Kontexte sind veraltet
Die Funktionalität der Pattern-Library bezogen auf dargestellte Patterns sowie deren Filterung wird durch das Projekt
common-context-widget-reactor bereitgestellt. Schedule-Änderungen, neu erstellte, gelöschte oder umbenannte Patterns werden nach einigen Sekunden erkannt und das Filterergebnis angepasst.
In der Pattern Library werden ausschließlich nicht-residente Kontexte aufgeführt. Änderungen, die durch Trims an nicht-residenten Patterns ausgelöst wurden, werden derzeit (2023-11-10) nicht beobachtet. Daher können die Informationen wie die enthaltenen Strahlparameter veralten.
Die Scheduling App bietet zwei Befehle, die ebenfalls zum
common-context-widget-reactor gehören, an, um die Anzeige der Pattern Library zu aktualisieren. Dazu im Hamburger-Menü rechts oben das Entwickler-Untermenü öffnen:
- "Pattern-Daten aktualisieren". Damit kann man ein ausgewähltes Pattern explizit aktualisieren. Für ein einzelnes Pattern sollte eine Aktualisierung nicht länger als ein paar Sekunden dauern.
- "Pattern-Bibliothek aktualisieren". Damit werden alle Informationen, die dem Hintergrunddienst common-context-widget-service-lib bekannt sind, aktualisiert. Diese Aktualisierung dauert sehr lange und lohnt sich nur, wenn überhaupt, nur wenn die Bibliothek viele falsche Informationen enthält.
1.2 Screen 2: Anlegen neuer Patterns
- Settings werden über mehrere Schritte in Chains/Pattern getrimmt - recht komplex
Hier könnten typischerweise Fehler auftreten, die mit
LSA-Trims und dem
Datenmodell zu tun haben
1.2.1 Interessanter Code
1.2.1.1 bzgl. Trimmen
-
PatternEditorController#trimSettings
und daraus aufgerufene Helfer-Klassen/-Methoden
1.2.1.2 bzgl. Erzeugen neuer Chains
-
CopyStandAloneChainAndInitIfNecessaryTask
und InitTemplateChainHelper
1.2.1.3 bzgl. Einbauen von Chains in Patterns
-
UpdateChainsInPatternTask
und ContextGenerationHelper#createPattern
2 Updates 2021-02
2.1 Unter der Haube: Erstellen von LSA-Chain-Objekten mit der common-template-chain-generation-lib
Umbau unter der Haube: Beim Erstellen von neuen LSA-Chain-Objekten auf dem "PatternEditor"-Screen und zur Ermittlung von Informationen über Chains wird die Library
common-template-chain-generation-lib von Holger Liebermann verwendet.
2.1.1 Funktionsumfang
Statt für jeden Strahlweg eine exakt passende Template Chain (Standalone-Chain mit ContextCategory TEMPLATE) vorhalten zu müssen, gibt es hauptsächlich noch "Basic Template Chains" für die Ringe. Die Chain-Teile, die die Transferstrecken vor/hinter dem Ring abdecken, werden von Holgers Lib dynamisch dazugeneriert. Das spart Wartungsaufwand für die Modellierer.
- Es gibt weiter "normale" Template Chains z.B. für Chains ohne Ring (Cryring-Injektor) oder für Spezialfälle - über die Namensauswahl sind sie auffindbar!
- "Basic Chains" tauchen nicht in der Namensauswahl aus, weil man aus ihnen allein keine "durchrechenbaren" Chains machen kann (dazu werden Angaben über die Transferstrecken davor/danach benötigt).
Holgers Library liefert auch Informationen über unterstützte "Features" für einen Ring, d.h. ob es Checkboxes/Dropdowns zur Auswahl geben soll für:
- Chimney
- Merging
- Zwischen-Flattop
- Extraktionsarten (z.B. wird Extraktionsart CHARGE_CHANGE nur am ESR unterstützt)
- d.h. falls da jemand fragt "Warum kann ich für Ring X Extraktionsart Y auswählen, aber für Ring Z nicht?" -> wird vermutlich vom Modell nicht unterstützt, ggf. Holger nach Details fragen!
Die meisten angebotenen Feature-Kombis sollten vom Modell unterstützt werden, aber nicht bei allen ist das zwangsläufig der Fall. Das hängt davon ab, ob der/die zuständige Modellierer:in eine entsprechende Basic-Chain zur Verfügung gestellt hat. Zuständige Modellierer sind: SIS18: Holger Liebermann, ESR: Sergey Litvinov, Cryring: Ingrid Kraus.
2.1.2 Zugriffe auf die Library
Aus folgenden Packages:
-
de.gsi.fcc.applications.scheduling.patterneditor.chaininfoarea.ringoptions
-
de.gsi.fcc.applications.scheduling.patterneditor.utils.chainsforpatternbuilding
- insbesondere
ChainDescriptorBasicMatchingUtils
und ChainsForPatternBuildingHelper
- Fehler beim Erzeugen einer Chain: DynamicChainCreationException, Details im Cause
2.2 Unterstützung von Chains für Maschinenexperimente
Für Maschinenexperimente stellen die Modellierer z.T. Chains bereit, die nicht für den normalen Betrieb gedacht sind. Diese Chains haben die LSA-ContextCategory MD (Machine Development). Es gibt eine Menüoption, um diese Chains ggf. zusätzlichen zu den normalen TEMPLATE Chains komfortabel über die Scheduling App einplanen zu können:
Standardmäßig ist diese Option deaktiviert.
Stolperfalle für Modellierer (eher nicht für Operateure): Wenn nur der SIS100-Ring über die Strukturauswahl ausgewählt wird, wird keine Dropdown für die Extraktionsart angeboten.
Das liegt daran, dass es für den SIS100 bisher (!) keinen nachfolgenden Particle Transfer (PT) gibt. Dieses Verhalten ist Absicht/korrekt, denn es ergibt normalerweise Sinn: Unter der Annahme, dass für die ganze zu benutzende Beschleunigeranlage Particle Transfers existieren, kann aus einem Ring, für den es keinen Nachfolge-PT gibt, niemals extrahiert werden.
Hinter dem SIS100 soll es zukünftig natürlich Transferstrecken und somit PTs geben, im Moment ist das jedoch noch nicht der Fall. Die Modellierer tun aber in ihren Modellen bereits so, als gäbe es Extraktionsmöglichkeiten, und stolpern dann darüber, dass die Scheduling App ihnen keine Auswahl anbietet.
Lösung: Die zu verwendende Template Chains soll per Namensauswahl ausgewählt werden.
(Anmerkung: Anne hat einen Workaround, der die Auswahl der Extraktionsart am SIS100 explizit ermöglicht, schonmal vorbereitet. Holger meinte aber, dass das bisher noch keine Anforderung sei, also wurde der Workaround nicht eingebaut.)
--
AnnekeWalter - 02 Feb 2021