Asynchrone VIs mit Event Struktur sofort beenden

Hallo liebe Mitforisten,

eine ganz bescheuerte Frage auf die ich zwar keine Antwort per SuFu gefunden habe, aber eigentlich erwarten würde dass die schon irgendwo beantwortet ist:
Ich habe mir ein Projekt gebastelt, dass mir meine DAQ Hardware als LV-Objekt anlegt und anschließend in Kanäle zerlegt die ich aus einem Ini file initialisiere. Das ganze ist so ausgelegt, dass ich die Labels der Controls nutze um Control und zugehörigen Kanal zu verknüpfen und damit automatisch mein Mapping von meinen ini-Routinen erledigt werden kann. Der "Nachteil" ist, dass dadurch das FP von der Funktionalität weitgehend entkoppelt ist. Das nur als Vorbemerkung warum die Frage relevant ist.

Ich habe jetzt neu ein Counter Objekt gebaut, dass einen Start und einen Stop Button haben kann, mindestens aber einen Start Button braucht (der dann für Start und Stop da ist). Was von beidem vorhanden ist, kann mein Objekt prüfen, im FP wäre Aufwand und zusätzlicher Code notwendig, der noch dazu Funktionalitäten erneut implementieren müsste die auf Counter(objekt)ebene besser aufgehoben sind. Allein um zu prüfen was vorhanden ist und wie deswegen geschaltet werden müsste.
Wie will ich das lösen? --> Event Struktur im Counter Objekt die als VI asynchron gestartet wird und einfach nur die Betätigung von Start und Stop überwacht. Das als dynamische Events zur Laufzeit anzulegen, kriege ich wahrscheinlich noch hin. Mein Problem ist eher:

Beim "Aufräumen" am Ende muss ich alle diese Schleifen (und damit das VI) sauber wieder beenden. Die einfachste Lösung die mir einfällt wäre ein Button auf dem Frontpanel der nur dazu da ist, dass ich dem beim beenden ein Value (signaling) hinwerfen kann der das "Beenden" Event direkt triggert. So richtig sauber scheint mir die Lösung aber nicht - auch wenn ich solchen Lösungen nicht grundsätzlich ablehnend gegenüber stehen würde. Gibts noch ne andere Variante mit der ich trotz Eventstruktur ein pollen vermeiden kann? Gibts da irgendeinen Königsweg für wie man es machen "sollte"? Soweit ich das überblickt habe gibt es bei den dynamischen Events keins das man allein im Blockdiagram (ohne Nutzung des FP) triggern kann.

Gruß Kiesch

P.S: Was mir noch aufgefallen ist: Die dynamische Eventregistrierung will ja eine feste Zahl an Referenzen haben, die zur Entwicklungszeit bereits definiert sein müssen. Ist zu erwarten, dass das zu Problemen führt wenn ich da leere Referenzen reinschreibe? Das die triggern ist ja nicht zu erwarten (da leer) und es erspart mir im konkreten Fall nach der Button Anzahl unterscheiden zu müssen welchen Event Struktur ich verwenden muss. Das kann dann über eine passieren und dort wo notwendig wird das Programverhalten dementsprechend angepasst. So lange das nicht zur Laufzeit merkwürdige Fehler werfen kann, wäre ich damit zufrieden dort leere/ungültige Referenzen mit reinzuschreiben statt abzufangen das die leer sind.

P.P.S: Mir fällt grade noch auf, ich kann natürlich auch einen "Programmende" Button nach unten ins Objekt durchreichen und dynamisch registrieren. Den muss der Nutzer im Hauptprogram dann lediglich mit nach unten durchreichen (und darf den dann nichtmehr latchen lassen wenn ich mich recht erinnere). So richtig schön finde ich die Lösung aber ebenfalls nicht.

P.P.P.S: Falls relevant kann ich auch gerne ein Minimalbeispiel basteln was ich mir in etwa vorstelle, dann aber reduziert um die ganze LVOOP und multiplen Aufruf des asynchronen SubVIs.

LV Version ist 2019

---

Nachtrag:

Wenn ich das richtige Stichwort "user event" gehabt hätte, hätte ich vermutlich auch früher gefunden was die Lösung für mein Problem sein dürfte... Ich werde mich mal damit auseinandersetzen. Das sollte User Event sollte aber ja genau das machen was ich eigentlich will wenn ichs richtig überreisse.

