LabVIEWForum.de - Stringvergleich in case-Struktur

LabVIEWForum.de

Normale Version: Stringvergleich in case-Struktur
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2
' schrieb:Jens, Lucki,
meint ihr so???
Habe mal ein Beispiel gemacht. Es läßt sich noch eleganter machen, da sich das das meiste mehrmals wiederholt, aber ich wollte so wenig wie möglich verändern. Es ist fast alles leer, da muß Du noch ausfüllen. Neu ist jetzt, daß Du von jedem Punkt aus stoppen kannst oder auch zu einem beliebigen anderen State hinspringen kannst (Auf die blaue Leitung unten die entsprechend Zahl -1 geben) . Habe es jetzt einfach mal so gemacht, daß das VI bei 0 Bytes im Port stoppt, ohne den Rest noch zu machen.

LabVIEW rät übrigens von der exzessiven Verwendung von Sequenzstrukturen ab, so wie Du das hier praktizierst. Meist machen das Anfänger, die der Datenflußsteuerung nicht richtig trauen oder das Prinzip noch nicht richtig verstanden haben.
Lv85_img[attachment=15378]
Vielen, vielen Dank an euch beide. Jetzt ist mir das auch klar geworden;)Hab nun noch die Bedingungen eingebaut und hoffe nun das alles funktioniert. Allerdings ist mir immer noch nicht klar, warum LabVIEW die Sequenzen nicht nacheinander abarbeitet??? Wünsch euch einen schönen Feierabend.

Beste Grüße,

Thomas
' schrieb:Allerdings ist mir immer noch nicht klar, warum LabVIEW die Sequenzen nicht nacheinander abarbeitet???
Wie kommst du jetzt darauf?
' schrieb:Allerdings ist mir immer noch nicht klar, warum LabVIEW die Sequenzen nicht nacheinander abarbeitet???
Hat das hier jemand so behauptet? Ich wüßte nicht. Das Problem bei Sequenzen ist doch gerade, daß sie immer starr hintereinander abgeabeitet werden und deshalb wenig flexibel sind. Also wenn z.B in Sequenz 0 ein Fehler festgetellt wird, die die Abarbeitung der nachfolgenden Sequenzen sinnlos macht, so ist die Auslassung dieser nachfolgenden Sequenzen schlecht möglich.

Übrigens ist auch diese 3er-Sequenz "Senden - Warten - Lesen der Bytes aus dem Buffer" nicht unbedingt das Beste.
Z.-B. so: Bei der Konfiguration "Terminal Zeichen" definieren. Der Empfangene String sollte mit diesem Zeichen abschließen, also z.B "CR". Das Lese- VI wartet dann, bis das Zeichen im Buffer eintrifft und liest dann den Buffer aus. Damit hat man keine unnötigen Wartezeiten.
Oder so: Wenn kein Terminalzeichen da ist, aber die Anzahl der zu erwartenden Bytes genau bekannt ist, dann ebenfalls Wartezeit weglassen und die Anzahl Bytes als Konstante an den VI-Eingang anlegen.
Guten Morgen Lucki,

"Oder so: Wenn kein Terminalzeichen da ist, aber die Anzahl der zu erwartenden Bytes genau bekannt ist, dann ebenfalls Wartezeit weglassen und die Anzahl Bytes als Konstante an den VI-Eingang anlegen."

Die Problematik bei mir ist, das er die Wartezeiten nicht einhält!!! Allerdings klingen Deine Vorschläge sehr gut. Das mit dem Terminalzeichen funktioniert wohl nicht, da mein Gerät auf einen ganz bestimmten request mit einem ganz bestimmten response antwortet. Falls ich dem request da noch was anhänge, kann es sein das ich nichts mehr bekomme. Allerdings ist die zweite Alternative wohl super. Aber ich dachte mit dem bytes at port habe ich genau dieses Verhalten! So wie ich Dichnun verstanden habe, muss ich den bytes at port entfernen und dem VISA lesen die genaue byte-Anzahl als Konstante spendieren Rolleyes?

Grüße, Thomas
' schrieb:Die Problematik bei mir ist, das er die Wartezeiten nicht einhält!!!
Das Timeout wird eingestellt im Visa-Konfigurations-VI, und da habe ich mich sowieso sehr gewundert, daß Du da gar keines hast. Du brauchst doch eine Vorgabe der Baudrate usw., ich frage mich, wieso Dein VI überhaupt funktionieren kann, wenn das fehlt.
So wie Du es machst ist es auch nicht schlecht, der einzige Nachteil ist nur, daß Du bei der Wartezeit eine Reserve einbeziehen mußt. D.h das Ganze dauert etwas länger als unbedingt naotwendig. Der Vorteil ist aber, daß es keinen Timeoutfehler geben kann, denn Du liest eben immer die Anzahl von Bytes, die nach der Wartezeit garantiert im Buffer sind - ob das der richtige, vollständige String ist, ist eine andere Frage.
Wenn die Gegenstelle ein von Dir nicht zu beeinflussendes Gerät ist und kein Abschlußzeichen beim Senden das Strings mitliefert, ist natürlich nichts zu machen.
Ich persönlich habe eine Allergie gegen Sequenztrukturen und versuche sie immer zu vermeiden. Bei Deinem VI würde ich es z.B so machen:
[attachment=15392]
Seiten: 1 2
Referenz-URLs