Verbesserung der Messmodul-GDI-Treiber

Hier werden Anregungen für die LAPI-Version 2.0 gesammelt und diskutiert.

Verbesserung der Messmodul-GDI-Treiber

Beitragvon iFarber » Donnerstag 28. Januar 2010, 15:40

Folgende Erweiterungen/Verbesserungen am Verhalten der GDI-Treiber für Messmodule halte ich für sinnvoll und bitte um die Meinung des Forums:

1.Ausgabe von Warnungen:
Bei Warnungen sollten wir mehrere Bereiche unterscheiden:
- Konfigurationswarnungen (z.B. gewünschte Abtastrate wird nicht unterstüzt und wurde vom GDI-Treiber geändert)
- Informationswarnungen (z.B. Gerät ist Offline oder Online oder in einem anderen speziellen Modus, siehe unten).

Die Warnungen werden vom Anwender ausgewertet (z.B. beim DKonfigurator angezeigt). Es ist wichtig, dass der Anwender nicht mit den Warnungen überfordert ist (z.B. kann er oft nicht entscheiden ob die Warnung wichtig ist usw.). Der Einsatz von Warnungen muss mit Anwender des Gerätetreibers besprochen werden, bzw. im LAPI-AK diskutiert und möglicherweise in Spec. 2.0 ergänzt.

Fragen zur Diskussion:
Welche Warnungen sind für den Anwender wichtig?

2.Definition von Betriebsarten:
Zur Zeit wird die Betriebsart (Online, Offline, etc.) vom Messmodul-Gerätetreiber automatisch gewählt.
Fragen zur Diskussion:
- Sollte die Möglichkeit bestehen, die Betriebsart des Treibers im Betrieb umzuschalten (extra FO Betriebsart) oder sollte die Betriebsart grundsätzlich beim Hinzunehmen eines Gerätes festgelegt sein (Modus im CreateParameter des VD)?
- Welche Betriebsarten wollen wir überhaupt unterscheiden? (Offline/Online/Simulation/Debug/etc.)
- Soll die tatsächliche Einstellung der Betriebsart dem Anwender mitgeteilt werden?
- Gibt es besondere Ansprüche der Anwender für die Steuerung des Debug-Modus bei Gerätetreibern?.

3. ErrorCfg-Blob:
Der GDI-Treiber für den Datenlogger liefert außer des Konfig-Blobs noch zusätzlichen ErrorCfg-Blob. Dahin schreibt der GDI-Treiber den Ablauf der Konfiguration. Man kann das mit der Ausgabe eines Compilers beim Übersetzen eines Programmes vergleichen. Der ErrorCfg-Blob wird von der LAPI-DLL gelesen und in eine Datei gespeichert.
Sollten die Messmodultreiber auch einen entsprechenden Blob generieren?

4. Kommunikationsobjekte statt CreateParameter
Wir haben einige Parameter (z.B. Kanalanummer) als CreateParameter festgelegt, weil wir der Meinung waren, dass sie zur Lebenszeit der Instanz nicht geändert werden.
Allerdings haben wir später spezielle Vorgaben, wie "automatisch" zugelassen, die dem GDI-Treiber sagen, dass er die Parameter selbst bestimmen soll.
Nun fehlt dafür die Rückmeldemöglichkeit.
Sollten wir grundsätzlich die CreateParameter nochmal neu definieren, mit dem heutigen Wissen um die Ansprüche aus einer automatischen Konfiguration?

Mit freundlichen Grüßen,
Igor Farber (MFP)
iFarber
 
Beiträge: 4
Registriert: Donnerstag 28. Januar 2010, 14:56

Re: Verbesserung der Messmodul-GDI-Treiber

Beitragvon MMerwald » Donnerstag 4. Februar 2010, 09:19

Hallo Herr Farber,

zu Ihren Punkten:

1.Ausgabe von Warnungen
Die Einteilung in Gruppen halte ich für sinnvoll, ich würde aber vorschlagen, die genannten Beispiele (Wert wird nicht unterstützt, Wert wurde geändert, etc.) selbst als mögliche Typen zu definieren. Eine Frage in diesem Zusammenhang wäre, ob der GDI-Treiber bestimmen soll, ob ein solcher Fehlertyp eine Warnung oder ein Fehler ist. Generell ist aber dann eine feingranulare Steuerung der Sichtbarkeit in der Konfigurationssoftware möglich.
Grundsätzlich sollte jeder Zustand der von dem vom Anwender gewünschten abweicht in einen spezifischen Warnungstyp "verpackt" werden können. Über die Anzeige auf der Oberfläche entscheidet dann die Konfigurationssoftware.

2.Definition von Betriebsarten
In unserem Anwendungsgebiet wird nur die Offline-Konfiguration benötigt. Nichtsdestotrotz halte ich eine flexible Steuerung der Betriebsart der Gerätetreiber in Hinsicht einer breiten Verwendung für sehr wichtig und ist für eine Konfigurationssoftware eine sinnvolle Ergänzung.

3. ErrorCfg-Blob
Ich denke gerade bei den Messmodulen würde ein "Konfigurationstrace" bei der Fehlersuche sehr viel helfen, da die BLOBs ja erst durch Rücklesen über die Herstellersoftware "einsehbar" sind. In diesem Zusammenhang würde ich auch noch folgende Themen vorschlagen:
  • Umbenennung von "ErrorCfg-Blob" in "ConfigurationTrace" o.ä. vorschlagen, dann hört sich das nicht so nach "Fehler" an ...
  • In diesem Trace sollten auch alle angefallenen Warnungen/Fehler (siehe Punkt 1) eingetragen werden.
  • Definition der Inhalte der Formatierung dieser Traces (auch rückwirkend für die Datenloggerdatei ErrorConf_XYZ.txt)

4. Kommunikationsobjekte statt CreateParameter
Hier tue ich mich etwas schwer, da ich ehrlich gesagt nicht ganz verstehe was Sie damit meinen?
MMerwald
 
Beiträge: 37
Registriert: Dienstag 21. Juli 2009, 11:19


Zurück zu Version 2.0

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron