+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Umschalten von Programmfunktionen über Registerkarte (/Thread-Umschalten-von-Programmfunktionen-ueber-Registerkarte)
Umschalten von Programmfunktionen über Registerkarte - Kiesch - 22.10.2009 14:22
Hallo,
habe eine Frage zur Funktion und Nutzung der lokalen Variablen. Und zwar hab ich auf meinem Display eine Registerkarte eingesetzt, die zwischen verschiedenen Methoden zur Eingabe einer Position auf einem 4 Zoll Wafer realisieren soll. Soweit erstmal kein Problem.
Allerdings habe ich jetzt zum Umschalten zwischen den verschiedenen Prozessen eine zweite Schleife integriert (parralel laufen) um zwischen den Verschiedenen Methoden jederzeit umschalten zu können (durch klicken auf der Registerkarte). Nun scheint es allerdings so zu sein, dass mein Ausgabeport der Variable mit dem ich eigentlich nur den Case Switchen möchte bei Abfrage gleichzeitig auch meine Registerkarte zurücksetzt (so siehts zumindest für mich aus), wenn ich diese umgeschaltet habe. Effektiv äußert sich das, indem die Registerkarte manchmal direkt nach dem klick auf die alte Seite zurückswitcht.
Leider lässt sich auch das parralel laufen der Abfrage und somit die Nutzung der Lokalen Variable eigentlich nicht vermeiden (zumindest nicht ohne größere Umbauten und einen schwerer nachvollziehbaren Code; in meinem Cases sitzt am Ende wohl je eine While Schleife - entsprechend muss diese eigentlich zwingend parralel zur Abfrage der Registerkarte laufen.
Hat jemand eine Idee woran das liegen könnte und Lösungsvorschläge? Ich hatte schon daran gedacht ob mir eventuell Eventstrukturen weiterhelfen könnten, jedoch bin ich leider nicht genügend vertraut damit - ich wäre daher sehr verbunden wenn mir jemand gute Lektüre zu Eventstrukturen empfehlen könnte (möglichst kostenfrei ^^).
Gruß Kiesch
p.S: Angehängt ein vi LV 8.6 zur Verdeutlichung der Problematik (hab mal allen code rausgenommen der sonst nur irritieren würde; ja hardwired endlosschleifen sind böse, aber wie gesagt, das soll nur zur Demonstration dienen).
[attachment=21934]
Umschalten von Programmfunktionen über Registerkarte - Achim - 22.10.2009 14:47
Ich verstehe nicht, warum du den Wert eines Controls wieder auf eine Variable des gleichen Controls schaufelst...insbesondere da die Schleifen ohne Wartezeit laufen, ist doch nie klar, welcher Teil des Codes zuerst abgearbeitet wird und daher Vorrang hat...Stichwort "race condition"
Umschalten von Programmfunktionen über Registerkarte - Kiesch - 22.10.2009 14:59
Ah, ich sehe ich habe anscheinend einen gravierenden Denkfehler. Die lokale Variable (Ausgabe) funktioniert also gleichzeitig als Abfrage und wird (vor allem) ständig auch parralel durchgeführt ohne dass ich noch eine zweite Schleife brauche die die Abfrage realisiert? (so scheint es zumindest nachdem ich die zweite Schleife rausgenommen habe).
Gilt das generell? Also - werden lokale Variablen ständig parrallel zu allen anderen Prozessen aktualisiert?
P.S: Das die Parrallel ablaufen und sich deswegen ins Gehege kommen könnten, war mir bewusst, allerdings war ich der Meinung das Frontpanel Readout und Schreiben in die Lokale Variable ein Vorgang sind (ergo nicht nach dem auslesen unterbrochen wird; was dazu führt, dass danach ein veralteter zustand in die Variable geschrieben wird). Sorry für diese letztlich extremst einfach zu beantwortende Frage -.-
Umschalten von Programmfunktionen über Registerkarte - IchSelbst - 22.10.2009 18:29
Zitat:Effektiv äußert sich das, indem die Registerkarte manchmal direkt nach dem klick auf die alte Seite zurückswitcht.Ja, das ist genau so.
Das liegt an folgendem:
Der Wire, der vom Bedienelement zur lokalen Variablen geht, braucht eine gewissen Zeit. Wenn genau während dieser Zeit, sich das TabSheet am FP ändert, dann springt es wieder zurück. Das geht so: Zuerst wird "Seite 1" aus dem Bedienelement ausgelesen und auf den Wire gegeben. Dann findet ein TaskSwitch zwischen BD und FP statt, der Anwender klickt jetzt "Seite 2" an und die wird auch sichtbar. Und jetzt TaskSwitch wieder zurück von FP nach BD. Jetzt steht aber "Seite 1" im Wire und wird auf die lokale Variable geschrieben => TabSheet geht wie von selbst wieder auf "Seite 1".
Der Fehler wird noch dadurch verstärkt, weil die While-Schleifen ohne Wartezeit ablaufen!
' schrieb:Ah, ich sehe ich habe anscheinend einen gravierenden Denkfehler. Die lokale Variable (Ausgabe) funktioniert also gleichzeitig als Abfrage und wird (vor allem) ständig auch parralel durchgeführt ohne dass ich noch eine zweite Schleife brauche die die Abfrage realisiert? (so scheint es zumindest nachdem ich die zweite Schleife rausgenommen habe).Wenn ich dich richtig verstanden habe, hast du bisher folgendes gedacht: Ich muss zuerst mal das Bedienelement in die lokale Variable schreiben, sonst funktioniert die obere While-Schleife nicht.
Dem ist aber nicht so. Sobald das Bedienelement geändert wird, haben automatisch auch alle lokalen Variablen, die zu diesem Bedienelent gehören, den geänderten Wert.
Zitat:Also - werden lokale Variablen ständig parrallel zu allen anderen Prozessen aktualisiert?Im Prinzip ja.
Sag es aber besser so: Eine lokale Variable hat immer den selben Wert wie das dazu gehörende Element (ob Bedien- oder Anzeigeelement ist dabei egal).
Zitat:Das die Parrallel ablaufen und sich deswegen ins Gehege kommen könnten, war mir bewusst,Das "Ins Gehege kommen" hat aber nichts mit lokalen Variablen an sich zu tun. Vielmehr damit, weil lokale Variablen des selben Elementes für gewöhnlich in unterschiedlichen Datenflüssen liegen. Und wegen des Datenflusses kann man nicht entscheiden, ob eine lokale Variable nicht doch eher ausgelesen wurde als sie von einen anderen Datenfluss beschrieben wird.
Zitat:allerdings war ich der Meinung das Frontpanel Readout und Schreiben in die Lokale Variable ein Vorgang sind (ergo nicht nach dem auslesen unterbrochen wird; was dazu führt, dass danach ein veralteter zustand in die Variable geschrieben wird).Im Prinzip ist das richtig.
Dein Fehler liegt ja auch nicht hierin, sondern in dem Vorgang, den ich oben beschrieben habe.