You are here: Foswiki>Frontend Web>PPCDevelopments>Usr-zutun (18 Aug 2011, UnknownUser)Edit Attach
  • Wie dokumentieren wir die Default- und Therapie-USRs? Sollen die entsprechenden Header-Dateien (z.B. default-usrs.hh) ins Doxyfile aufgenommen werden? Oder soll man besser eigenständige Abschnitte haben, die die Gerätemodell-Doku nur referiert. Wo bringt man diese Abschnitte aber unter?

  • Die Property EMODLIST des Devman sollte auch zurück liefern:
    • die Gerätemodelle des GuP (DMAN) und der SEs (EC) sowie
    • die jeweiligen Versionsnummern der Gerätemodell-Software.

  • DevMan-Properties sollen/können nicht alle implementiert werden. Welche sind noch notwendig? Was muss nachgebaut werden, damit man COMP_TEST, evtl. eingeschränkt, weiterhin nutzen kann? Siehe dazu Interfaces für Systemeigenschaften

  • Default-USRs und Therapie-USRs sollten perspektifisch eigenständig compilierbare Einheiten sein, also nicht mehr von gm-usrs.cc inkludiert werden. Das erfordert aber erhöhten Implementationsaufwand (Design Pattern?), da es zum Teil recht enge Abhängigkeiten, z.B. vom DPR-Layout eines bestimmten Gerätemodells, gibt.

  • Die Sache mit den "actDevConstants()" und "getDeviceParameter()" in den Default-USRs ist noch nicht implementiert. Ich muss mir erst mal klar werden, wie das überhaupt bisher funktioniert. Das (und mehr?) braucht man wohl auch für die Standard-USRs.

  • Property implementieren, die eine Liste bestehender Konnektierungen zurück liefert. DevMan: alle, Geräte: nur die Konnektierungen für dieses Gerät.

  • Istwerte im Ringpuffer: Slave-Daten aus zurückliegenden Zyklen verfügbar halten. Alte Istwerte nicht einfach überschreiben, wenn neuere vorliegen, sonderen in einem Ringpuffer auch zurückliegende Daten aufheben.
    • Ringpuffer muss für Zugriffe der USR transparent sein, solange keine ergänzenden Angaben erfolgen.
    • Zusätzlich etwas bauen, um gezielt ältere Datensätze lesen zu können? (damit wäre das gezielte Einsammeln von Daten eines ganz bestimmten Zyklus realisierbar, der Ringpuffer muss dafür genügend Tiefe haben, um alle Datensätze für z.B. 5s bereithalten zu können, Kain)
      • Macht wohl wenig Sinn, wenn Daten wie im Unilac mit hoher Rate anfallen können (allerdings fallen dann auch immer relativ wenig Daten an, sodass der Ringpuffer sehr tief sein kann, Kain)
      • Besser: Monitor / Stream Funktionalität
    • Für den Fall, dass ein virtueller Beschleuniger selten läuft: Etwas zaubern, damit für jeden virtuellen Beschleuniger mindestens ein Datensatz (der jeweils letzte) aufgehoben wird
    • Ring-Puffer kann auch für Master-Daten Sinn machen:
      • Daten periodisch aufnehmen
      • Ring-Puffer beinhaltet dann Historie der Daten
Edit  | Attach | Print version | History: r27 < r26 < r25 < r24 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r27 - 18 Aug 2011, UnknownUser
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback