LabVIEWForum.de - Sofortiger Stop einer While-Schleife in einer SubVi durch MainVi

LabVIEWForum.de

Normale Version: Sofortiger Stop einer While-Schleife in einer SubVi durch MainVi
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2 3 4
' schrieb:Ist das korrekt?
Jawohl.

Zitat:Ist das so, wie du es vorschlaegst, bitte?
Jawohl.

Zitat:Was passiert eigentlich, wenn ich einen weiteren JiggleM2 Button mit einem entsprechenden SubVi einfuehre?
Kann ich dann ebenfalls eine Referenz von "Stop Inner" in diese Sub.vi einfuegen und wenn man dann "Stopp inner"-Button drueckt, sendet dann "Generate User Event.vi" einen Befehl an alle moeglichen Eventstrukturen, die mit dem Draht bze. einer Referenz von "Stopp Inner" verbunden sind?
Ja, das geht tatsächlich. Ich hab das nämlich im Zuge dieses Themas hier mal kurz probiert.

Zitat:Entspricht das folgendem Verhalten: Ich druecke den Button "Stop inner" und er bleibt dunkelgrau und springt nicht zurueck zu hellgrau? Ich muss ihn im Moment immer manuell druecken und die Eigenschaft "Latch when released" ist nicht erlaubt, wohl aufgrund der Eventstruktur.
Genau das meine ich.
Zitat:Ichselbst, es tut mir leid, aber ich verstehe das nicht. Ich vermute ein wenig, ich muss die Filmstreifen benutzen und irgendwie vor die beiden inneren Schleifen parken.
Genau: Filmstreifen = Sequenzstruktur.

Zitat:Im Moment funktioniert auch der "Stop outer"-Button nicht. Man kann ihn zwar druecken, aber die Main.vi wird nicht beendet. Eigentlich sollte er die aeussere while-Schleife und beide inneren beenden und LabVIEW kontrolliert stoppen.
Das liegt daran:
Wenn du "StoppOuter" anklickst, wird nur die untere While-Schleife beendet, nicht aber die obere. Weil die obere While-Schleife aber noch läuft, kann das MainVI nicht beendet werden.

Zitat:Ich habe auch keine Erklaerung dafuer gefunden, warum in der Main.vi ganz links an der ausseren Schleife ein Boolean False mit einer lokalen Variable des "Stop outer" verbunden wurde. Setzt das mir generell den "Stop-Outer" Button auf false?
Ja, natürlich. Was hast du denn gedacht?
Mittels "Lokaler Variablen" kann man nämlich das Bedienelement manipulieren.

Zitat:Ich habe meine Vi "Set_flow_rate_and_direction.vi" noch einmal vor die beiden inneren while-Schleifen eingebaut und in der Eventstruktur (sihe ober innere while-Schleife) eine lokale Variable der "flow properties" generiert.
Ist ein solches Verfahren gefaehrlich, eventuell aus Datenflussgruenden?
Dieses Verfahren ist nicht gefährlich. Du kannst das bedenkenlos so machen.


' schrieb:Ich habe jetzt die Mechanical Action des "Stopp inner" Buttons zu "Switched until released" geaendert. Dann springt er zumindest wieder in den hellgrauen Zustand zurueck und verbleibt nicht im dunkelgrauen, gedrueckten Zustand.
Dann funktioniert auch der "Stopp outer" Button in folgender Art und Weise: Man drueckt entweder "Stop inner" zuerst und dann "Stop outer", LabVIEW bricht ab, oder erst "Stop outer", dann "Stop inner", LabVIEW bricht ab.
Ist so ok.


' schrieb:Ich habe an der aeusseren while-Schleife eine Boolean False mit einer lokalen Variable von "Stop inner"-Button verknuepft. Damit wird ja zunaechst sichergestellt, dass der Button nicht zufaelligerweise auf True steht.
So hab ich das gemeint.


