LabVIEWForum.de - Messdatenaufbereitung

LabVIEWForum.de

Normale Version: Messdatenaufbereitung
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2 3 4 5
' schrieb:Ist es möglich das StringVisa1.vi in LV 8.5 zu bekommen. Es würde mich interessieren. wie die Aufgabe gelöst wurde.
Kein Problem, habe den Beitrag oben editiert und die beiden VIs gegen V85 ausgetauscht.
Gruß Ludwig
Hallo

Ich hab nun ein Vi erstellt um den Sensor anzusteuern und seine Daten auszulesen.
Nun möchte gerne die Commands nicht selbst eintippen müssen, sonder rein über Impulse, also mittels einer Tastenbetätigung schicken. Ich hab versucht eine solche Betätigung einzubringen, jedoch funktioniert sie nicht reibungslos. Der Sensor reagiert nur teilweise auf die Commands. Kann es sein, dass ich bei meinem Programm noch etwas grundlegendes vergessen hab?

Lv85_img[attachment=17387]

Gruss danii
Hallo

Es hat sich erledigt, ich habs hingekriegt.

gruss danii
Hallo

Ich da nochmals ein Problem.

Die Daten kommen nicht immer gleich vom Sensor. D.h. wenn sie in der normalen Form (676F 0D0A 7F7F FF04 7F7F FF1A 7F7F FFA9 7F7F FFEF 7F7F 0011 7F7F 0033 7F7F 010A 7F7F 00B3 7F7F FFEE 7F7F FFEE 7F7F FFEF 7F7F FFEF 7F7F FFEE 7F7F FE76 7F7F FF1A 7F7F FFBA 7F7F FFEE 7F7F 0011 7F7F 0044) kommen,kann ich sie problemlos lesen.

Nun kommt es aber vor, dass die Daten so (7FFF 047F 7FFF 1A7F 7FFF A97F 7FFF EF7F 7F00 117F 7F00 337F 7F01 usw.) kommen, dann krieg ich nur noch komische Werte raus. Das Problem wird wahrscheinlich sein, dass die 7F7F nicht immer in der gleichen vierer Gruppe stehen. Was kann ich da tun um trotzdem die Werte lesen zu können?

Für die Daten auswertung habe ich das Hex2.vi verwendet.

[attachment=17394] LV8.5

Gruss danii
Das ist doch mein VI. Funktioniert doch...

Gruß, Jens
' schrieb:Das ist doch mein VI. Funktioniert doch...

Gruß, Jens
Genau, und mein VI funktioniert auch:
[attachment=17405]
Du kannst sogar in beiden VIs bei den Strings beliebigen Datenmüll voranstellen, mit gerader oder ungerader Anzahl von Bytes, es funktioniert trotzdem.
Lediglich der Vorschlag von rolfk kann so nicht funktionieren, da dort von Anfang an paarweiese statt byteweise eingelesen wird. Wenn man mit da mit dem falschen byte beginnt, kommt es nie zur Synchronisation. (Aber hier mildernde Umstände: das Thema war ja nicht die Synchronisation, sondern die Umrechnung Bytes in Zahlenwerte)
Ja das ist dein Vi. Wenn ich es alleine benutze funktioniert es ohne probleme.

Nun ist es aber so, dass ich es in ein anderes Vi implementiert habe. Dort ist das Ziel mehrere Messungen nacheinander durchführen zu können. Wenn ich also mehrmals hintereinander Starte und Stope, krieg ich komische werte raus. Ich denke das Vi hat probleme mit den Start und Stop Commands. Es gibt dann komische byte Paarungen die, die Auswertung beeinträchtigen.

