LabVIEWForum.de

Hallo zusammen,
ich arbeite schon einige Zeit an einem etwas größeren Projekt. Die Fehlerbehandlung habe ich bisher etwas stiefmütterlich behandelt und möchte sie jetzt effizient integrieren.

Immerhin habe ich alle Funktionen mit Fehlercases ausgerüstet, um (so dachte ich jedenfalls) später die Fehlerbehandlung ohne größeren Aufwand einführen zu können. Das Projekt ist komplett objektorientiert (LVOOP) programmiert.

Leider bin ich mit der in LV vorgesehenen Fehlerbehandlung nicht so ganz glücklich. Tritt nämlich ein Fehler auf, so wird dieser ja jetzt durch alle meine VIs durchgereicht, bis er irgendwo bearbeitet wird.

Ich würde mir aber lieber wünschen, dass nur bestimmte Fehler zu einer Ignoranz des Codes führen (z.B. bei Visa Fehler kann immer noch mit der Datenbank kommuniziert werden). Klar kann man die Fehler nach den Code-Bereichen bewerten, aber diese Bewertung müsste ich ja jetzt in jedem VI nachpflegen.

Durch die Verwendung von OOP gibt es bei mir auch nicht so eine ausgeprägte Verwendung von State-Machines. Es gibt eine für das Hauptprogramm und eine für eine untergeordnete Testroutine. Wenn ich jetzt hier mit einer Fehler Queue arbeite und die Fehler nach jedem Case behandel, werden aber immer zu viele VIs ignoriert. Diese Methode macht doch eh nur Sinn, wenn man für jedes SubVI einen eigenen Case anlegt, oder? Das geht aber mit dem OOP nicht zusammen.

Vielleicht hat ja jemand noch eine gute Idee, sonst muss ich wohl die Fehlerklassifizierung nachpflegen.

Also ich habe ein VI "Fehlerbehandlung.vi". Das hat als eingang einen Fehle rund als Ausgang einen Fehler. Innerhalb des VIs habe ich eine Casestruktur die den ErrorCode auswertet. Bekannte Fehler haben einen eigenen Case und da entscheide ich, was ich mit den Fehlern mache. Üblicherweise wir ddie Ursache behoben, der Fehler in die Logdatei geschrieben und dann der Fehler gelöscht. Kenne ich den Fehler nicht, sprich er hat keinen Case, wird der defaultcase ausgeführt. da wird der fehler bei mir einfach weitergereicht.

Dieses VI habe ich dann auf jeden fall am ende von jedem subvi eingebunden, aber auch so schon mal an allen stellen wo ich fehler erwarte die ich behandeln kann.

LG
Torsten

Ehrlich gesagt habe ich nicht ganz verstanden was der Unterschied zwischen "normaler" LV-Programmierung und LVOOP-Programmierung im Bezug auf Fehlerbehandlung ist.
Das mit dem Weiterreichen des Fehlers durch alle VIs ist doch ne tolle Sache. Wie sieht überhaupt deine Programmstruktur aus? Kannst du es kurz beschreiben?
So wie ich verstehe hast du mehrere Objekte (VISA, DB u.s.w.) in deinem Programm seriell geschaltet. Der Ablauf ist bei dir durch den Fehlercluster gewährleistet. Du kannst aber den Fehler von Objekt einer Klasse zum nächsten Objekt der gleichen Klasse anschliessen. Somit hast du so viele Fehlerleitungen wie Objekte. Den Datenfluss kannst du über die Daten machen, die du von einer Klasse zur anderen weiterreichst.

Passt die Antwort zu deiner Frage Oder habe ich es falsch verstanden?

Nur zum Andeuten, was ich meine, habe ich einen Screenshot gemacht. Das Programmm funktioniert noch nicht und ist noch gar nicht fertig, also bitte nicht darüber diskutieren.

Grober Programmaufbau:
Ich habe in dem Programm viel mit Kompositionen gearbeitet.
D.h.:
Am Anfang wird ein Objekt TestStand initiiert. In den Privatdaten dieses Objektes werden dann Prüfmodule der Klasse Module abgelegt, die je nach dem welche Module per Hardwarekennung im Prüfstand erkannt worden sind, mit gegebenen Konfigurationen (Tasks usw..) initiiert werden.

So hat man dann quasi eine ziemliche Verschachtelung an Objekten und kann eben leider nicht für jede Klasse eine eigene Fehlerleitung nutzen (obwohl ich diesen Ansatz sehr interessant finde), da ja in vielen SubVis verschiedene Objekte aufgerufen werden.

Man könnte natürlich die Fehler per Array oder Cluster zusammenfassen. Das würde aber auch wieder umfangreichere Umbauarbeiten zur Folge haben.

Objektorientiert heißt einfach, dass z.B. ein Prüfablauf nicht (nur) über eine State Maschine gesteuert wird, sondern z.b. einfach für jede zu testende Komponente eines Prüflings ein Objekt in einem Array abgelegt ist. Diese Objekte sind dann Subklassen von einer Klasse Komponente oder von spezielleren Klassen. Somit lassen sich viele Gemeinsamkeiten nutzen (z.B wenn nur ein Befehl für die serielle Ansteuerung unterschiedlich ist).

Soll einfach heißen, es gibt halt nicht so viele Cases wie bei rein funktionalen Programmen und deshalb werden evtl. Fehler nicht so oft bearbeitet, wenn man das nach jedem Case machen würde.

Falls jemand mal einen ähnlichen Fall hat, meine derzeitige Lösung:
Ich mehrere Fehlerklassen eingeführt, die alle Subklassen der Klasse Error sind. Diese hat als Attribute den Fehlercluster sowie Min- und Maxwerte des zugehörigen Fehlercodes.
In einer Klasse ErrorCompound ist je ein Objekt jeder Fehlerklasse als Attribut gespeichert. Somit hat man jetzt die Möglichkeit, je nach Fehlerart individuell zu reagieren.
Komplexere SubVIs, die wiederum SubVIs aufrufen, bekommen ErrorCompound als Eingang. Einfachere haben nur einen einfachen Fehlereingang, der mit der jeweiligen Fehlerklasse verbunden wird. Auftretende Fehler werden anhand des Codes klassifiziert und in der jeweiligen Klasse gespeichert. Die Abarbeitung kann dann durch die Vererbungsstruktur und überschreibende VIs individuell erfolgen.

Hört sich kompliziert an, ist aber durch Schleifen und Vererbung ziemlich einfach zu realisieren und bietet mir wesentlich mehr Flexibilität, als die Standard-Fehlerbearbeitung.

Danke nochmal für die guten Anregungen.