Messdatenaufbereitung

' schrieb:Wenn ich den Sensor mit dem Example File "Basic Serial write and read.vi" ansteuere bekomme ich als Antwort Daten im Hex-Format heraus. Diese würde ich nun gerne als normale Zahlen in einen Graphen überführen. Was gibt es da für Möglichkeiten?

Hier noch den Auszug der erhaltenen Hex-Daten

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

Ich gehe davon aus, dass die 7F7F die vor jedem Zahlenwert erscheint als synchronisierung des Sensors dienen. D.h. nur die folgenden vier Stellen geben den Messwert wieder

Vieleicht kann mir da jemand helfen.

Hier mal ein Vorschlag. Du musst dann halt noch selber nach dem 0D0A Code im String suchen. Das ist ein Carriage Line Feed, obwohl da wohl noch eine besondere Codierung sein wird denn 0D0A ist ja auch eine gültige 16 Bit Integer Zahl.

Die Daten scheinen bereits im LabVIEW bevorzugten Big Endian Format vorzuliegen und die 7F7F machen tatsächlich nicht so viel Sinn. Ich dachte erst dass es in Wirklichkeit eine 4 Byte Floating Point Zahl sein könnte aber da kommt man auf sinnlose Werte wenn man das so interpretiert.

   

Rolf Kalbermatter

Anzeige

Danke für eure Infos

Ich habe mal mit dem Hersteller de Sensors telefoniert. Er hat mir gesagt, dass alle wichtigen Daten um den Sensor anzusteuern im Datasheet unter den Punkten 2 und 3 entnommen werden können. Und somit die Ansteuernung des Sensors mit LabVIEW relativ einfach bewerkstelligt werden könne. Leider kann ich mit diesen Angaben nicht wirklich viel anfangen, da ich mit der Ansteuerung von Sensoren nicht viel Erfahrung hab.

Das Datasheet hab ich im Anhang angefügt. Vieleicht hat jemand ja schon etwas in dieser Richtung mit LabVIEW programmiert und kann mir weiterhelfen.

gruss danii


  Datasheet_mass_flow_meter_ASF1430_E.pdf (Größe: 300,24 KB / Downloads: 445)

' schrieb:Danke für eure Infos

Ich habe mal mit dem Hersteller de Sensors telefoniert. Er hat mir gesagt, dass alle wichtigen Daten um den Sensor anzusteuern im Datasheet unter den Punkten 2 und 3 entnommen werden können. Und somit die Ansteuernung des Sensors mit LabVIEW relativ einfach bewerkstelligt werden könne. Leider kann ich mit diesen Angaben nicht wirklich viel anfangen, da ich mit der Ansteuerung von Sensoren nicht viel Erfahrung hab.

Das Datasheet hab ich im Anhang angefügt. Vieleicht hat jemand ja schon etwas in dieser Richtung mit LabVIEW programmiert und kann mir weiterhelfen.

gruss danii

[attachment=44953:Datashee...SF1430_E.pdf]

Also das Ganze scheint ja ziemlich einfach. Zuerst mal wird der Sensor wohl beim Einschalten normalerweise automatisch beginnen um Daten zu spucken. Du wirst also zuerst mal nach dem Öffnen der Schnittstelle ein VISA Flush machen wollen. Danach musst Du die einkommenden Daten nach zwei aufeinanderfolgenden 7F Bytes absuchen müssen. Am einfachsten liest Du erst mal 4 Bytes ein und suchst dann mit Match Pattern und einem Pattern von "7F+" (suche nach einem oder mehr aufenanderfolgenden Bytes mit dem ASCII Code 0x7F) nach diesen Bytes. Danach schaust Du was die Länge des übriggebliebenen Strings am Ausgang "after substring" ist. Das sind null, eins oder zwei Byte. Dann liest Du nochmal '2 - diese Anzahl' Bytes und jetzt kannst Du immer vier Bytes lesen, wobei die ersten zwei jeweils 7F sind und die letzten zwei die 16 Bit binaire Zahl sind. Die Konvertierung dieser 16 Bit Integerzahl kannst Du jeweils mit dem Typecast wie in meinem vorigen Vorbild angegeben realisieren.

Wenn Du den Sensor umkonfigurieren willst musst Du erst einen einzelnen Character "s" schicken und dann jeweils die Kommandos die für Deine Konfiguration nötig sind. Alle Kommandos ausser das Stop Kommando "s" musst Du jeweils mit einem Carriage Return "r" oder Line Feed "n" abschliessen. Du kannst diese Character direkt in eine Stringkonstante einführen indem Du diese mit der rechten Maustaste anklickst und im Pop-up Menu die Option "-Codes Display" anwählst. Alternativ kannst Du auch die entsprechenden Konstanten aus der String Palette nehmen und mit Build String hintenanfügen. Nach jedem Kommando antwortet der Sensor mit eventuellen Daten und am Schluss ein "okr"
Am Ende der Konfiguration schickst Du das Kommando "gor" und der Sensor beginnt wieder mit Daten spucken.

