..nein nein nein nein, des is alles irgendwie net des Wahre.
Die Frage von zuvor bleibt noch offen. Und hier ist die naechste :)
Ich habs versucht in eine schoene Geschichte mit bereits vorgefertigten Vermutungen zu packen. Wenn jemand seinen Senf dazu geben koennte, ob er es genauso machen wuerde oder anders bzw. ob die Vermutungen richtig oder falsch sind waere ich sehr dankbar :)
Szenario (schaut laenglich aus, ist aber zumindest nicht kompliziert):
Im Mainloop vom Programm wird ein Drehknopf (der einen Winkel mit einem Motor einstellen soll) ausgelesen, den der Anwender drehen kann. Drueckt er auf 'Uebernehmen', soll der Motor die Schritte fahren, die noetig sind, um den eingestellten Winkel zu erhalten.
Loesung:
Wenn der Drehknopf auf 40 steht und auf 80 gedreht wurde, muessen also 40 Schritte gefahren werden. Das ist eine Subtraktion die das Mainloop ausfuehrt. Dann schicke ich einen Notifier mit Anzahl der Schritte an ein paralleles Loop, dass immer laueft, aber mit 'WAIT for Notifier' hingehalten wird. Wenn dieser ankommt wird fuer jeden Schritt ein Puls erzeugt (also ein For-Loop mit N=Schrittzahl im parallelen Loop gestartet).
Das kann ich dann ja beliebig oft machen: jedes Mal wenn der Anwender einen anderen Winkel einstellt, wird der Notifier vom Main Loop ja neu gesendet und mein paralleles wartendes Loop startet jedesmal das Motordreh-For-Loop.
Problem A:
Das Hauptprogramm ist irgendwann wenn der Anwender keinen Bock mehr hat den Motor zu drehen zu Ende :). Der Anwender drueckt also z.B. STOP. Das externe Loop laueft aber nach wie vor. Das soll nicht so sein.
Loesungsvorschlag zu A:
Beim Beenden des Mainloops den Notifier erneut schicken mit z.B. (-1) als Schrittzahl. In das parallele Loop muss dazu dann eine Abfrage eingebaut werden, die prueft ob der Motor gedreht werden soll, oder im Fall (-1) dass Loop gestoppt (und der Notifier aufgeloest) werden soll. Das waere darueber hinaus eine weitere Antwort auf die Frage von zuvor, wie man eine Queue sauber beenden koennte. Vielleicht ist das ja sogar die richtige?
Problem B:
Der Motor ist langsam, der Anwender entscheidet sich fuer einen anderen Winkel, noch waehrend das Motordreh-For-Loop laueft. Der Notifier wird also wieder geschickt, aber kommt nicht an, da momentan keiner auf ihn "wartet".
Loesungsvorschlag zu B:
Der Labviewprogrammierer ist zu unwissend. Der Notifier kommt an, sobald das For-Loop zu Ende ist. Denn der zuletzt gesendete Notifier bleibt "in der Leitung". Er wird lediglich jedes Mal von neu gesendeten Notifications Ueberschrieben. Das hab ich gerade ausprobiert :)
Zwischenfrage 1: Wie lange bleibt er in der Leitung? Solange bis irgendwo 'Wait for Notifier' getriggert wird? Oder so lange bis ein neuer Notifier gesendet wird?
Antwortvorschlag zu Zwischenfrage 1:
Nachdem man mehrere Loops mit ein- und demselben Notifier triggern kann, wahrscheinlich so lange bis ein neuer gesendet wird. Also ist ab dem Moment an dem ein Notifier gesendet wurde immer einer in der Leitung, es sei denn es wurde 'cancel notifier' aufgerufen.
Warum wird dann 'Wait for Notifier' nicht dauernd neu getriggert? Wahrscheinlich weil sich Wait for Notifier merkt, auf welche interne Notifier-Nummer letztes mal ausgeloest worden ist, und auf diese wird nicht nochmal ausgehloest. Nur eine Vermutung.
Problem C:
Der Anwender ist uebereifrig und drueckt ein paar Mal waherend dem laufenden Drehvorgang. Es werden also Notifier gesendet, von denen diesmal wirklich welche verloren gehen. Nachdem das Mainloop nicht weiss wieviele Schritte sich der Motor in der Zeit schon gedreht hat geht es zur Schrittberechnung immer vom zuletzt gesetzten Wert aus. Der letzte Notifier der in der Leitung steht und gelesen wird enthaelt also eine voellig falsche Schrittzahl.
Loesungsvorschlag zu C:
Eine Queue anstatt dem Notifier verwenden.

