LabVIEWForum.de - Programm mit Obtain Notifier beenden

LabVIEWForum.de

Normale Version: Programm mit Obtain Notifier beenden
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo Zusammen,

zuerst kurz allgemeine Fakten:
- Labview 2016 (32 bit) ENG (Anhänge noch mal als V13 gespeichert. Hoffe das hat geklappt.)
- WinX 64 bit


Kurzbeschreibung Programm:
Ich schreibe ein Prog in dem zwei Schleifen parallel arbeiten.
1. Schleife als StateMachine für den Start des Programms + Event Structur zum Abfragen von Ereignissen
2. Schleife wird via einem Obtain Notifier von der ersten informiert, was zu tun ist. Nimmt dann kontinuierlich Messdaten auf und verarbeitet diese.

Problembeschreibung:
Über den Obtain Notifier (ein Cluster als input) gebe ich auch ein Bit zum Beenden der 2. Schleife mit falls das Programm beendet wird (Event Structur) oder ein Fehler oben auftritt. Bzw. sollte dies so geschehen.
In dem Cluster befinden sich noch 2 weitere Bits die ohne Probleme Funktionieren.
Nur beim Beenden / Abbruch des Programms wird das Bit zum beenden der Schleife nicht empfangen (in der 1.Schleife aber gesetzt)

Bereits gemacht:
- Kleines Dummy-Programm (Programm_beenden_cluster.vi) geschrieben, was aus meiner Sicht funktioniert und ich glaube auch verstanden zu haben. Angel_not

Frage an euch / Verständnisproblem:
So jetzt die Frage an euch: in meinem Dummy-Programm geht es; in meinem eigentlichen nicht. Nur finde ich da leider keinen wirklichen Unterschied Angry
Könnte von euch bitte jemand mal einen Blick drauf werfen?
Ich hab die ganzen subVIs jetzt nicht mit dazugepackt. Sollte auch so gehen.
Wäre für weitere Anmerkungen auch offen, da ich noch nicht lange mit LabView arbeite.

Vielen Dank für euere Zeit und Unterstützung

Viele Grüße christoph
Hallo Hiwi,

Zitat:Kleines Dummy-Programm (Programm_beenden_cluster.vi) geschrieben, was aus meiner Sicht funktioniert und ich glaube auch verstanden zu haben.
Wieso verwendest du "Get Notifier Status" anstatt des sinnvolleren "Wait on Notification"?
Wieso soll deine Consumer-Loop ungebremst laufen?
Wieso ist die Notifier-Referenz in der Producer-Loop nicht durchverdrahtet?
Hast du dieses Mini-VI wirklich "verstanden"? Funktioniert das VI wirklich?

Zitat:Könnte von euch bitte jemand mal einen Blick drauf werfen?
Boah, ist das BD groß!
Wo soll man denn da den Überblick behalten und irgendetwas finden?

Auch hier halte ich es für problematisch, überall mit "Get Notifier Status" zu arbeiten. Und warum muss man den Status mehrfach in einer Schleife abfragen?

Zitat:Wäre für weitere Anmerkungen auch offen, da ich noch nicht lange mit LabView arbeite.
Erste Anmerkung: das schreibt man "LabVIEW"! Big Grin
Zweite Anmerkung: Profil_ergaenzen
Ansonsten: zu viele lokale Variablen/"Value"-PropertyNodes für meinen Geschmack…
Hallo Christoph

Das BD ist wirklich sehr gross (wie von Gerd schon erwähnt) und daher schwierig zu interpretieren...

Ich denke das Problem ist, dass die Notifier-Referenz nach dem Beenden des Producers (Event-Struktur) direkt geschlossen wird.
Hat der Consumer eine Verzögerung implementiert, so versucht diese Schleife auf eine "ungültige" Notifier-Referenz zuzugreifen.

Schliess den Notifier erst, wenn beide Schleifen beendet wurden.

Gruss
Chris
Hallo Zusammen,

schon mal Danke für eure Hilfe Smile

@Chris:
Zitat:Ich denke das Problem ist, dass die Notifier-Referenz nach dem Beenden des Producers (Event-Struktur) direkt geschlossen wird.
Hat der Consumer eine Verzögerung implementiert, so versucht diese Schleife auf eine "ungültige" Notifier-Referenz zuzugreifen.

Schliess den Notifier erst, wenn beide Schleifen beendet wurden.

Das könnte schon mal einen Teil meiner Probleme behoben haben Smile Danke

@Gerd
Zitat:Kleines Dummy-Programm (Programm_beenden_cluster.vi) geschrieben, was aus meiner Sicht funktioniert und ich glaube auch verstanden zu haben.
Wieso verwendest du "Get Notifier Status" anstatt des sinnvolleren "Wait on Notification"?

