Dein VI ist ein schönes Beispiel dafür, wieso ich persönlich nach Jahren LabVIEW immer noch nicht richtig warm werde mit Notifiern.
Problem ist, dass du eigentlich eine 1-zu-1 Kommunikation brauchst, der Notifier aber eine 1-zu-N Kommunikation liefert.
Fangen wir bei der Obtain/Destroy Variante an:
Durch das dauernde Erstellen eines neuen Notifiers, den du jeweils nach einmaliger Verwendung wieder zerstörst, stellst du "manuell" die 1-zu-1 Kommunikation sicher. Die jeweils zweite Schleife rechts meldet immer genau an den Aufrufer zurück, und danach ist der Notifier weg. Es kann also nichts schief gehen.
Das Ganze würde natürlich genauso sicher funktionieren, wenn du die Notifier jeweils vor der Schleife nur 1x erzeugst:
Jetzt zur FGV-Variante:
Erster (kleiner) Fehler: In der untersten For-Schleife ist die Notifier-Refnum nicht weitergegeben.
Das ist aber nicht das Haupt-Problem, wieso diese Variante nicht wie gedacht funktioniert. Das eigentliche Problem ist hier die 1-zu-N Funktionalität des Notifiers. Ich skizziere das mal an Hand von 2 Prozessen. Es könnte Folgendes passieren:
Prozess 1 holt sich die Refnum von Notifier 1 aus dem FGV. Diese gibt sie per Queue an den Parallel-Prozess 1 weiter und wartet jetzt auf eine Meldung. Der Parallel-Prozess 1 sendet diese Meldung dann irgendwann, und es geht in Schleife 1 weiter, die Refnum wird wieder freigegeben.
Prozess 2 wird erst jetzt gestartet (ist ja alles parallel programmiert), holt sich jetzt ebenfalls die Refnum von Notifier 1 (der ist ja wieder frei verfügbar), gibt sie an den Parallel-Prozess 2 weiter, und startet ein "Wait on Notification". Und hier kann es schon schief gehen. Ein "Wait on Notification" wartet nicht ab Aufruf auf eine neue Meldung, sondern wartet pro Instanz auf eine Meldung. Diese Instanz hat die Meldung aus Prozess 1 aber noch nicht ausgelesen, das ist für diese Instanz also eine neue Meldung. Sie wird somit ausgewertet und schon hast du einen Fehler.
Jetzt könntest du probieren, das Ganze mit einem "True" am Eingang "Ignore Previous" am Eingang von "Wait on Notification" zu umgehen. Somit würde Prozess 2 zumindest nicht die Notification von Prozess 1 auswerten. Das funktioniert aber auch nicht sauber, denn auf Grund des Multi-Threading von LabVIEW könnte jetzt Folgendes passieren:
- Prozess 2 holt sich Notifer 1 und gibt ihn per Queue weiter.
- Der Parallel-Prozess 2 liest Notifer 1 aus und sendet sofort die Meldung.
- Erst jetzt startet Prozess 1 das "Wait on Notification", wegen "Ignore previous" erhält er aber gar keine Meldung.
Folge: Stillstand.
Mögliche Lösung für die FGV-Variante: Umstieg auf 1-Element Queues anstatt des Notifiers. Denn dann hast du wieder eine saubere 1-zu-1 Kommunikation.
--
Und dann noch zu deinem "ich habe gehört": Keine Ahnung, woher du das hast, ich kenne nur den Hinweis aus der Hilfe, der sich aber auf den Speicheranstieg bei "Obtain Notifier" bezieht:
Zitat:If you use the Obtain Notifier function to return a reference to a named notifier inside a loop, LabVIEW creates a new reference to the named notifier each time the loop iterates. If you use Obtain Notifier in a tight loop, LabVIEW slowly increases how much memory it uses because each new reference uses an additional four bytes. These bytes are released automatically when the VI stops running. However, in a long-running application it may appear as if LabVIEW is leaking memory since the memory usage keeps increasing. To prevent this unintended memory allocation, use the Release Notifier function in the loop to release the notifier reference for each iteration.
Also eigentlich ganz was anderes.
Die FGV-Variante wird übrigens durch die "Shared Resource" FGV immer langsamer sein...
Gruß, Jens
--
Edit: "Moin zusammen" um 11 Uhr nachts...
(06.09.2014 09:45 )GerdW schrieb: P.S.: Das AutoCleanup-Tool hätte zumindest bei der FGV auch nicht geschadet…
, die 2012-Variante vom FGV sieht IMHO schön aus, die 2011er habe ich mir nicht angeschaut. Kein Bedarf AutoCleanUp.
