This FESA class will inherit from the FESA-Class-BASE-ACU-PowerSupply, in order to get the common public interface.

Documentation about the device which will be controlled by this class can be found at: Winfilesvg:BEL$Root\belgroup\Projekte\Mini-CS for CEA\cea-docus

More information will be added soon ...

---

Email Ralf Huhmann

---

Hallo Kollegen,

im Rahmen unseres MiniKontrollSystems (MCS) für Saclay müssen ja von der GSI noch einige FESA-Klassen (vielleicht auch nur eine Klasse, aber jedenfalls mehrere Geräte) für die Power-Supplies gebaut werden, die Integration mit SCU und ACU erfolgen, sowie Integration, Aufbau und Test der FESA-Laufzeitumgebung innerhalb des MCS erfolgen, das endgültige Produktionssystem aufgebaut und geliefert werden.

Im Projektverzeichnis "belgroup\Projekte\Mini-CS for CEA" liegen alle Informationen, denen wir entnehmen können, welche Geräte es gibt und wie die Sicht der CEA-Kollegen auf diese Geräte ist (d.h. welche Properties sie steuern wollen). Letzteres ist aber nur ergänzend zu sehen. Im wesentlichen können alle Information und Abstimmungen die Power-Supplies betreffend mit den EET-Kollegen (H.Ramakers, J.Trueller) erfolgen. Diese sind die entscheidenen Ansprechpartner für das Design der FESA-Klassen. Dieses Design muss dann natürlich mit AP abgesprochen werden (Review).

Also, wenn wir mal eine typische Milestoneliste aufsetzen (von der Art wie wir sie gerne mit Cosylab absprechen) könnte dies so aussehen:

- FESA class Design ready dd.mm.yy
- FESA class Design review dd.mm.yy
- First version of runtime FESA server part (not neccesarilly SCU, no ACU) dd.mm.yy
- First version of runtime FESA class with driver (with SCU, with ACU) dd.mm.yy
- Review of first runtime version dd.mm.yy
- Final version of runtime version dd.mm.yy
- Integration into MCS (FAT) dd.mm.yy
- Integration into production system dd.mm.yy
- Deployment to Saclay dd.mm.yy
- SAT in Saclay dd.mm.yy

Hier fehlen die Datumsangaben. Mir wäre es sehr (sehr-sehr-sehr) lieb, wenn wir hier wenigstens eine Ahnung hätten, wie Eure Planungen aussehen. Wenn wir nämlich den äußeren Zeitrahmen ernst nehmen, drängt die Zeit: 2.Quartal 2013 MCS produktionsreif installiert in Saclay.

Um die Entwicklung der FESA-Klassen anzustossen, schlage ich vor: ein abstimmendes BEL-Meeting nächste Woche (15.-19. Oktober), danach lade ich zu einem Meeting mit den EET-Kollegen ein.

Viele Grüße
Ralf
---

---

Email Ludwig Hechler

---

Hallo,

ein paar Infos zu Power Supplies pLinac Saclay:

- Es wird zwei FESA-Klassen geben, die weitgehend
  den heutigen Gerätemodellen MD (DC-Magnete) und 
  IQX (Quellen-Netzgeräte) entsprechen.

  - 2 MD, 1 IQX auf Quellenpotential
  - 6 MD, 2 IQX auf Erdpotential

  Alle Geräte werden via SCU/ACU angesteuert.

  Zumindest für die MD-Geräte auf Quellenpotential 
  wünscht sich Jürgen Trüller eine weitere Property
  (VOLTAGEI), um den Spannungsabfall am Verbraucher
  auslesen zu können.


- Die Geräte auf Quellenpotential werden über Licht-
  leiter bedient, wobei SCU und ACU auf Erdpotential
  liegen. 

  Zur Zeit ist nur _eine_ SCU/ACU-Kombination für 
  _alle_ drei Geräte auf Quellenpotential vorgesehen.
  Das heißt, dass eine SCU drei Geräte von _zwei_
  verschiedenen FESA-Klassen bedienen soll (Licht-
  leiter und zwei Umsetzer optisch/elektrisch sind
  teuer und eine zweite Strecke (zur Zeit) nicht im
  Etat.). Alex meint, dass das für FESA kein Problem
  darstellt. Ob man gleich bei einer der ersten 
  Implementationen so weit weg vom Standard will, 
  der da heißt: "Ein NG, eine SCU", sollte man noch
  mal bedenken.


- Vorraussetzung, um mehrere Geräte auf einer SCU/ACU
  betreiben zu können, ist, dass das Registermodell 
  der ACU festgelegt sein muss. Ob das mittlerweile
  so ist, weiß ich nicht. 


- Für die ACU-Zugriffe halte ich einen expliziten 
  ACU-Treiber (synchron bzw. blocking) für sinnvoll.
  Der könnte z.B. auf dem allgemeinen synchronen 
  SCU-EB-Treiber aufsetzen und in etwa so aussehen

    int32_t readAcu(int16_t devNum, int16_t regNum, int16_t& value);
    int32_t writeAcu(int16_t devNum, int16_t regNum, int16_t value);

  wobei devNum den Registersatz (für das n-te Geräte)
  auswählt, regNum das Register angibt, value der
  eigentliche Wert ist und jede Funktion einen 
  Fehlerstatus zurückgibt.

  Wenn meherere Geräte (-objekte) ein und denselben
  Treiber benutzen, muss man noch mal über mutexed 
  access und reentrance nachdenken! 


Gruß,
L.