 |
|
Release 17
Termin: 6. Mai 2010 Prioritäten:1 - Muss mit der aktuellen Release fertig werden, da dringend benötigt
2 - Soll mit der aktuellen Release fertig werden, aber (noch) nicht dringend
3 - Wünschenswert, da spürbare Erleichterung für Betrieb / Arbeit der Gruppe
4 - Ganz nett, nice to have
5 - Beruhigt irgendwen irgendwie, stört zumindest nicht
6 - Stört / behindert, besser gar nicht angehen
Beim Implementieren bitte wieder die Merkliste und die Windows-Merkliste beachten! Die Icons bedeuten:
- der Punkt bedarf einer klärenden Diskussion. 
- zum Punkt gibt es ergänzende Bemerkungen. Das Icon ist klickbar. 
- der Punkt ist auf die nächste Release verschoben. 
- der Punkt ist erledigt.
Klären
| Nr. | Name | Prio | Projekt | |
|
|---|---|---|---|---|---|
| 1 | LH | 1 | Erweiterung der Device-Access-IDL-Schnittstelle: | ||
| 1.1 | LH | 1 | - um einen Prozessnamen. | |
|
| 1.2 | LH | 1 | - Property-spezifische Timeouts? | |
|
| 1.3 | LH | 1 | - Weitere Konnektierungsart (für IPS)? | ||
| 1.4 | LH | 1 | - 64-Bit Integers | |
|
| 1.5 | LH | 1 | - Geräte-Reservierung | |
|
| 2 | LH | 1 | Für mutex zwischen GuP und SE wird ein echtes testAndSet() ( read-modify-write via VME-Bus) benötigt! Klären, wie das geht. Siehe Luis Email Test-and-set unter PowerPC vom 8.Aug.08 aber auch Udos Email USRs: Mutexe für die Bearbeitung von Gerätedaten? vom 15.Feb.2010. |
||
| 3 | LH | 2 | Soll beim Ende von Konnektierungen immer das userCallback->exit() aufgerufen werden? |
|
|
| 4 | LH | 2 | Erweiterung der Konstantentabelle für MX und MD? | |
|
| 5 | SMa | 4 | Fehlerbehandlung in Klasse NsrvException ggfs. ersetzen durch AccDevException? Informationsweitergabe ueberdenken. | |
|
| 6 | LH | 3 | USR-Absturz (z.B. NULL-Ptr) soll nicht zum Devman-Absturz führen. | |
|
| 7 | Kain,LH,SMa | 2 | Loglevel des devman umsetzen ueberarbeiten, Eingaben irritierend! (InfoRcvThread) |
Bemerkungen
Ergänzende Bemerkungen, Hinweise usw. zu obiger Liste Klären.| Nr. | Bemerkung |
|---|---|
| 1.1 | Im Moment kann man im Logfile nur sehen, welcher User z.B. eine Gerätereferenz beim Nameserver nachfragt oder eine Konnektierung aufsetzt. Das ist zu wenig Info. Z.B. laufen alle Operatingprogramm unter dem selben User siskons. Da ist es schwierig, einen Prozess zu ermitteln, der sich fehlerhaft oder nicht normgerecht verhält. Die Erweiterung muss natürlich auch in Userface/UfcServer eingebaut werden. Sind die Namen eindeutig genug? Vielleicht besser: IP-Adresse des Hosts + Process-Id
UK, 16.Feb.2010: In corbaifc.idl ist deklariert, dass bei jedem Zugriff (als Teil der AccessId) IP-Adresse und Process-ID des Aufrufers mitkommen. Um auch Zugriffe aus Userface rückverfolgen zu können, müsste man noch auf die VMS-Seite zurückmelden, welcher Userface-Server für den Client-Prozess gestartet wird, und das ins Kontrollsystem-Logfile schreiben. Der Rechner-Name des Userface-Servers wird inzwischen zurückgemeldet, aber an die Prozess-ID hat wohl keiner gedacht.
UK, 20. Apr. 2010: Anstatt bei jedem Gerätezugriff viele Zusatzinformationen zu übertragen (mit der Schwierigkeit, dass diese zentrale Schnittstelle geändert werden muss, wenn weitere Informationen gewünscht werden) rege ich an, diese Schnittstelle auf zentrale Kennungen zu beschränken - und das sind Rechner-Kennung (IP-Adresse) und Prozess-Id. Auf Client-Seite sollte jedesmal, wenn ein Programm startet, was die DevAcc-Schnittstelle beinhaltet, die Prozess-Id in einem zentralen Logfile festgehalten werden. Ähnlich, wie heute schon festgehalten wird, wenn sich ein Programm an den Netman konnektiert. In dieses Logfile kann zusätzlich jede Information geschrieben werden, die man gerne hätte. Was das konkret ist, kann sogar je nach Tagesanforderung erweitert werden - ohne die zentrale Geräteschnittstelle ändern zu müssen. |
| 1.2 | Als Idee (UK, 9. Mar 2010): Jedes Geräte-Objekt könnte sich für jede Property einen spezifischen Timeout merken und diese über eine Property lesbar machen (Liste, für alle Properties in einem Zugriff). Beim Instantiieren des Device-Objektes auf der Client-Seite (in der Anwendung) könnten diese Timeouts von der Serverseite eingelesen und sich gemerkt werden. Das verzögert die Instantiierung etwas, wird aber nicht so schlimm sein. Und wenn doch: Diese Timeouts braucht man sich nur einmal pro Gerätemodell merken. Das Gerätemodell kann mit der CORBA-IOR vom Nameserver mitgeliefert werden. Verwendung der Timeouts: Vor jedem synchronen Property-Aufruf wird im ORB der jeweilige Timeout gesetzt. Das kann nicht viel kosten, letztlich muss nur irgenwo eine Zahl ausgetauscht werden. Aber: Damit das Ganze auch in einer Multi-Threaded Umgebung funktioniert, muss man das relativ teure supportPerThreadTimeOut einschalten. |
| 1.4 | Die dafür noch von Klaus angepassten bzw. erweiterten und von Lui korrigierten Dateien liegen zur Zeit auf ~hechler/scratch/klaus. |
| 1.5 | Erst mal eine Strategie entwerfen. Entweder via Property oder via zusätzlicher Methode der Klasse Device ein Gerät reservieren. |
| 3 | Es scheint immer (mal) wieder Probleme zu geben, dass das eigentliche User-Callback-Objekt nicht mehr da ist oder schon anderweitig (für die nächste Konnektierung) benutzt wird, die exit() Methode aber noch aufgerufen wird. Zudem ist es nicht immer ganz einfach, nach einem disconnect() noch auf das exit() zu warten. Man kann ja auch sagen: wenn das disconnect() mit ok zurück kommt, dann reicht mir das. Oder evtl. ein disconnect() mit einem (optionalen) Parameter noexit basteln, der dazu führt, dass das exit() nicht auch noch aufgerufen wird. Aber auch ein Signal Handler, der das Segmentaion Fault-Signal auffängt ( callback-corba.cc, Zeile 103), wäre denkbar. |
| 4 | Unterscheiden Imax und Inenn. Timeoutzeit für CONNECT und POWER? |
| 5 | Die Klasse NSrvException wird lediglich innerhalb des Nameservers verwendet. Exceptions nach aussen sind AccDevExceptions. |
| 6 | Die Nutzung eines NULL-Pointers in einer USR ( T* p = NULL; p->element = 42;) lässt den ganzen Devman abstürzen mit segmentation fault. Kann man solche Signals abfangen, ähnlich wie wir's in MOPS etwa mit Buserrors usw. gemacht haben? Das würde vielleicht heißen, nur den Thread der fehlerhaften USR, also das Device-Objekt, zu beenden und neu aufzusetzen. |
Umfang
| Nr. | Name | Prio | Tage | Projekt | |
|
|---|---|---|---|---|---|---|
| 1 | Property-Beschreibung mit XML und Code-Generierung | |||||
| 1.1 | NN | 3 | Doku erstellen. User's Manual zum Erstellen einer USR-XML-Datei. In englisch! | |||
| 2 | Geräte-Software | |||||
| 2.1 | Umstellung Gerätemodelle | |||||
| 2.1.1 | Kain | 1 | PZU, PZUI, PZUS | |||
| 2.1.2 | GSch | 1 | IPS | |||
| 2.1.3 | LH | 1 | DTTC | |
||
| 2.1.4 | Kain | 1 | FG | |||
| 2.1.5 | GuRi | 2 | MB | |||
| 2.1.6 | Kain | 2 | MK | |||
| 2.1.7 | NN | 2 | DTP | |||
| 2.2 | Umstellung VME-Rahmen | |||||
| 2.2.1 | NN | 1 | K2XCG48_ -> K2XCG01 |
|||
| 2.2.2 | NN | 1 | K4XCG49_ -> K4XCG02 |
|||
| 2.2.3 | NN | 1 | KUECG4D_ -> KUECG03 |
|||
| 2.2.4 | LH | 1 | KUECG56_ -> KUECG04 |
|||
| 2.2.5 | NN | 1 | K5XCG59_ -> K5XCG01 |
|||
| 2.2.6 | NN | 1 | K3XCG5C_ -> K3XCG01 |
|||
| 2.2.7 | NN | 1 | KE3CG94_ -> KE3CG02 |
|||
| 2.x | KHer | 2 | Mutexe für die Schrittmotorsteuerung auprobieren. Siehe Punkt 2 unter Klären. | |||
| 3 | Devman | |||||
| 3.1 | Kain | 2 | onlineTest() von den lifeCtrlThreads aus ausführen lassen? | |
||
| 4 | Nameservice and Access Rights | |||||
| -- | ||||||
| 5 | Userface | |||||
| -- | ||||||
| 6 | Versionsverwaltung, Releases, Scripte | |||||
| -- | ||||||
| 7 | Linux und ELDK | |||||
| 7.1 | KHer | 2 | Linux im Flash bzw. in der RAM-Disk. | |||
| 8 | Erweiterungen Device Access Interface | |||||
| 8.1 | LH | 1 | Erweiterung der Device-Access-IDL-Schnittstelle. Siehe Punkt 1 unter Klären. | |||
| 9 | Subscription Service | |||||
| 9.1 | LH | 2 | Überarbeitung der Software und Fehlerbehebung. | |||
| 9.2 | LH | 2 | Timeout auch in DeviceCallback::exit() einbauen. |
|||
| 10 | Alarme | |||||
| -- | ||||||
| 11 | Allgemeines & Kleinigkeiten | |||||
| 11.1 | UK | 1 | Explizite Kodierung der Copy-Konstruktoren und Zuweisungsoperatoren. Siehe Udos Email default copy-constructor/assignment operator vom 5.Feb.2001. | |||
| 11.2 | LH | 2 | Wenn generell auf UTC umgestellt wird, die festen Zeit-Offsets in der Geräte-Software der Pulszentralen (auch SWPZ) und in MAX entfernen. | |
Bemerkungen
Ergänzende Bemerkungen, Hinweise usw. zu obiger Liste Umfang.| Nr. | Bemerkung |
|---|---|
| 3.1 | Sorgt dafür, dass der online-Zustand der Devices regelmäßig geprüft wird, bei VmeDevice würde geprüft, ob alle devices eines ec noch in der dbs eingetragen sind. |
| 11.2 | Erübrigt sich für PZU und PZS, wenn diese unter V09 laufen. Bei der Umstellung muss der Offset raus, da Linux schon mit UTC arbeitet. |
Bugs and Feature Requests
To report bugs or request features, use Bugzilla from now on.
Accnomen
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding Foswiki? Send feedback