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!
ich habe in folgendem VI einen Effekt den ich mir nichr erklären kann wo der herkommt. Vieleicht sieht es jemand von euch.
Was soll das VI machen?
Solange T0 betätigt ist soll die Whilschlife ausgeführt werden, T0 nur True während Maustaste gedrückt - funktioniert
Bei einfachem Druck auf eine andere Taste soll die entsprechende Meldung ausgelöst werden (da kommen noch Melder hin) - funktioniert
Jetzt der Effekt: Bei Doppelklick auf T0 rastet diese. Wieso? Ich weiß nur das es etwas mit der Wartezeit von 100ms zu tun hat.
"Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen." (Albert Einstein)
Anzeige
17.08.2010, 07:48 (Dieser Beitrag wurde zuletzt bearbeitet: 17.08.2010 07:49 von GerdW.)
schon etwas kompliziert, deine Logik... Hast einen Cluster auf dem UI, welches der Benutzer bedienen soll und wo du munter vom Programm aus Werte reinschreibst...
1) Du erzeugst einen Melder-Eintrag bei jeder Wertänderung von T0, also auch, wenn der Benutzer den Knopf loslässt. Vielleicht nur dann Meldungen erzeugen, wenn T0=TRUE?!
2) Du vergleichst ein boolsches Element mit TRUE auf Gleichheit. Was soll das? (Das ist unnötig, google mal nach Rube-Goldberg! IF TRUE=TRUE THEN TRUE ELSE FALSE )
3) Unbundle by Name trägt ungemein zur Lesbarkeit von Code bei...
4) Wieso schreibst du nach deiner While-Schleife nochmal ein FALSE in den Cluster? T0 ist doch schon FALSE - sonst wäre die Schleife nicht beendet worden... (Der komplette Frame2 ist unnötig - RubeGoldberg!)
wie soll ich sonst ein Bedienelement anpassen wenn sich deren Zustand programmbedingt ändern muss?
1) wie fragst du T0=TRUE ab? ich habe jetzt in der Ereignisstruktur über Wertänderung den neuen Wert abgefragt und gesagt wenn True dann schreibe in Melder, sonst nix
2) stimmt ist sinnlos
3) nehm ich normalerweise auch aus diesem Grund. Nur hier eben nicht. Warum weiß der Geier - vielleicht auch nicht.
4) Den 2. Frame benötige ich um beim verlassen von der Whileschleife den vorhergehenden Status wieder herzustellen. Setzte ich dabei nicht auf False so wird dieser wieder TRUE
geist
"Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen." (Albert Einstein)
17.08.2010, 10:06 (Dieser Beitrag wurde zuletzt bearbeitet: 17.08.2010 10:07 von GerdW.)
"4) Den 2. Frame benötige ich um beim verlassen von der Whileschleife den vorhergehenden Status wieder herzustellen. Setzte ich dabei nicht auf False so wird dieser wieder TRUE"
Dein T0-Schalter ist so konfiguriert, dass er TRUE bleibt, solange der Benutzer ihn gedrückt hält. Lässt der Benutzer los, geht er auf FALSE zurück. Deine While-Loop läuft, bis der Schalter auf FALSE geht. Im nächsten Frame setzt du den Schalter dann (zur Sicherheit?!) nochmal auf FALSE?
Ziel ist, wenn zuvor beispielsweise T6 gedrückt war, dass nach dem loslassen von T0 auch T6 wieder gesetzt wird. Da ich aber das Cluster mit den Werten vom drücken der Taste T0 initalisiere, muss ich T0 erneut auf False setzten. Ich will letzlich nur dass ich wieder die vorherige Ausgangsstellung erreiche.
geist
"Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen." (Albert Einstein)
da sieht man mal wieder schön, warum (Un)BundleByName hier Vorteile hat: man muss nur das setzen, was wirklich nötig ist und muss nicht alle Eingänge betrachten...
das ich nur das Element betrachten brauch was ich ändern will ist bei (Un)BundleByName soweit klar. Benötige dabei aber jedesmal ein Eingangscluster. Und bei diesem steht in meinem Programm T0 nuneinmal auf True.
Ich habe aber irgendwo das Gefühl dass wir aneinander vorbeireden, oder ich dich nicht ganz verstehe. Somal ich das gleiche Ergebnis erziele wenn ich BundleByName nehme, oder eben das andere nehme. Vieleicht hast du ein Beispiel für jede Variante.
Auf das mir ein Licht aufgeht.
geist
"Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen." (Albert Einstein)
Zu deinem eigentlichen Problem:
Bei einem Doppelklick unter 100ms bekommt deine While-Loop den Schaltvorgang nicht mit und läuft ungestört weiter - der zwischenzeitliche Umschaltvorgang H->L->H wurde ja "übersehen". Entweder machst du die While-Loop schneller (z.B. 10ms, wobei nur jede 10 Iteration gezählt wird) oder du verwendest in der Loop auch ein Event (z.B. per Melder von deinem Event-Producer-Loop)...
da sieht man wieder wer mehr Programmiererfahrung hat. Dein Programm macht nix anderes ist aber deutlich sinnvoller aufgebaut.
Jedenfalls weiß ich jetzt vorauf du vorhin hinaus wolltest.
Ich denke ich werde mich für die schnellere Whileloop entscheiden. Mit mehreren Event-Producer-Loop in einem VI habe ich noch keine guten Erfahrungen gemacht.
Jedenfalls dank ich dir
geist07
"Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen." (Albert Einstein)
ich meinte nicht, dass du mehrere Event-Strukturen verwenden sollst. Eine reicht...
Du müsstest nur in der While-Loop ebenfalls auf deinen Melder reagieren, dem kann man ja auch einen TimeOut ("Wait on Notification") vorgeben. Der TimeOut ersetzt dann den bisherigen "Wait"-Aufruf...
)