Aufbau Device Access

Table of Contents

Multiplexing: Virtueller Beschleuniger

Das multiplexing-Kriterium im bestehenden Kontrollsystem ist der "virtuelle Beschleuniger".

Virtueller Beschleuniger: Nummer im Bereich 0 .. 15. Ein virtueller Beschleuniger enthält in Unilac und SIS18 die Daten für einen ganzen Zyklus, im ESR entspricht er in etwa einen Beam-Prozess

Es gibt neben multiplexed Properties (oft als Slave-Properties bezeichnet) oftmals auch echte DC-Properties (auch als Master Properties bezeichnet), sowohl bei Setting als auch bei Acquisition Werten.

Front-End Ebenen

Front-End ist aufgeteilt in zwei echte Ebenen: SE/EC und GµP. Beide stecken gemeinsam in einem VME-Rahmen, je ein GµP mit einer oder mehreren SEs.

SE/EC-Ebene

Hier sind die Geräte physikalisch angeschlossen. Anschluss der Geräte an die SEs/ECs ist immer über den MIL-Bus. An einen MIL-Bus sind in der Regel mehrere Geräte angeschlossen, auch schon mal 30 oder mehr Geräte.

Jede SE/EC bedient nur jeweils einen Typ von Geräten (also nur Power Supplies oder nur Profilgitter). Die Software ist organisiert:

• ECM (Equipment Control Monitor), verwaltert und managed die Software auf SE/EC
• EQM (Equipment Control Module), implementiert die eigentlichen Aktionen, insbesondere die gerätespezifischen. Die EQMs entsprechen den FESA Real-Time Actions

Jede SE/EC hat auch eine Nomenklatur und eigene Properties.

Auf den SEs/ECs läuft ein schlanker Betriebssystem-Kernel (pSOS). Es gibt keine Shell oder ähnliches. Zugriff ist nur möglich über den GµP oder über eine Terminal-Schnittstelle.

GµP

Die SEs/ECs werden von den übergeordneten GµPs (Gruppen-Micro) verwaltet. Netzwerk-Zugriff erfolgt nur auf den GµP. Die Kommunikation mit den SEs/ECs erfolgt über einen gemeinsames Shared Memory. Dieses Shared Memory liegt auf den SEs/ECs).

Die Software ist organisiert:

• DevMan (Device Manager) verwaltet das Ganze.
• USR (User Sevice Routine): Implementieren die Funktionalität der Properties, je eine USR pro Property (Schreiben und Lesen getrennt). Die USRs entsprechen den FESA Server-Actions.

Jeder DevMan hat selber eine Nomenklatur und auch Properties, über die man z.B. die Konfiguration auslesen kann.

Der GµP läuft unter Linux. Einloggen als root wie auf den SCUs. Jeder GµP verwaltet in der Regel mehrere SEs/ECs.

Non-VME Ansteuerungen

An ganz wenigen Stellen gibt es auch eine Geräte-Ansteuerung ohne SE/EC. Beispiel: Cosylab Schrittmotorsteuerung. Hier laufen nur DevMan und USRs, der Zugriff auf das Gerät erfolgt aus den USRs.

Geräte-Modellierung

Jeder Geräte-Typ (Netzgerät, Profilgitter, ...) erfordert eine spezifische Behandlung. Die dafür erforderliche Software ist auf den SEs/ECs in einem Satz von spezifischen EQMs und auf dem GµP in einem Satz von spezifischen USRs realisiert. Beide zusammen (EQMs und USRs) werden als Gerätemodell-Software bezeichnet, sie entspricht der FESA-Klasse.

MIL-Bus

Der MIL-Bus ist ein Bus-System zur Kommunikation mit mehreren Geräten. In der GSI sind die Front-End Controller (SE/EC oder SCU) der Master, die Geräte reagieren nur. Über den MIL-Bus kann man 255 verschiedene Kommandos absetzen (8 Bit, 0 gibt es nicht), davon sind 127 Schreib- und 127 (oder 128?) Lese-Kommandos. Bei jedem Kommando kan ein 16-Bit Daten-Wort mitübertragen werden.

Die Addressierung der verschiedenen Geräte an einem Bus erfolgt über eine 8-Bit Adresse (1..255). Diese Adresse muss am Bus eindeutig sein.

Zum Anschluss der Hardware steckt in jedem Gerät eine Anschluss-Karte, die IFK/IFB (Interface-Karte/Interface-Board), an die der MIL-Bus angeschlossen werden kann und an einem zweiten Anschluss zum nächsten Gerät weitergeführt werden kann. Am letzten Gerät des Bus wird auf dem zweiten (Ausgangs-) Anschluss ein Abschluss-Stecker benötig. Fehlt der, funktioniert der Bus in vielen Fällen trotzdem - aber oft gibt es dann misteriöse Fehler.

Timing-System

Die Ausführung der Echtzeit-Aktionen wird von einem Timing-System gesteuert. Auch das entsprechend wie bei FESA und Timing-Master, aber einfacher.

Die Signale im Timing-System sind recht einfach aufgebaut:16-Bit Messages, aufgebaut aus 8 Bit Event-Code (es gibt also maximal 255 verschiedene Timing-Events: Timing-Events MIL-Timing), 4 Bit der virtuelle Beschleuniger und 4 Bit spezifische Bedeutung (nur noch im Unilac verwendet). Timing-Events im Bereich über 200 haben teilweise Sonderbedeutungen, so wird darüber die Uhrzeit verteilt.

Als Verteilmedium dient ein etwas außer der Reihe verwendeter MIL-Bus, deshalb wird das Timing-System auch als MIL-Timing bezeichnet.

Wie für FAIR gibt es mehrere Timing-Bereiche, denen jedes Gerät zugeordnet ist. Die Unterteilung ist vergleichsweise grob, es gibt nur drei Bereiche: Unilac, hier aber noch sieben Unterbereiche sowie SIS18 und ESR. Die Hoch-Energie Strahlführung wird, wie schon zuvor, vom Timing des SIS18 mitversorgt, in Sonderfällen auch vom Timing des ESR (umsteckbar). Im Unilac gibt es sieben Unerbereiche (jeweils für die drei Ionenquellen, für den HLI, den HSI, für den Alvarez und de Experientierhalle, und für den TK). In allen Bereichen, die vom jeweiligen Strahl durchlaufen werden, werden gleichartige Eventfolgen verschickt, wobei die Ionenquellen-Bereiche dazu passende Eventfolgen haben.

Für die Device-Access Geräte in SIS18 und ESR speist der Timing-Master Timing-Events ein, die identisch zu dem sein sollen, was die frühere Pulszentrale verschickt hat. Für Device Acces und für die neue Welt (FESA) werden jeweils getrennte Timing-Events verschickt (jeweils getrennte Nummernbereiche). Über einen Umsetzer, der am White-Rabbit Timing-Bus mithört, werden die von Device-Access benötigten Timing-Events im bestehenden MIL-Timing-System verschickt. Im Unilac läuft weiterhin die bestehende Pulszentrale (GU__ZZ).