Was mir nur noch an Fragezeichen dann üblich geblieben ist / sind, sind die P.S. und die Frage wie ich bei meinem dynamischen Event dann hinterher wieder rauskriege welches Control das getriggert hat (CtrlRef sollte da helfen) und was passiert wenn ich die CtrlRef für ein User Event abfrage...

Gruß Kiesch

Hallo Kiesch,

Zitat:Soweit ich das überblickt habe gibt es bei den dynamischen Events keins das man allein im Blockdiagram (ohne Nutzung des FP) triggern kann.

Für UserEvents gibt es die Funktionen Create/Fire/Destroy.
Und du kannst ein UserEvent dynamisch für deine Event-Struktur registrieren: damit kannst du es auch programmatisch "ohne FP-Nutzung" triggern…

Hi Gerd,

danke für den Hinweis. Ich hatte das gestern dann doch noch gesehen und eigentlich auch noch einen Post dazu geschrieben (und offenbar nicht auf absenden geklickt).

Ein paar Fragezeichen bleiben dann aber noch übrig:

1. Die P.S.e - kann ich beim dynamischen Event einfach eine leere Referenz bei der Eventregistrierung reinschreiben? Ich habs mal ausprobiert und es crasht nicht direkt bei der Event Registrierung, aber können da später Probleme kommen? Das würde mir das Leben erleichtern, da ich dann nicht drumherum arbeiten muss, dass die Stop Taste optional ist. Die wird dann halt als leere Referenz reingegeben und triggert nie...

2. In der Event Struktur muss ich abfragen woher das Event kommt (von Stop oder Start; das kriege ich aus dem Label Text raus über die Control Referenz). Wie spielen da die User Events rein? Bei denen gibts ja kein Control und damit vermutlich keine Control-Referenz... Oder kriegen die bei den dynamischen Events einfach einen eigenen Rahmen? Arbeite das erste mal mit den dynamischen Events... Kanns auch erst nachher rausprobieren, falls die Lösung offensichtlich seht es mir bitte nach.

3. Es wird ja immer davon gewarnt parrallele Event Strukturen zu nutzen. In meinem Fall habe ich genau das ja zur Laufzeit (zumindest soweit der Nutzer mehr als einen Counter nutzen will). Jeder Counter sollte in der derzeitigen Architektur einen eindeutig unterscheidbaren Namen haben. Damit hat auch jeder Counter eigene Controls so dass bei Betätigung des Controls nur in einem Counter ein Event ausgelöst wird. Da die VIs noch dazu unabhängig voneinander parrallel laufen sollte es da denke ich kein Risiko geben, dass sich was verklemmt oder?
Was wäre wenn man Doppelnutzung zulässt (ein Button wird in mehreren Countern zum Starten genutzt)? Soweit ich das immer verstanden habe, kriegt jede der Event Strukturen dann ja ein eigenes Event. Funktionieren sollte das also auch, aber bestehen da praktische Probleme die man (aufgrund der parrallelen Event Strukturen) beachten muss?
Mir ist dabei grade auch aufgefallen, dass der Nutzer das sogar jetzt schon machen kann, da ich nicht prüfe ob die Namen aller Kanäle wirklich eindeutig sind... Wenn sie es nicht sind funktioniert derzeit der Code einfach nur nicht wie vorgesehen. Sowas sollte man glaube ich nicht dem Nutzer überlassen....

Gruß Kiesch

Hallo Kiesch,

1. Das habe ich so noch nicht ausprobiert. Wenn es bei der Registrierung keine Fehler gibt, sollte es später auch funktionieren. (Ein "leeres" Event triggert dann eben nie.) Du musst eben nur schon im Code den Event-Case angelegt haben…

2. UserEvents beziehen ihren Namen aus dem Label, dass du der (meist) Konstante beim CreateEvent gibst:
   

3. Parallele Event-Strukturen, noch dazu in parallel laufenden VIs, sind kein Problem. Innerhalb eines VIs deuten sie eher auf eine schlechte Architektur hin…

Zitat:Mir ist dabei grade auch aufgefallen, dass der Nutzer das sogar jetzt schon machen kann, da ich nicht prüfe ob die Namen aller Kanäle wirklich eindeutig sind... Wenn sie es nicht sind funktioniert derzeit der Code einfach nur nicht wie vorgesehen. Sowas sollte man glaube ich nicht dem Nutzer überlassen....

Nein, eher nicht…

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.