quote11: (<= Forum lässt nur 10 quotes zu)
Wenn ich das mit dem Datenfluss kapiert habe, dann wird doch erst alles ausgefuehrt, wenn alle Ports belegt sind oder when die untere, innere while-Schleife beendet ist. Haette ich nicht damit schon eine Sequenzierung, sowohl bevor die beiden inneren Schleifen starten als beim Zuruecksetzen des Buttons "Stop inner" rechts an der unteren, inneren while-Schleife?
/quote11:
Datenfluß ist immer dann, wenn irgendwelche Elemente durch einen Wire verbunden sind.
Für das Zurücksetzen des Buttons rechts nach der unteren While-Schleife hast du Recht: Dieses Zurücksetzen wird erst nach der While-Schleife gemacht, weil zwischen den beiden Elementen "While-Schleife" und "Button" ein Datenfluß (die grüne Linie) besteht.
Beachte daher folgendes:
Das Zurücksetzen links in der großen While-Schleife ist eigentlich sinnlos. Streng genommen kann dieses Zurücksetzen nämlich als allerletzter Befehl innerhalb der While-Schleife gemacht werden - also noch nach dem Zurücksetzen des "linken Buttons". Das kommt eben daher, weil es für das linke Zurücksetzen keinerlei Datenfluß gibt. Wann das linke Zurücksetzen tatsächlich ausgeführt, wird ist nicht festgelegt. Du darfst nicht vergessen: In LV gibt ein kein abarbeiten von Linsk nach Rechts - hier gilt lediglich Sequenzierung!
' schrieb:Ich habe einen dritten Eventcase eingefuegt, der value change of "Stop outer" weitergibt und diese ebenfalls stoppt. Ich habe dafuer eine lokale Variable von "Stop outer" in die Eventstruktur der oberen, inneren Schleife gelegt. Darf man das machen?
Darf man so machen.

Zitat:Ist es egal, ob "Stop outer" in dieser Evenstruktur sitzt, die entsprechende lokale Variable in der unteren, inneren while-Schleife oder umgekehrt?
Das ist egal. Beides geht.
Normalerweise macht man es so, dass das Bedienelement im Event-Case liegt und die Lokalen Variablen außerhalb. Beachte außerdem, dass es links im Eventcase neben den Parametern "Typ" und "Zeit" auch den Parameter "Neuer Wert" gibt. Dieser Parameter beinhaltet den Wert des Bedienelementes.

Zitat:Ich denke, es werden dann mit einem Button sowohl die beiden innern als auch die auessere Schleife gestoppt. LabVIew bricht jedenfalls sofort ab.
Jawohl, genau so.

Zitat:Ich finde es gut, wenn an der aeusseren Schleife bereits am Anfang alle Buttons mit Mechanical Action "Switched when released" auf false zur Sicherheit gesetzt werden. Ansonsten wuerde die Pumpe sofort loslegen, wenn vorher dem Start von LabVIEW einer der Button auf True stehen wuerde.
So macht man das.

Zitat:1. Muss ich auf der rechten Seite der inneren, unteren while Schleifen die beiden Buttons Stop inner und Stop outer auf false per lokale Variable zuruecksetzen?
Eigentlich nicht. Das ist überflüssig.

Zitat:2. Muesste ich die Buttons Infuse, Withdraw, Jiggle M1 per lokaler Variable und Boolean false an der linken Seite der unteren, inneren Schleife ggf. auf false zuruecksetzen oder reicht das nicht wie ich das gerade gemacht habe? Ich bin bei der jetzigen Version geblieben, da ich aufgrund des "error out" und des "VIsa Resource" Drahtes ein vorgegebene Reihenfolge habe.
Das reicht. Guckst du aber das Bild im Anhang.

Hinweis:
Das Schaltverhalten der drei Bedienelemente "Infuse", "Withdra", und "Jiggle M1" kann du auf "Latch beim Loslassen" stellen. Die Lokalen Variablen dieser Elemente brauchst du dann nicht mehr. Das Verhalten ist dann genau wie jetzt.
' schrieb:Das liegt daran:
Wenn du "StoppOuter" anklickst, wird nur die untere While-Schleife beendet, nicht aber die obere. Weil die obere While-Schleife aber noch läuft, kann das MainVI nicht beendet werden.
Es hat echt gedauert, bis ich das gesehen habe.

