Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
folgende Frage. Bei dem angehängten Schnipsel stoppe ich zeitgleich ein VI das ich über asynchronen Aufruf gestartet habe und überwache, wann das VI beendet ist. Merkwürdigerweise wird zwar in dem entsprechenden VI der Stoppbutton gedrückt, aber das VI bleibt auf Status-Running und auch der Pfeil Run zeigt dies an. Wenn ich allerdings die "Lampe" anschalte, gibt es kein Zeichen, dass das VI noch läuft (keine Bewegung hier). Hatte zuvor mit allgemeiner VI-Referenz gearbeitet, da funktionierte es. Leider wird der Code dann unübersichtlicher, weil ich vor dem VI Start einige Werte setzen muss. Verstehe nicht, warum es sich hier anders verhält. Hat jemand eine Idee?
mit dem gezeigten Code setzt du ein Control namens "Stop" auf TRUE - nicht mehr, aber auch nicht weniger.
Interessant wäre jetzt allerdings, ob dein "referenziertes VI" dieses Control überhaupt (und wann) ausliest/auswertet…
Zitat:Wenn ich allerdings die "Lampe" anschalte, gibt es kein Zeichen, dass das VI noch läuft (keine Bewegung hier).
Das heißt nur, dass das VI gerade auf irgendetwas wartet.
Auch hier wäre es hilfreich, dieses ominöse VI zu sehen…
Zunächst einmal:Das aufgerufene VI wird nur an einer Stelle aufgerufen. Ich hänge einen Screenshot an. Es erzeugt ein TriggerSignal auf unbestimmte Zeit und schaltet dieses ab, wenn es per Stopp oder Fehler oder Stopp in anderen verknüpften VIs angehalten wird.
aufgerufenes VI
04.03.2016, 09:05 (Dieser Beitrag wurde zuletzt bearbeitet: 04.03.2016 09:05 von GerdW.)
dann lege doch mal einen Breakpoint in dein subVI, direkt vor die While-Schleife. Ab da dann per Highlighting beobachten, was das subVI macht und wie/ob es auf deinen Stop-Befehl reagiert…
Wieso musst du dieses subVI überhaupt asynchron starten? Warum nicht einfach parallel zur Hauptschleife aufrufen?
Mit aller Vorsicht:
Wenn ich mich richtig erinnere, dann haben auch Kollegen von mir ab/bei LabVIEW 2013 ein Problem mit dieser PropertyNode. Seltsamerweise wird immer der Status "Running" zurückgegeben, sobald das VI auch nur im Speicher ist.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Ein Vi besitzt dann den Status running, wenn es als Sub-Vi in einem running Vi sitzt.
Wenn ein Vi nur über Vi-Server aufgerufen wird und ausgeführt wird, dann besitzt es den Status 'running top level', ist lediglich die Referenz im Speicher, dann gilt der Status 'idle'.
Also, wenn ein Vi wirklich Stoppen soll (im Sinne von bearbeitbar), dann darf es in keinem anderen Vi als Unterfunktion eingehangen sein!
(04.03.2016 10:10 )jg schrieb: Mit aller Vorsicht:
Wenn ich mich richtig erinnere, dann haben auch Kollegen von mir ab/bei LabVIEW 2013 ein Problem mit dieser PropertyNode. Seltsamerweise wird immer der Status "Running" zurückgegeben, sobald das VI auch nur im Speicher ist.
Gruß, Jens
Das ist nicht erst seit LabVIEW 2013 so. Ein VI bekommt den Status running, sobald es in irgendeiner Hierarchy benützt wird die running ist. Auch wenn eine strikte VI Server Referenz darauf offen ist. Der State Property kennt nur bad", "idle", "running", "run top level" und sonst nichts. Um unterscheiden zu können op ein VI wirklich gerade running ist oder nur Teil einer running Hierarchy und/oder mit einer offenen strikten VI Reference müsste der State "running" aufgeteilt werden in "reserved for running" und "running" aber das hätte weitreichende Folgen für die Backwardskompatibilität von bestehenden Applikationen.
