Hi
Kann mir jemand einen Tipp geben wie man den Fehlercluster am besten einsetzen kann ohne den Ablauf zu stören?
Wenn ein Fehler auftritt werden im Normalfall alle folgenden vi's oder SubVI die im Fehlercluster hängen ja nicht ausgeführt, wie ist das aber wenn ein VI dennoch ausgeführt werden soll?
z.B. wie im Anhang, wenn die dll initialisiert und das Gerät Fehlerfrei geöffnet wurde, aber im Anschluss beim write oder read ein Fehler auftritt dann wird das close ja auch nicht mehr ausgeführt, wäre es dann im allgemeinen Besser den Fehler vorher zu behandeln oder den Fehlereingang des close.vi abzuklemmen und die Fehlercluster danach zusammenzuführen? Oder gibt es eine bessere Lösung für solche Fälle?
Hallo Hansi,
im allgemeinen werden alle Close-Funktionen unabhängig vom Fehlerstatus ausgeführt!
Schau dir einfach mal FileClose, DestroyQueue o.ä. an…
Hi Gerd
Bei einem Knoten zum Aufruf externer Bibliotheken gibt es nur eine Einstellung in der man die Fehlerprüfung deaktivieren kann, an einer anderen Stelle habe ich keinen Hinweis dazu gefunden. Allerding bin ich mir nicht sicher ob diese Einstellung dann nur die Fehlerprüfung in diesem Knoten deaktiviert oder ob sie auch vorher entstandene Fehler igoriert und nur durchreicht. Oder gibt es noch eine andere Stelle al der die Ausführung im Fehlerfall beeinflusst werden kann?
Du kannst es auch umgehen.
Gruß
Freddy
Mercy
Ist vermutlich auch keine so gute Idee die Fehlerprüfung in einem dll Knoten zu deaktivieren, das könnte zu Probleme führen
(05.10.2016 07:58 )hansi9990 schrieb: [ -> ]Mercy
Ist vermutlich auch keine so gute Idee die Fehlerprüfung in einem dll Knoten zu deaktivieren, das könnte zu Probleme führen
Das ist grundsätzlich nur halb richtig. Das Ausschalten keine gute Idee ist, ist eindeutig richtig, aber dass das zu (mehr) Problemen führt dann wenn es eingeschaltet ist, stimmt so nicht ganz.
Die Fehlerbehandlung die Du auf diese Weise ausschaltest ist im wesentlichen ein Auffangnetz, wenn beim Aufruf der DLL Funktion etwas schief läuft. Dass kann ein falscher Parameter sein oder ein Bug in der DLL der eine Speicherverletzung verursacht, oder eine Exception die die DLL selber macht (Division durch 0 etwa).
Ein Problem ist, dass diese Fehlerbehandlung nicht alle solchen Fehler erkennen kann, selbst eine Speicherverletzung muss nicht unbedingt eine Ausnahembehandlung triggeren die von dieser Fehlerbehandlung abgefangen wird.
Das zweite Problem ist, dass ganz egal ob LabVIEW diesen Fehler abfängt und einen Fehler zurückgibt oder nicht, es bei Dingen wie einer Speicherverletzung ohnehin zu spät ist. Nicht für nichts steht im entsprechenden Dialog dass man den Computer neu starten sollte. Denn eine Speicherverletzung kann grundsätzlich irgendetwas willkürliches überschreiben, auch Speicherstellen die sehr lebenswichtige Daten für LabVIEW und/oder das Betriebssystem enthalten. Und wenn man da einfach weiterwurstelt, weil ja scheinbar alles noch funktioniert, dann könnte Speicher beschädigt sein der später Fehler im Betriebssystem oder in Files die zurück auf die Festplatte geschrieben werden, zur Folge haben könnte.
Das heisst, diese Fehlerbehandlung ist sicher nützlich während der Entwicklung und dem Testen, aber keine Garantie dass alles gut ist wenn keine Fehler kommen, selbst wenn sie auf dem höchsten Level eingestellt ist. Für gut getestete VIs (und das geht viel viel weiter dann einfach bis es nicht mehr crasht oder keine Fehlermeldungen mehr von der Call Library Node kommen, ist die Standardeinstellung die Beste. In der Debugeinstellung macht LabVIEW allerlei extra Checks die echt seriös Speicher und Ausführungszeit beanspruchen. Ausgeschaltet habe ich diese Fehlerbehandlung aber noch nie und ich fände es eindeutig am falschen Ort optimiert, um das zu tun.