* Die Implementierung der USRs geht bisher (21.Sep.04) davon aus, dass *nur ein* Gerätemodell bearbeitet wird. Weitere Gerätemodelle müssen "in einem eigenen main()" implementiert werden! -> Ok! Jetzt (12.Nov.04) gehen auch zwei Gerätemodelle (MX, PLA). Aber siehe die Punkte zu "Shared Library" weiter unten. * In <epmod>-usrs und <epmod>-device den namespace aktivieren und testen. -> Ok, allerdings bisher *nicht* für <eqmod>-dev-def.h * Was machen wir mit den Default- und den Therapie-USRs? -> Ok, die werden (im Moment, Jan.05) inkludiert, wie bisher. * Kann man nicht statt zwei Klassen ReadFieldS und WriteFieldS *nur eine* Klasse FieldS machen, die *beide* Methoden, read() *und* write() implementiert? ->Das geht nicht so einfach, weil jede USR u.a. mit den Eigenschaften PROP_MODE_READ/WRITE/CALL und MEDLOCK_NONE/VRTACC/ALL instanziiert wird. Lese- und Schreib-USR unterscheiden sich aber in diesen Eigenschaften. Belassen wir's also zunächst mal bei der Zuordnung eine Klasse, eine Methode. * Es gibt ein *kleines* Kompatibilitätsproblem, wenn wir Istwert- Properties nun mit "A" statt "I" am Ende (CURRENTI -> CURRENTA) bezeichnen. Userface wird nach wie vor auf TK1MU1(CURRENTI) zugreifen wollen. Behalten wir also die deutschen Bezeichnungen "I" (für Istwert) bei, statt die englische Bezeichnung "A" (für Actual Value) zu benutzen? "S" kann man ja glücklicherweise sowohl als Sollwert als auch als Set Value begreifen. -> Ok! Alles heißt wieder "SowiesoI". * USR-Support: Wie kann ich in checkAccessState() (ehemals getStandardParameter()) testen, ob ein Gerät gerade gelockt ist? Dazu brauche ich die Property-Kategory, die 'N', 'V' oder 'L' sein kann. Diese ist bisher im XSR-Header mitgekommen. Die zweite Info ist 'security' im DPR der SE. Das müsste eine Methode (der Klasse ???) sein. -> Ok! Info kriegt die USR beim Instanziieren mit. * Eine weitere Methode muss das Gerätemodell der SE-Software zurückgeben, damit gecheckt werden kann, ob die USRs dazu passen. -> Ok! Mit der Methode eqModNum(). * Default-USRs können nicht mehr auf die gerätespezifischen Daten im DPR zugreifen, z.B. um Status zu lesen, da die Methode devDataP(), die den Pointer auf die Gerätedaten liefert, zur Geräteklasse (z.B. MX) gehört und nicht zur Klasse VmeDevice. Einziger Ausweg: Status und alles andere über die Command-Communication-Area übergeben bzw. weitere Methoden der Klasse DevInfo (oder EcInfo?) erfinden. Betroffen sind folgende Default-USRs: RDefStatus RDefActive RDefInfostat RDefPower RDefEqmError RDefVersion -> Ok, DevInfo-Methoden bzw. Status via CmdComArea. * Die Klasse DevInfo (oder welche?) muss folgende Methoden zur Verfügung stellen. bool isMedMember(); // Gerät ist Therapie-Teilnehmer UWord workMode(); // Gerät ist im Normal-, Analyse-, Parameter- oder // Einstell-Modus; evtl. EnumMedOpermode als Returntyp ULong dataId(); // DataID des Gerätes aus dem DPR // (bisher mpDevDefDisp[logDev].dataId) bool hasLocalMemory(); // dpr.eqmodLocalMemoryType != LOCMEM_NO_NEED; ist // eigentlich geräte-MODELL-spezifisch, also // *SE* "has local Memory", nicht Device void getVersion(EcComponent c, // mit "enum EcComponent {ECP_ECM, ECP_MIL, ECP_EQMS, &VersString v); // ECP_EQMVARIANT};" oder so. Man könnte evtl. auch // 4 verschiedene Methoden machen. UWord activeStates(); // Aktivzustand aller VrtAccs -> Ok! Und weitere Methoden. * Welchen Namespace sollen die Default- und die Therapy-USRs bekommen? Zur Zeit haben sie keinen. Zur Zeit werden sie noch von den gerätemodell-spezifischen USRs includiert. Was ist, wenn man sie einfach innerhalb des "namespace EqModGm { ... }" includiert? Sie wären damit im jeweiligen Namespace der gerätemodell-spezifischen USRs. -> Ok, genau so isses realisiert. * Die Includes add-xxx-usrs.cc für die Default- und die 3 Therapie- USR-Dateien erfinden. -> Ok, erfunden. * Wie kommt denn eigentlich die Default-USR REqmError an die EQM-Errors? Bisher wurde alles direkt aus dem DPR gelesen. Und jetzt? - Direkt lesen geht nimmer - Eine Command-Communication-Area ist zu klein, readCommand() scheidet also aus. - Eine Methode devErrorP() entsprechend devDataP() erfinden? Brauchen wir (dann) eigentlich auch eine Methode devDefP()? "DevData", "DevErr" und "DevDef" sind jedenfalls die Bereiche im DPR, die es für jedes Gerät gibt. Falls es devDefP() geben wird, entfällt die eine oder andere oben erwähnte Methode, z.B. workMode(), da man dann via Pointer direkt auf das Element zugreifen kann. Die gleiche Frage, wie kommt man an die Daten, gilt auch für die Default-USR InfoStat. -> Ok! Es gibt entsprechende Klassen und Methoden * Im Zuge der Anpassung von =WDefActive= - es wird nur noch vrtAcc als Parameter übergeben, nicht mehr logDev - muss auch das =ActiveEQM= entsprechend angepasst werden. -> Ok, erledigt. * Die Therapie-USR "Write Security" haben wir als "hidden property" implementiert. D.h., für sie gibt es keinen Eintrag in der Mapping- Tabelle, so dass man, etwa via NODAL, nicht so einfach zugreifen kann. Hintergrund ist, dass man ein gelocktes Gerät damit jederzeit wieder freigeben kann, was nur in Problemfällen von Spezialisten genutzt werden soll. Die Property ist im Therapiebetrieb _nicht_ gelockt! Das wird im Zusammenhang mit Access Rights noch mal bedacht. -> Ok, kommt mit Access Rights. * Die Doku der USR =EqmError= in default-usrs.hh muss ergänzt werden. Ein Element des Error-Ringpuffers besteht aus _2_ ULongs! Im ersten sind 4 Bytes, die vrtAcc, logDev, eqmNr und intSts enthalten. Im zweiten ULong ist der eigentliche Fehler. -> Ok, erledigt.