Hier ein Auszug aus den erhaltenen Werten
676F 0D0A 7F7F 0000 7F7F 0011 7F7F 0000 7F7F 0000 7F7F 0000 7F7F 0000 7F7F 0000 7F7F 0000 7F7F 0011 7F7F 0000 7F7F 0000 7F7F 0000 7F7F FFEF 730D 0A4F 4B0D 0A67 6F0D 0A7F 7F00 007F 7F00 007F 7F00 007F 7F00 007F 7F00 117F 7F00 007F 7FFF EF7F 7F00 007F 7F00 007F 7F00 117F 7F00 007F 7F00 007F 7F00 007F 7F00 0073 0D0A 4F4B 0D0A 676F 0D0A 7F7F 0000 7F7F 0000 7F7F 0000 7F7F 0000 7F7F 0000 7F7F 0000 7F7F 0011 7F7F 0000 7F7F 0000 7F7F 0000 7F7F 0000 7F7F 0011 7F7F 0000 7F7F 0000 7F7F 0000 730D 0A4F 4B0D 0A67 6F0D 0A7F 7FFF EF7F 7F00 007F 7F00 117F 7F00 007F 7F00 007F 7F00 007F 7F00 117F 7F00 007F 7F00 007F 7F00 007F 7F00 117F 7F00 007F 7F00 007F 7F00 0073 0D0A 4F4B 0D0A

[attachment=17406] LV8.5

Ich versuche jetzt mal die einzelnen Messabschnitte einzeln umwandeln zu können. Vieleicht klappt es dann.
' schrieb:Genau, und mein VI funktioniert auch:
[attachment=45146:StringVisa.png]
Du kannst sogar in beiden VIs bei den Strings beliebigen Datenmüll voranstellen, mit gerader oder ungerader Anzahl von Bytes, es funktioniert trotzdem.
Lediglich der Vorschlag von rolfk kann so nicht funktionieren, da dort von Anfang an paarweiese statt byteweise eingelesen wird. Wenn man mit da mit dem falschen byte beginnt, kommt es nie zur Synchronisation. (Aber hier mildernde Umstände: das Thema war ja nicht die Synchronisation, sondern die Umrechnung Bytes in Zahlenwerte)

:bahn:Das letzte VI von mir in diesem Thread macht ja gerade Synchronisation am Anfang. Das hat zwar als Folge dass der erste gültige Wert immer weggeschmissen wird (könnte mit etwas mehr Aufwand auch noch vermieden werden) aber solange innerhalb eines Datanblocks danach kein Müll ist funktioniert das perfekt. Ich nicht begreifen!!

Natürlich muss man nach einer "Stop,{Kommandos},Start" Sequenz wohl wieder neu snchronisieren wenn man denn das ganze Kommando response Feedback nicht auch noch perfekt abhandelt.

Rolf Kalbermatter
Wäre es denn auch möglich basierend auf dem Hex.vi zusätzlich noch die Start & Stop Werte zu dedektieren und raus zu filtern?
' schrieb:Das letzte VI von mir in diesem Thread macht ja gerade Synchronisation am Anfang. Das hat zwar als Folge dass der erste gültige Wert immer weggeschmissen wird (könnte mit etwas mehr Aufwand auch noch vermieden werden) aber solange innerhalb eines Datanblocks danach kein Müll ist funktioniert das perfekt. Ich nicht begreifen!!

Entschuldigung, ich hatte nur das erste kleine Beispiel im Auge.
Das zweite habe ich mir jetzt mal angeschaut, und da sind mir bei der Synchronisation am Anfang auch gleich zwei Ungereimtheiten aufgefallen (Aber wie gesagt, bezog sich die Anfrage ja gar nicht auf Synchronisation mit den beiden 7F 7F Bytes. Also Perfektion war hier gar nicht gefragt)
Hier der BD-Ausschnitt:

[attachment=17418]
Damit meine ich

1. Angenommen, die (noch nicht synchronisierte) Bytefolge ist am Anfang 7F 00 00 7F. Dann bleiben am Ausgang des "VI Muster suchen" die 3 Bytes 00 00 7F übrig. Die nachfolgende Subtraktion 2-3 ergibt -1. Und das soll doch wohl bestimmt nicht als Byteanzahl vom nachfolgenden VI gelesen werden.
2. Kleiner Flüchtigkeitsfehler: Bei "regulär expression" hätte die code - Darstellung gewählt werden müssen. So wie hier in der Normalansicht wird nicht das Byte 0x7F, sondern es wird die 3 char lange Zeichenkette "7F" gesucht.

Der Aussage, daß das richtige Lesen ab erstem Wert nur mit mehr Auswand zu erreiches ist, stimme ich nicht zu. Mit byteweisen Einlesen und Bytebehandlung einer einer kleinen State machine, die wegen ihrer Winzigkeit kaum diesen Namen verdient, läßt sich das Problem sehr einfach lösen.
Seiten: 1 2 3 4 5
Referenz-URLs