Wenn ich in meinem Dummy den "Get Notifier Status" gegen den "Wait on Notification" ersetzte, dann hält er meine Consumer-Schleife an und wartet bis sich der Status ändert. Da er in der Schleife kontinuierlich Messen soll, würde das so nicht passen. Das war der Grund für mich den "Get Notifier Status" zu verwenden.
"... When the notifier receives a message, this function continues to execute. ..."

Zitat:Wieso soll deine Consumer-Loop ungebremst laufen?
Wieso ist die Notifier-Referenz in der Producer-Loop nicht durchverdrahtet?
Unachtsamkeit beim Dummyprojekt Angel_not

Zitat:Hast du dieses Mini-VI wirklich "verstanden"? Funktioniert das VI wirklich?

Das ist jetzt eine Fangfrage von dir. Wink Vor deiner Antwort hätte ich mit ja geantwortet. Danach ... bin noch unsicher.
Nach meinem Verständnis was ich testen konnte hat es soweit funktioniert. Der Einwand von Chris war gut. Da bin ich drübergestolpert, da die Schleife ungebremst gelaufen ist.

Zitat:Könnte von euch bitte jemand mal einen Blick drauf werfen?
Boah, ist das BD groß!
Wo soll man denn da den Überblick behalten und irgendetwas finden?

Ich hab leider noch kein wirklich großes Projekt gesehen. Meistens waren das Tutorials bzw. Beispiele welche auch nicht groß waren.
Ist es dann sinvoll mehr in subVIs zu packen? Auch dann wenn es quasi nur 1x Verwendung findet?

Zitat:Auch hier halte ich es für problematisch, überall mit "Get Notifier Status" zu arbeiten.

Wie oben angemerkt, weiß ich nicht recht wie ich den "Wait on Notification" einsetzen soll. Gibt es dann generell bessere Wege für meine Fragestellung als mit der Notification? Queue Operations hab ich gelesen, das die mehr dafür gedacht sind, wenn ich größere Daten zwischen Producer und Consumer austauschen möchte (wie z.B. Messdaten) und es nicht wichtig ist, das man sicher den letzten Wert erwischt.

Zitat:Und warum muss man den Status mehrfach in einer Schleife abfragen?

War für mich so einfacher ersichtlich wo das Signal herkommt Wink
Was mich wieder zu dem Problem des großen BD kommen lässst Wink
Ist jetzt auf eine Abfrage reduziert.

Zitat:Wäre für weitere Anmerkungen auch offen, da ich noch nicht lange mit LabView arbeite.
Erste Anmerkung: das schreibt man "LabVIEW"! Big Grin

Werde ich beachten.

Zitat:Zweite Anmerkung: Profil_ergaenzen

Sollte jetzt passen Smile

Zitat:Ansonsten: zu viele lokale Variablen/"Value"-PropertyNodes für meinen Geschmack…

Gibt es damit Probleme bzw. was wären da alternaiven?

Danke für eure Unterstützung Smile

Viele Grüße aus Weihenstephan

christoph
Hallo Christoph,

Zitat:Wenn ich in meinem Dummy den "Get Notifier Status" gegen den "Wait on Notification" ersetzte, dann hält er meine Consumer-Schleife an und wartet bis sich der Status ändert. Da er in der Schleife kontinuierlich Messen soll, würde das so nicht passen. Das war der Grund für mich den "Get Notifier Status" zu verwenden.
Dafür hat diese Funktion ja noch einen TimeOut-Eingang und -Ausgang…

Was bedeutet "kontinuierlich"?

Zitat:Ist es dann sinvoll mehr in subVIs zu packen?
Definitiv JA.
Hallo Zusammen,

nochmal Danke an Gerd Smile
Ich glaube meine Unklarheiten lichten sich.

Habe auch noch den Link gefunden: http://www.labviewforum.de/Thread-Proble...tification

Aus allen Informationen hab ich mein Dummy modifiziert.
Vor allem mit dem Satz:
Zitat:Dafür hat diese Funktion ja noch einen TimeOut-Eingang und -Ausgang…
und dem Link konnte ich was anfangen (so hoffe ich.)

Meine Bitte an euch:
Würdet ihr mal über mein Dummy schauen und sagen, ob es jetzt so OK wäre oder ob da noch ein böser Fehler drin ist?
Und welche Consumer-Schleife aus euer Sicht die bessere Wahl wäre und warum. Aus meiner Sicht funktionieren beide gleich, und mir fehlt leider (noch) der Hintergrund um eine Aussage zu treffen welche besser ist. (Außer ich bin hier komplett auf dem Holzweg und beide sind für den virtuellen Papierkorb Sad)

Zitat:Was bedeutet "kontinuierlich"?

Wenn ein Freigabesignal anliegt, lese alle 500 ms von einer Zählkarte die Werte aus und verarbeite diese so lange, bis das Freigabesignal nicht mehr anliegt.

Zitat:
Zitat:
Ist es dann sinvoll mehr in subVIs zu packen?

Definitiv JA.

Danke. Ist in Arbeit. Smile

Vielen Dank euch nochmal Smile

Vielel Grüße
christoph
Referenz-URLs