+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Fehlerbehandlung in SubVIs (/Thread-Fehlerbehandlung-in-SubVIs)
Fehlerbehandlung in SubVIs - BerndD - 13.05.2011 14:08
Hallo,
mein erstes Projekt in LV ist es, für ein USB-Gerät eine LV-Anbindung zu schreiben. Ich habe die erste SubVI erfolgreich erstellt. Sie ruft über CLF’s eine in Delphi geschriebene DLL auf. Es funktioniert soweit gut.
Nun möchte ich mich um die Fehlerbehandlung kümmern. Also Fehlereingang zur Verfügung stellen, Fehler zur 1. CLF schleifen. Solange Fehler anliegt, nichts machen. Wenn Ok, DLL-Funktion aufrufen, Rückgabewert auswerten und in Fehlercluster einspeisen und zur nächsten CLF schleifen. Dort dasselbe wie bei der 1. CLF und dann den Fehlercluster als Ausgang zur Verfügung stellen. Am Ausgang sollen die durchgeschliffenen Fehler plus den eigenen Fehlern anliegen.
Da dies ein Standard-Problem ist, das von einem Profi quasi ständig gelöst wird, hoffe ich ihr könnt mir eine SubVI zeigen, wo dies vorbildlich gelöst wurde. Oder ein Artikel wo das Thema Fehlerbehandlung ausfühlich beschrieben wird.
Selbst habe ich leider nichts gefunden, was vermutlich daran liegt, dass bei Beispielen die Fehlerbehandlung weggelassen wird, um es einfach halten zu können. Das Durcharbeiten der Hilfe zum Thema Fehlerbehandlung scheitert daran, das ständig auf eine „NI Scan Engine” verwiesen wird. Was da dann steht ist mir einfach zu hoch. Ich denke so tief muss ich auch vorerst nicht einsteigen.
RE: Fehlerbehandlung in SubVIs - M Nussbaumer - 17.05.2011 10:27
Den Error-Ausgang kannst du an eine Case-Struktur anschliessen, dadurch bekommst du einen Case für den Fehler und einen für den Normalfall. Wie du die Fehler aus deiner DLL behandeln willst, oder gar ignorieren willst liegt bei dir.
Hoffe das hilft dir weiter!
Gruss Marc
RE: Fehlerbehandlung in SubVIs - BerndD - 17.05.2011 10:47
Hallo,
danke Marc, ich bin zwischenzeitlich weiter gekommen und habe den Fehlerstatus an eine Case-Struktur angeschlossen. Wobei ich einfach mit dem Verbindungswerkzeug ein Abzweig zum Case-Eingang gemacht habe. LV scheint dann automatisch die Signal-Leitung aus dem Cluster zu nehmen.
Leider funktioniert es nicht. Wenn ein Fehler von meiner DLL zurückgeliefert wird, gibt es folgende Probleme:
1. Wenn ich das blinken des Debuggers richtig interpretiere, werden die Ausgabeparameter weiter propagiert, bevor der Rückgabewert (der die Fehlernummer enthält) ausgewertet wird.
2. Das Status-Signal im Fehlercluster wird nicht gesetzt. Oder setzt die Dialogausgabe des Fehlers den Fehlerstatus zurück? Wenn ja, wie kann man das verhindern?
3. Da der Fehlerstatus nicht gesetzt wird, wird der 2. DLL-Aufruf ausgeführt. Danach tritt ein weiteres Problem auf: LabView behauptet in ein Fehlerdialog, dass der zurückgegebene Fehler nicht definiert sei. Das kann eigentlich nicht sein, weil ich die Fehlerbehandlung bei dem beiden Aufrufen gleich aufgebaut habe. Allerdings fällt mir auf, dass beim 2. „General Error Handler.vi“ am Fehlercode-Eingang ein rotes Dreieck ist. Was hat das zu bedeuten?
Ich habe ein Bild der vi und das Projekt angehängt. Für die enthaltene DLL habe ich ein Virencheck bei Virustotal.com durchgeführt und das Protokoll als PDF beigelegt. Hier die MD5 Prüfsumme:
8133252f5978f6f4658baa4e92d6c7b0 *pei2c.dll
Vielen Dank im Vorraus.
Bernd
[attachment=33801][attachment=33802]
RE: Fehlerbehandlung in SubVIs - M Nussbaumer - 17.05.2011 11:41
(17.05.2011 10:47 )BerndD schrieb: Hallo,
danke Marc, ich bin zwischenzeitlich weiter gekommen und habe den Fehlerstatus an eine Case-Struktur angeschlossen. Wobei ich einfach mit dem Verbindungswerkzeug ein Abzweig zum Case-Eingang gemacht habe. LV scheint dann automatisch die Signal-Leitung aus dem Cluster zu nehmen.
Leider funktioniert es nicht. Wenn ein Fehler von meiner DLL zurückgeliefert wird, gibt es folgende Probleme:
1. Wenn ich das blinken des Debuggers richtig interpretiere, werden die Ausgabeparameter weiter propagiert, bevor der Rückgabewert (der die Fehlernummer enthält) ausgewertet wird.
Du kannst die Wertezuweisung nochmal in eine Case-Struktur setzten und dort nur im "Nicht-Fehlerfall" die neuen Werte setzen
2. Das Status-Signal im Fehlercluster wird nicht gesetzt. Oder setzt die Dialogausgabe des Fehlers den Fehlerstatus zurück? Wenn ja, wie kann man das verhindern?
Prinzipiell wird der Fehlerstatus nicht ohne entsprechende Programmierereinwirkung zurückgesetzt, jedoch könnte es sein das es sich bei der Fehlermeldung um eine Warnung handelt... Wann tritt der Fehler dann eigentlich auf? Wenn ich das Programm starte und keine Karte habe?
Du kannst auch den Fehlercluster nicht von Errorausgang sondern direkt von der DLL weiterführen, falls du den Verdacht hast, dass dein Dialog dir den Status zurücksetzt (was er eigentlich nicht machen sollte)
3. Da der Fehlerstatus nicht gesetzt wird, wird der 2. DLL-Aufruf ausgeführt. Danach tritt ein weiteres Problem auf: LabView behauptet in ein Fehlerdialog, dass der zurückgegebene Fehler nicht definiert sei. Das kann eigentlich nicht sein, weil ich die Fehlerbehandlung bei dem beiden Aufrufen gleich aufgebaut habe. Allerdings fällt mir auf, dass beim 2. „General Error Handler.vi“ am Fehlercode-Eingang ein rotes Dreieck ist. Was hat das zu bedeuten?
Dieses rote Dreieck zeigt an, dass eine Datentypenumwandlung stattfindet, in deinem Programm von U32 auf I32
Ich habe ein Bild der vi und das Projekt angehängt. Für die enthaltene DLL habe ich ein Virencheck bei Virustotal.com durchgeführt und das Protokoll als PDF beigelegt. Hier die MD5 Prüfsumme:
8133252f5978f6f4658baa4e92d6c7b0 *pei2c.dll
Vielen Dank im Vorraus.
Bernd
Hoffe das ganze hilft dir weiter!
Falls was unklar ist darfst du natürlich gerne nachfragen
Gruss Marc
RE: Fehlerbehandlung in SubVIs - Lucki - 18.05.2011 08:43
Schöne Beispiele zur professionellen Feherbehandlung findet man im Buch LabVIEW Graphical Programming Leider habe ichs verborgt, Rückgabetermin unbekannt.
Z.B. entsinne ich mich dunkel, dass Fehler bei parallelen Strukturen über Queues verwaltet wurden.