Zitat:Ich habe jetzt die Mechanical Action des "Stopp inner" Buttons zu "Switched until released" geaendert. Dann springt er zumindest wieder in den hellgrauen Zustand zurueck und verbleibt nicht im dunkelgrauen, gedrueckten Zustand.
Dann funktioniert auch der "Stopp outer" Button in folgender Art und Weise: Man drueckt entweder "Stop inner" zuerst und dann "Stop outer", LabVIEW bricht ab, oder erst "Stop outer", dann "Stop inner", LabVIEW bricht ab.
Das funktioniert doch nur deswegen, weil ich erstmal die Mechanical Action des "Stop inner"-Buttons in "Switched until released" geaendert habe und der Button dann wieder in den urspruenglichen Zustand zurueckspringt. Es wird dann die Eventstruktur ausgeloest und die obere, innere while-Schleife stoppt. Deswegen muss man danach noch "Stop outer" druecken, um alle verbleibenden while-Schleifen zu stoppen.
So habe ich das jetzt verstanden.

Ich finde meine jetztige Version, die bei einmaligen Druecken ds "Stop outer" alles beendet, besser.

Das bringt mich noch zu einer anderen Beobachtung:
Oft liegt ja in einem Eventcase eine Boolean, bei ist es z.b. ein Stop-Button. Ich habe mich jetzt fuer folgendes entschieden: Den Stop-Button nicht direkt mit der naechsten Vi oder stop einer whil-Schleife verbinden, sondern neben den Stop-Button eine Boolean True in die event case legen, die dann zusichert, dass auch wirklich ein true-value weitergeleitet wird.
Ich weiss nicht, ob ich da uebertreibe, aber wenn man sich vielleicht mit der mechanical action eines Buttons unsicher ist, hilft das vielleicht?
Value change bedeutet doch nur, dass sich etwas aendert und nimmt keine Rueckicht auf den eigentlich boolean-Wert. Stimmt das? Deswegen glaube ich das "Stop outer" dann, wie kurz zuvor oben beschrieben, ermoeglichte, die Schleife zu beenden. Es hat sich halt irgendwas gaendert und das reichte, den event case auszuloesen.

' schrieb:Das Schaltverhalten der drei Bedienelemente "Infuse", "Withdra", und "Jiggle M1" kann du auf "Latch beim Loslassen" stellen. Die Lokalen Variablen dieser Elemente brauchst du dann nicht mehr. Das Verhalten ist dann genau wie jetzt.
Ist "Latch beim Losslassen" "Latch when released"?
Ich glaube, das war urspruenglich auch so.

EDIT: IchSelbst, entschuldige, aber bist du dir sicher, das das geht? Ich habe versucht, den Infuse-Button auf "Latchen when released" umzustellen. Dann gab es eine Fehlermeldung, dass bei latch keine lokalen Variablen erlaubt seien. Also bleibt der Button erstmal bei "Switched when released".
Ich benoetige doch die lokale Variabel des Buttons fuer die Sequenz, wie in deinem Bild dargestellt.


' schrieb:In LV gibt ein kein abarbeiten von Linsk nach Rechts - hier gilt lediglich Sequenzierung!
Was bestimmt bitte die Sequenzierung? Die Kabel, die dann auch den Datenfluss bestimmen?
Hallo IchSelbst.

Heute habe ich meine zweite Jiggle Methode M2 fertiggestellt.
Ich habe zwei Ansaetze versucht und beide basieren mehr oder weniger auf deinem und Luckis Vorschlag.

Diese Methode funktioniert so, dass man der Pumpe ein Targetvolumen vorgeben muss und sie solange pumpt, bis dieses erreicht wird.

1. Ansatz:

Date: Autofill_M2_LV2009_v1.vi

