Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
wie beendet man denn die Schleifen beim Erzeuger-Verbraucher-System ordentlich?
NI fragt beim Auslesen den Fehler-Cluster ab und im Fehlerfall wird beendet. Das geht, aber das ist nicht sauber: Die Referenz wird zerstört und beim anschließenden Zugriff der Fehler ausgewertet.
Geht man normalerweise her und nutzt z.B. einen Melder, der signalisiert, dass nun das Programmende folgt und reagiert darauf oder evtl. mit Kommunikation über benutzerdefinierte Ereignisse?
Um dieses Problem zu lösen würde ich eine Meldung (per Queue) vom Erzeuger zum Verbraucher senden.
Das heisst konkret, der Erzeuger-Loop stopt wenn der Benutzer auf Stop drückt und wenn der Verbraucher den Stop-Befehl vom Erzeuger per Queue erhält, dann stopt auch dieser.
' schrieb:NI fragt beim Auslesen den Fehler-Cluster ab und im Fehlerfall wird beendet. Das geht, aber das ist nicht sauber: Die Referenz wird zerstört und beim anschließenden Zugriff der Fehler ausgewertet.
Ich halte das nicht für ein unsauberes Verfahren. Ich würde nicht "zerstört" sagen, sondern "normal beendet". Auch in Normal-OOP würde man so was machen: "if not(assigned(referenz)) then ...".
Zitat:Geht man normalerweise her und nutzt z.B. einen Melder, der signalisiert, dass nun das Programmende folgt und reagiert darauf oder evtl. mit Kommunikation über benutzerdefinierte Ereignisse?
Nichtsdestoweniger verwende ich ein anderes Verfahren: Über die Steuer-Queue einen Befehl "ExitClass" hinschicken ...
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
21.10.2010, 13:58 (Dieser Beitrag wurde zuletzt bearbeitet: 21.10.2010 14:02 von Lucki.)
' schrieb:NI fragt beim Auslesen den Fehler-Cluster ab und im Fehlerfall wird beendet. Das geht, aber das ist nicht sauber: Die Referenz wird zerstört und beim anschließenden Zugriff der Fehler ausgewertet.
Ich finde auch, man kann das an sich so machen. Das Unsaubere daran würde ich eher an einem anderen Punkt festmachen: In dem Sub-Vi, welches so beendet wird, findet ja überhaupt keine ordentliche Fehlerbehandlung statt. Es wird einfach vorausgesetzt, daß es in diesem SubVi keine Fehler gibt, außer dem Schließen der Queue durch das Haupt-Vi.
Ein ordentliche Fehlerbehandlung würde ich mir so vorstellen: Abfragen des Fehlers. Wenn es Schließen der Queue ist, Sub-VI beenden, andernfalls den Fehler über einen Melder an das Hautpt-VI senden, welches dann entscheiden soll, was zu geschehen hat.
21.10.2010, 21:11 (Dieser Beitrag wurde zuletzt bearbeitet: 21.10.2010 21:12 von macmarvin.)
Ich würde auf jeden Fall ein spezielles Kommando zum Beenden vorsehen.
Wie soll man sonst einen Programmierfehler (aus Versehen irgendwo die Queue geschlossen bzw. verloren) von einem gewünschten Beenden unterscheiden?
Danke für die Antworten.
Da muss ich mal überlegen, was für mich das beste ist.
' schrieb:Ich würde auf jeden Fall ein spezielles Kommando zum Beenden vorsehen.
Wie soll man sonst einen Programmierfehler (aus Versehen irgendwo die Queue geschlossen bzw. verloren) von einem gewünschten Beenden unterscheiden?
Das funktioniert nach der NI-Methode schon, da dort der Fehler-Cluster am Eingang des Lesen-VIs nicht verbunden ist. Somit wird nur beendet, wenn im Lesen-VI ein Fehler aufgetreten ist. Da fragt man sich natürlich, wie sinnvoll das ist, da das VI trotz vorangegangenem Fehler ausgeführt wird.
' schrieb:Das funktioniert nach der NI-Methode schon, da dort der Fehler-Cluster am Eingang des Lesen-VIs nicht verbunden ist. Somit wird nur beendet, wenn im Lesen-VI ein Fehler aufgetreten ist. Da fragt man sich natürlich, wie sinnvoll das ist, da das VI trotz vorangegangenem Fehler ausgeführt wird.
Nö... unterscheiden kannst du es eben nicht, ob du willentlich oder aus versehen die Schleife beendet hast, weil die Referenz futsch ist (weil Programmierfehler oder LV-Bug (z.B. CAR 136680). Der Fehlereingang ist unerheblich.
Insgesamt würde ich das implizite Beenden als schlechten Stil einstufen.
25.10.2010, 12:22 (Dieser Beitrag wurde zuletzt bearbeitet: 25.10.2010 12:23 von Matze.)
' schrieb:Man könnte den Fehler-Cluster theoretisch auch mit dem VI "Keine Zahl/Kein Pfad/Keine Referenz?" prüfen und beim Wert "true" die Schleife beenden.
Hm?
Wie man den Status im Fehler-Cluster ermittelt ist Wurst. Es geht darum, dass eine Queue-Ref auch mal verschwinden kann, nicht weil sie ordnungsgemäß geschlossen wurde, sondern weil an anderer Stelle etwas schief ging. Bei der impliziten Methode stoppt der Verbraucher einfach. Bei der expliziten Methode erkennt der Verbraucher, dass etwas nicht stimmt (fehlender Stopp-Befehl!) und kann mit einem reconnect-Versuch reagieren - Fehlerbehandlung.
Gruß dimitri
„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
' schrieb:und kann mit einem reconnect-Versuch reagieren
Ist ein Reconnect in diesem Falle nicht ein sinnloses Feature? Nach dem Reconnect wäre wohl auf jeden Fall der Stopp-Befehl verloren. Sollte dann die MainApp den Stopp-Befehl wiederholen?
Im Falle, wenn die Queue-Referenz "plötzlich" weg ist, bleibt einem nur der Stopp der Gesamtapplikation. Solange man nicht weis, warum die Queuereferenz verschwunden ist, sind alle Gegenmaßnahmen (Reconnect) sinnlos. Über den Errorcluster den Consumer zu beendet, ist in der Entwicklungsphase sinnvoll. Da kann es schon mal vorkommen, dass die Referenz verloren geht. Hier wird man aber keinen Reconnect machen, sondern den Programmierfehler beheben.
Queue-Referenzen verschwinden normalerweise nicht in der Art, wie z.B. eine TCP/IP-Referenz. Die verschwindet, wenn der Anwender den Stecker zieht. Hier sollte normalerweise ein automatischer Reconnect her. Wie aber verschwindet eine Queue-Referenz?
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
