RE: Asynchrone VIs mit Event Struktur sofort beenden
Vielen Dank Gerd!
Ich bin jetzt durch die Problemstellung besser durchgestiegen wie dynamische Events funktionieren und frage mich warum ich die bisher nicht genutzt habe...
Was für mich dann lediglich noch offen ist aber glaube ich trivial "wie zu erwarten" funktionieren dürfte:
By asynchroner mehrfacher Ausführung des gleichen VIs sollten ja verschiedene Instanzen des VIs im Speicher sein, die dann jeweils auf den eigenen Daten arbeiten. Angelegt werden die Events in je einer eigenen Instanz meiner Klasse - pro Instanz der Klasse ein Aufruf der dann den asynchronen Call startet und dabei die registrierten Events und erforderliche Daten übergibt.
1. Alle diese asynchronen VIs sollten dadurch ein "eigenes" Beenden User event kriegen (da jede Instanz ein "neues" Event dafür registriert, ergo jede kriegt eine "persönliche" Referenz für ein Event), richtig?
1a. dadurch sollte sich dann jede Instanz des VIs auch selbstständig beenden können (beenden event triggern --> asynchrones VI räumt sich und seine Daten auf, Klasse macht was sie zum auflösen machen muss) ohne die anderen zu beeinflussen? Daher, ich kann auch wenn ich die Konfiguration meines Counters ändern wollen würde (nach Start) das beenden Event triggern und das asynchrone VI neu starten ohne einfluss auf alles andere (ich frage lediglich weil sich Labview manchmal nicht verhält wie man es erwartet...)
2. Das VI muss dann vermutlich auf "Preallocated clone reentrant execution" eingestellt werden, so dass jede Instanz auch die eigenen Daten dauerhaft halten kann, richtig?
Oder reicht auch die "shared clone reentrant execution" ? Ich frage deshalb, weil ich bei ersterer die Klasse nichtmehr dynamisch dispatchen darf, bei letzterer schon. Das wäre wichtig das zu können, falls weitere Klassen dazukommen die ein ähnliches Monitoring implementieren müssen.
Falls relevant: Aktuell ist es so, dass nur zum Start des Programs hier eine Initialisierung vorgenommen wird. Und dabei alle diese VIs einmalig gestartet werden und bis zum Programmende durchlaufen (als Event Monitoren). Wenn ich großzügig bin (und die Zeit finde) würde ich dem Nutzer auch noch erlauben zur Laufzeit Einstellungen des Counters zu ändern. Bisher ist das nur im INI file möglich, so dass eine Änderung einen Programneustart erfordert (und ich auch nur zum start das Ini File einlesen und am Ende wieder ausschreiben muss - relevant wenn Default Werte gesetzt wurden damit der User Rückinfo hat was für Flags er zur Verfügung hat für Einstellungen). Selbst die Änderung würde lediglich zu vereinzelten Neustarts des Event Monitors einer Klasse führen wenn Einstellungen geändert werden und auf die Klasse ausgespielt werden müssen.
Gruß Kiesch
P.S: Da FGVs hier im Forum sehr beliebt sind noch ein Kommentar: ich hatte schon überlegt ob ich für Änderungen eine FGV nutzen sollte über die ich das an die asynchronen VIs ausspielen kann, allerdings erscheint es nicht sinnvoll den Event Monitor mögliche Probleme die dadurch auftreten könnten lösen zu lassen, wenn ich das auch über eine Klassenmethode machen kann die mehr oder weniger die alte Instanz aufräumt und eine neue mit geänderten Werten erzeugt.
Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
|