Ich habe im Timeout-Case der Eventstruktur eine while-Schleife hinzugefuegt, die solange laeuft, bis der Status T* or Target reached erreicht wird. Dann bricht sie ab und es beginnt der naechste Timeout-Case. Die Timeout-Zeit ist bei 0 sec, weil nicht gewartet werden muss.

Problem: Drueckt man in der Main.vi den "Stop-inner" Button, dann dauert es bis diese SubVi abgebrochen wird und zwar solange bis das Target reached erreicht wird, also die innerste while-Schleife in dieser SubVi beendet wird.

Ist das die richtige Erklaerung? Zweitens, haette man diese while-Schleife um die Status.vi sofort toeten koennen?


2. Ansatz:
Datei: Autofill_M2_LV2009_v2.vi

Da ich nicht wusste, wie man diese ganz innere while-Schleife toetet, habe ich mich an einer zweiten Sub.vi namens Autofill_M2_LV2009_v2.vi gebaut.

Die Status.vi habe ich rausgeworfen. Dies Loesung ist aehnlich zu Jiggle M1-Methode. Es wird alles ueber die Timeout-Zeit geregelt und es gibt im Timeout keine weitere while-Schleife. Deswegen kann man diese Abfolge sofort unterbrechen.

Ich habe zur Timeout-Zeit noch 20ms addiert. Dann hat der Motor noch genug extra Zeit zu schalten, dass eine Bewwegung zu Ende ist und die naechste anfaengt. Lasse ich diese Extra-Zeit weg, macht der Schrittmotor Probleme. Hat diesbzgl jemand Erfahrung, wenn man einen Schrittmotor zu schnell die Richtung umkehren laesst?

Diese Version funktioniert und deswegen nutze ich sie jetzt.

Was noch nicht 100% funktioniert, ist die Ausgaben 0.5 cycle und Time t von den sub.vis in die mains zu holen, so dass die immer aktuell dargestellt werden Bisher ist es so, dass die entsprechenden Anzeigen in der Main.vi nur upgedated werden, wenn die Sub.vi beendet ist.

Gruesse
blue

Lv09_img2
Werteuebertragung von Sub ins Main konnte ich mir mit diesen Beitrag beantworten. Funktioniert auch. Allerdings vielleicht eine Frage:
Warum ist es ein DigNum (strict) property node und kein normaler property node? Strict heisst doch, dass der Datentyp beibehalten wird, oder?
Danke, Blue
' schrieb:IchSelbst, entschuldige, aber bist du dir sicher, das das geht? Ich habe versucht, den Infuse-Button auf "Latchen when released" umzustellen. Dann gab es eine Fehlermeldung, dass bei latch keine lokalen Variablen erlaubt seien. Also bleibt der Button erstmal bei "Switched when released".
"Latchen" bedeutet ja, dass der Button automatisch wieder resettet wird, sobald das Bedienelement ausgelesen wird. Das hat zur Folge, dass es hier keine lokalen Variablen gibt.
Es ist so:
Normalerweise hat der Button den Wert false. Wird er geklickt, schaltet er sich automatisch auf true - und bleibt solange auf true, bis im Blockdiagramm das Bedienelement ausgelesen wird. Mit diesem einen Auslesen wird der Button automatisch wieder auf false gesetzt. Und da das Resetten automatisch geht, brauchst du im Blockdiagramm keine Lokalen Variablen zum restetten.

Zitat:Was bestimmt bitte die Sequenzierung? Die Kabel, die dann auch den Datenfluss bestimmen?
Jawohl, genau diese Kabel bewirken eine Sequenzierung. Das, was durch das Kabel verbunden wird, wird ja der Reihe nach - also sequenziell - verarbeitet. Und da man mit Kabeln gut sequenzieren kann, verwendet man häufig den sogenannten Error-Cluster zum Sequenzieren. Hat man keine Möglichkeit zum Kabel ziehen, kann man eben den Sequenzrahmen nehmen.
' schrieb:Warum ist es ein DigNum (strict) property node und kein normaler property node? Strict heisst doch, dass der Datentyp beibehalten wird, oder?
Das ist ein weites Feld.