Rolf Kalbermatter

' schrieb:z.B. so...

Mir sind die bisherigen Lösungen alle etwas zu umständlich
   

  Hex.vi (Größe: 9,85 KB / Downloads: 190)

' schrieb:Mir sind die bisherigen Lösungen alle etwas zu umständlich
[attachment=44962:Hex.png]
[attachment=44963:Hex.vi]

Das Beispiel würde funktionieren wenn denn die Daten im String so drin stehen würden. Aber das Stringkontrol des ursprünglichen Posters ist gesetzt um die binären Daten im Hex Code Display anzuzeigen. Damit geht Deine Lösung aber nicht.

Rolf Kalbermatter

@Lucki: Hi, Lucki, dein VI ist in diesem Fall nicht korrekt.
Die Darstellung des Übertragungsstrings im PDF stellt klar das, dass ein String der Art
7F 7F 7C 7F 7F 7F 7C 7F
hier als HEX-Codierung des Strings zu verstehen ist. Du müsstest deinen String im FP erst mal auf HEX-Anzeige umschalten und dann den String wandeln.
Außerdem stellen die 2 Datenbytes zwischen 7F & 7F genau das Binärmuster einer I16 Zahl dar, nicht einer Double.
Es müsste also folgendermaßen gewandelt werden:
   
Um aus diesen I16-Werten dann zu Temperaturen oder Massendurchflüssen zu kommen, muss noch durch 100 bzw. 70 geteilt werden.

@danii:
Ich muss sagen, die Anleitung des Protokolls und der Befehle ist eine der besseren Sorte. Wirklich gut zu verstehen.
Ich würde dir folgendes vorschlagen:
Mach dich erst mal mit Seite 6-8 vertraut.
Dann spiele erst mal mit dem Windows-Hyperterminal rum, baue eine Verbindung auf, schau dir die Meldungen deines Sensors an.
Dann kommt der nächste Schritt, Verbindung mit LabVIEW (hast du ja schon), vielleicht erst mal mit dem angesprochenen Bsps aus dem NI-Examplefinder, wenn du mehr spielen willst, nimm das hier:
http://www.LabVIEWforum.de/RS232-Terminal-t6239.html

Eine mögliche Umsetzung des Suchalgorithmus nach den Trennbytes könnte so aussehen:

  Hex2.vi (Größe: 14,88 KB / Downloads: 179)

   
(So, da kann Lucki noch was dran verbessern, wenn er will)

Gruß, Jens

Anzeige

' schrieb:(So, da kann Lucki noch was dran verbessern, wenn er will)

Ja selbstverständlich, Du kennst mich ja. Aber jetzt muß ich ins Bett, morgen früh raus und dann drei Tage nach München. Und danach ist das Thema mausetot...

@Lucki: Wer weiss, manchmal halten sich solche Threads länger als man denkt.

Gute Nacht und viel Spaß in München,

Jens

' schrieb:@Lucki: Wer weiss, manchmal halten sich solche Threads länger als man denkt.

Gute Nacht und viel Spaß in München,

Jens

Nix mit gute Nacht, das mußte noch geklärt werden. Ich gestehe, daß ich beratungsresitent bin. Ich halte nach wie vor den geposteten Hex-String für einen ASCII-String in Normaldarstellung und nicht für eine Sonderdarstellung in Hex, wie sie in LabVIEW mit der Anzeigeoption "Hex-Darstellung" möglich ist und worauf ihr euch alle geeinigt zu haben scheint. Also ich interpretiere die Daten schichtweg so, wie sie laut Manual übermittelt werden. Allerdings - und das konnte ich vor dem Lesen des Manuals nicht wissen - sind die Hexwerte als I16 und nicht als U16 (- oder double, was wertmäßig auf dasselbe (!) hinausläuft -) zu interpretieren.
Außerden gehe ich jetzt davon aus, daß die ersten beiden Bytes keine Daten sind.
Damit ändert sich das VI zur Erzeugung der Graphik zwar geringfügig, ist aber immer noch genau so einfach:
   

  Hex3.vi (Größe: 9,5 KB / Downloads: 171)

@Lucki: Schau mal hier:
   
Wenn 0x7F ein Byte sein soll, dann muss es der HEX-Code des Byte sein.
Ansonsten wären ja auch nicht 2 übertragene Bytes die Integer-Zahl, hierfür brauchst du 4 Byte.

Nochmals, gute Nacht,

Jens