LabVIEWForum.de - Fehler visualisieren

LabVIEWForum.de

Normale Version: Fehler visualisieren
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo zusammen.

Rahmenbedingung:
In einem aktuellen Projekt werden von mehreren (min. einer, max. sechs) Hardwarecontrollern Daten verarbeitet. Für jeden Controller gibt es ein separates UI. Für den Anwender ist es absolut wichtig, dass er später eine Rückmeldung bekommt, wenn und wo welcher Fehler aufgetreten ist. Derzeit gibt es noch keine "Anzeige" für Fehler, die während der Laufzeit aufgetreten sind. Es ist angedacht, eigene Fehlercodes zu entwerfen und diese dann an entsprechenden Stellen im Programm "auszulösen" wenn es nötig ist. Vereinfacht ausgedrückt: Man weiß, wo welche Fehler auftreten könnten. Die Anzeige selbst sollte dann in einem eigenen Fenster erfolgen.

Ansatz:
Um dieser Anforderung gerecht zu werden, habe ich verschiedene Ansätze verfolgt, um mögliche Fehler zu visualisieren. Meine Schwierigkeit besteht darin, dass ich mich nicht festlegen kann, welche der folgenden Optionen (oder Optionen, die ich nicht kenne Big Grin ) die sinnvollste ist. Derzeit beschäftige ich mich rein theoretisch damit.

FGV:

Bei der Verwendung einer FGV würde ich das so machen wollen, dass diese die Daten von den Fehlerleitungen aufnimmt und in einem separaten VI in ein Array für den jeweiligen Hardwarecontroller schreibt. In dem anzeigenden VI würde ich dann somit n Arrays anzeigen lassen, die jeweils alle aufgetretenen Fehler beinhalten. Meine Bedenken hierbei: Kann ich sicher sein, dass ich immer alle Fehler in das Anzeige-VI übertrage?

Queue:

Queue Referenz für jeden Hardwarecontroller erzeugen und im Anzeige VI die Queues auslesen und anzeigen lassen, z.B. via Arrays (siehe FGV). Ich könnte mir sicher sein, dass alle Fehler in der Queue landen und nichts verloren geht.

Notifier:
Nie mit den Viechern gearbeitet. Der Hilfe nach zu urteilen, könnte man diese auch für das Melden von Fehlern heranziehen. Ich bin mir aber nicht sicher, ob das der gängigen Praxis entspricht.

Wie macht man sowas also "richtig"? Welche Methoden ist die Ideale, zwecks Statusmeldungen für den Anwender, ohne den Programmablauf zu beeinträchtigen?
Hoffentlich konnte ich mein Anliegen präzise genug schildern und freue mich auf eure Rückmeldung!

Der NoWay
Hallo NoWay,

ich verwende dieses Grundprinzip:
Ich starte eine parallel laufende Schleife, die ein ErrorLog erstellt. Diese Routine öffnet eine Queue namens "ErrorLog" und wartet dort auf Botschaften/Einträge. Jede andere Routine darf in diese benannte Queue schreiben - und sendet sinnvolle ErrorCluster, in denen ErrorSource und ErrorCode vermerkt ist…

Alternativ habe ich auch eine FGV, die ErrorCluster verschiedener Routinen anhand einer Kennung verwaltet (Key-Value-Paar mittels Variant-Attributen). Hier wird immer der aktuelle Fehlerzustand vermerkt und kann von einem Anzeige-VI abgefragt werden, um dann alle Fehlerquellen/-zustände in einer Listbox darzustellen…

Zum Notifier: Du musst sicherstellen, dass der Notifier gelesen wird, bevor er erneut überschrieben wird. Eine Queue ist sicherer, wenn du keine Werte "überlesen" willst…
Ergänzung zu Gerd: Notifier ist prädestiniert für eine One-to-Many Kommunikation, Queue für eine Many-to-One. Du braucht garantiert eine Many-To-One.

Vielleicht lohnt sich für dich ein Blick auf den Structured Error Handler (SEH).

Gruß, Jens
@GerdW, danke für den Denkanstoss.

@Jens
Das ist korrekt. Ich habe mehrere Teilnehmer die an ein VI "berichten", was alles passiert ist. Derzeit verfolge ich den Ansatz via Queue genauer und konnte bereits einen Erfolg verzeichnen, indem ich an einer beliebigen Stelle einen Fehler an das ErrorLog Vi sende. Das Problem, welches sich mir aktuell in den Weg stellt ist das folgende:

Ich bin hingegangen und habe einen Custom Error Code 5000 in einem Fehlercluster angegeben. Der Fehler wandert dann brav durch die Queue zu meinem VI und wird dort aus der Queue entfernt. Da aber der Fehler nirgends "definiert" ist, spuckt die Queue dann eine Meldung aus, in der ich darauf hingewiesen werde, dass es sich um einen unbekannten Fehler handelt. Mittlerweile bin ich auf den Trichter gekommen, dass ich unter Tools->Advanced->Edit Error Codes eigene Error Codes definieren und als Datei abspeichern kann. Wie aber kann ich meinem Programm dann zu verstehen geben, dass es genau diese Datei für die zusätzlichen Error Codes verwenden soll?

Was den Structured Error Handler angeht: Ich habe die Seite überflogen und werde mir diese in einer ruhigen Minuten etwas genauer zu Gemüte führen.
Hallo NoWay,

der AllgemeineFehlerBehandler kennt Eingänge für Benutzer-definierte ErrorCodes…

Wenn man die Hilfe dazu weiterverfolgt, findet man auch einen Hinweis auf den Fehler-Editor und dessen Verwendung! Diese ErrorCodes lassen sich auch im AppBuilder angeben…
(24.09.2014 08:23 )GerdW schrieb: [ -> ]Alternativ habe ich auch eine FGV, die ErrorCluster verschiedener Routinen anhand einer Kennung verwaltet (Key-Value-Paar mittels Variant-Attributen). Hier wird immer der aktuelle Fehlerzustand vermerkt und kann von einem Anzeige-VI abgefragt werden, um dann alle Fehlerquellen/-zustände in einer Listbox darzustellen…

Wie gibst du die Daten an die Listbox weiter? In meinem Fall würde ich gerne Fehler und Statusmeldungen als "Statusview" für den Anwender in einer Listbox darstellen. Gelöst habe ich dies bisher mit einem String Array. Macht man das so oder gibt es da eventuell eine geschicktere Lösung? Ich könnte mir vorstellen, dass dies problematisch ist, wenn das Programm über lange Zeit läuft (unwahrscheinlich aber eben möglich) und dadurch das StringArray aufgeblasen wird.

Klar, ich könnte das Array begrenzen, aber das will ich eigentlich nicht. Die einzige Lösung in meinen Augen wäre demnach das Wegschreiben der Logdaten.

Gruß
NoWay
Hallo NoWay,

da ich immer nur den "aktuellen" Fehlerstatus vermerke, bleibt die Liste übersichtlich - die Anzahl der Fehlerquellen ist begrenzt…

Zitat:Gelöst habe ich dies bisher mit einem String Array. Macht man das so
Eine Listbox erwartet nunmal ein Stringarray - also muss man auch eines erstellen…

Zitat:Klar, ich könnte das Array begrenzen, aber das will ich eigentlich nicht.
Was ist dir lieber: ein unbegrenzt wachsendes Array mit Gefahr eines "OutOfMemory"-Fehlers oder ein stabil laufendes Programm?

Zitat:Die einzige Lösung in meinen Augen wäre demnach das Wegschreiben der Logdaten.
Das Speichern von Log-Daten ist immer eine sinnvolle Entscheidung…
Referenz-URLs