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!
habe ein kleines Problem mit meiner Ereignisstruktur: Wertänderung.
In der Ereignisstruktur soll eine Casestruktur 2x aufgerufen werden (mit unterschiedlichen Variablen).
Diese wird allerdings nur 1x aufgerufen (immer der letzte Eintrag).
Wenn man sich das Programm anschaut sieht man direkt was gemeint ist.
ciao
Funaukel
Anzeige
30.03.2012, 08:04 (Dieser Beitrag wurde zuletzt bearbeitet: 30.03.2012 08:08 von GerdW.)
Oder etwas verständlicher ausgedrückt: Nochmal den in meiner Signatur verlinkten Basics-Kurs durchgehen und DATAFLOW verinnerlichen!
Fehler:
- Dataflow missachtet und lokale Variablen benutzt
- Dataflow missachtet und eine Case-Struktur in einer Iteration deiner Schleife zweimal aufrufen wollen
- Aufräumknopf nicht benutzt: warum sollen wir erst dein BD aufräumen, wenn du Lösungen haben willst
Mögliche Lösung:
- QSM (QueuedStateMachine) verwenden und Befehle als Cluster[String,Wert,Wartezeit] versenden
- statt eines Strings ein typdefiniertes Enum verwenden
- parallele Schleifen verwenden
- Basics-Kurs durchgehen!
Besser hätte ich meine LabView Künste nicht beschreiben können.
Immer wenn ich denke, ich habe LabView halbwegs verstanden, kommt wieder eine neue Baustelle auf mich zu.
(30.03.2012 08:04 )GerdW schrieb: Oder etwas verständlicher ausgedrückt: Nochmal den in meiner Signatur verlinkten Basics-Kurs durchgehen und DATAFLOW verinnerlichen!
Fehler:
- Dataflow missachtet und lokale Variablen benutzt
- Dataflow missachtet und eine Case-Struktur in einer Iteration deiner Schleife zweimal aufrufen wollen
- Aufräumknopf nicht benutzt: warum sollen wir erst dein BD aufräumen, wenn du Lösungen haben willst
Mögliche Lösung:
- QSM (QueuedStateMachine) verwenden und Befehle als Cluster[String,Wert,Wartezeit] versenden
- statt eines Strings ein typdefiniertes Enum verwenden
- parallele Schleifen verwenden
- Basics-Kurs durchgehen!
Vielen Dank.....Mit der Aussage hast du mir so eben mein Wochenende versaut/gerettet.
Werde mich dann mal an die Arbeit begeben.
Die von Gerd erwähnte Queue driven State machine (Googeln mit Labview QSM) ist extrem variabel, und auch dein Problem, von einem Ereignis aus mehrere Cases (oder mehrere Male denselbsen Case) zu aktivieren, ist damit elegant lösbar. Allerdings halte ich es für unwahrscheinlich, dass Du das als Anfänger von selbst hinbekommst, deshalb hier ein kleine Vorlage.
Habe eine Frage zum Datentyp der Queue.
Kann dieser variabel sein?
d.h. Ich schreibe an Queue Position 1: Enum + I8
und an Position 2: Enum + Cluster
und an Position 3: Enum + DBL
usw.....
Da in den State-Maschines auch verschiedene Datentypen verwendet werden können, will ich in die Queue veränderbare Variablen schreiben.
Ist das möglich in LabView?
ciao
30.03.2012, 12:30 (Dieser Beitrag wurde zuletzt bearbeitet: 30.03.2012 12:31 von GerdW.)
nein, eine Queue kann nur mit einem festen Datentyp arbeiten. Aber:
Du kannst natürlich einen Datentyp designen, der alle deine Erfordernisse abdeckt, z.B. ein Cluster mit String, DBL, INT32, Enum-Kommando. Je nach Kommando wird dann der passende Wert aus dem Cluster weiterverwendet...
Noch mehr Aber:
Du kannst natürlich auch ein Variant für die Queue-Definition verwenden, musst dann aber jeweils korrekt konvertieren...
Eine andere Möglichkeit, die verschiedensten Datentypen zu übertragen, ist deren Serialisierung/Deserialisierung zu/aus einem String. Ich habe noch ein altes Labview-Buch aus Zeiten von LV6/LV7, da ist die QSM bereits mit Beispielen vertreten, es gab aber noch nicht den Datentyp Variant. Deshalb wurde es ausschließich so gemacht. Beispiel (Zu sehen ist hier nur die Deserialisierung):
.
Gerd hat aber Recht, wenn er das gar nicht erwähnt. Der Datentyp Variant ist gewissermassen die modernere Variante dieser Prozedur, ich würde es jetzt auch nur noch so machen. Neuere Lehrbeispiele sehen dementsprechend eher so aus:
Ich verwende inzwischen durchwegs statt Variant die Funktionen 'flatten to XML' und 'unflatten from XML' wenn ich Argumente mit unterschiedlichen Datentypen in einer State Machine zu übergeben habe. Habe ich mir angewöhnt, als ich bei irgendeiner Variant-Umwandlung auf ein 'das geht nicht' gestossen bin (weiss nimmer genau was es war - irgendwas mit Array oder Cluster).
@THL
Sehr guter Hinweis, das wußte ich gar nicht.
Da bei HTML der meiste Zeichensalat erzeugt wird, vermute ich zwar, daß die Konvertierungsgeschindigkeit in abnehmender Reihenfolge Variant - String - HTML ist. Aber ich will den Vorschlag damit nicht herunterspielen, meist ist ja die Ausführungsgeschwindigkeit nicht an einer kritischen Grenze.