Eben deswegen: "Strict heisst doch, dass der Datentyp beibehalten wird" - der Typ des Propertys, hier DBL, wird erzwungen, also beibehalten.

Ein Property ist immer an ein Objekt gebunden. Erstellst du ein Property von einem Bedienelement am Frontpanel, weis das Property, zu welchem Objekt es gehört. Das Property kennt also den Typ des Bedienelementes - hier nämlich DBL. Ein solches Property hat keinen Referenzanschluss. Ist auch nicht nötig, es gehört ja zu einen bestimmten Objekt.

Jetzt kann man aber auch Propertys erstellen ohne Bezug zu einem Frontpanelelement, also "objektfreie" Propertys. Solche Propertys brauchen dann aber einen Referenzanschluss. Die Referenz gibt nämlich das Objekt an, das vom Property bearbeitet werden soll. Wenn du dir jetzt die Referenz im SubVI ankuckst, siehst du, dass diese Referenz die "Eigenschaft" DBL hat. Und weil aus der Referenz bereits hervorgeht, dass es sich bei dem zu bearbeitenden Objekt um eines vom Typ DBL handeln wird, ist das eigentlich objektfreie Propertys doch typ-gebunden - daher steht hier strict.

Der dritte Fall ist folgender:
Das Property bekommt zwar ein Objekt zugewiesen (ohne Objekt wäre sinnlos) - aber keinen Typ. Das heißt der Typ des Objektes ist unbekannt. Dann steht auch nicht strict drinnen. Dann gibt es aber auch keinen bereits zur Entwicklungszeit festgelegten Typ, also weder DBL, noch String, noch I32 etc. Der Typ ist dann Variant.
' schrieb:Problem: Drueckt man in der Main.vi den "Stop-inner" Button, dann dauert es bis diese SubVi abgebrochen wird und zwar solange bis das Target reached erreicht wird, also die innerste while-Schleife in dieser SubVi beendet wird.
Ist das die richtige Erklaerung?
Ja, das ist die richtige Erklärung.

Zitat:Zweitens, haette man diese while-Schleife um die Status.vi sofort toeten koennen?
So wie du das hier programmiert hast, geht das nicht.

Was man aber auch nicht machen soll, ist in einem Event-Case eine langdauernde While-Schleife zu verwenden. Das ist ganz schlecht.


Zitat:Da ich nicht wusste, wie man diese ganz innere while-Schleife toetet, habe ich mich an einer zweiten Sub.vi namens Autofill_M2_LV2009_v2.vi gebaut.
Hinweis: Ein Prozess wird auch in Deutschland gekillt, eine While-Schleife aber beendet. Yahoo
So z.B. kann man das machen. Wichtig ist, dass in einem Event-Case nur Code ausgeführt wird, der praktisch keine Zeit kostet.

Zitat:Ich habe zur Timeout-Zeit noch 20ms addiert. Dann hat der Motor noch genug extra Zeit zu schalten, dass eine Bewwegung zu Ende ist und die naechste anfaengt. Lasse ich diese Extra-Zeit weg, macht der Schrittmotor Probleme. Hat diesbzgl jemand Erfahrung, wenn man einen Schrittmotor zu schnell die Richtung umkehren laesst?
Mach hier am besten ein neues Thema auf.

Zitat:Was noch nicht 100% funktioniert, ist die Ausgaben 0.5 cycle und Time t von den sub.vis in die mains zu holen, so dass die immer aktuell dargestellt werden Bisher ist es so, dass die entsprechenden Anzeigen in der Main.vi nur upgedated werden, wenn die Sub.vi beendet ist.
Hat sich ja erledigt.
IchSelbst, vielen Dank fuer deine ausfuehrlichen Erklaerungen. Yourock
Viele Gruesse
blue
Seiten: 1 2 3 4
Referenz-URLs