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!
Mein Entladegerät sendet ca. alle 500ms ein Datentelegramm mit 5 wichtigen Parametern. Jeder dieser Parameter ist zum Übertragen in High- und Low-Byte aufgeteilt. Diese stellen vorzeichenbehaftete Integer Werte dar.
Es erscheinen also 10 Bytes = 80 bit mit jedem Datentelegramm an meiner seriellen Schnittstelle (getestet mit Monitorprogramm HTerm). Als Startzeichen wird 0x02 (STX) gesendet, und als Stopzeichen 0x03 (ETX): Der zwischen diesen Zeichen befindliche Code interessiert also.
haben und in einem Array speichern (dann als .txt bzw. excel-file). Dieses Array soll also die 5 Parameter als Gleitkommazahl darstellen, evtl. mit einem Zeitstempel versehen werden, und mit jedem neuen Telegramm nach unten wachsen.
Leider habe ich sehr wenig Kenntnisse über LabVIEW, deshalb hoffe ich hier eine Hilfestellung zu bekommen. Auch ein Tipp für die Vorgehensweise würde mich schon freuen. =)
Ich verwende LabVIEW 9.0 (32bit). Anbei noch eine Übersicht zu dem Datentelegramm.
Zunächst Vielen Dank für die rasche Antwort, GerdW!
Ich denke ich verstehe noch nicht so ganz, inwieweit ich deinen Tipp verwenden kann.
Ausgehend von einem gefundenen Beispiel habe ich mir ein Programm gebastelt, welches mir eine Anzahl von Bytes von der seriellen Schnittstelle mit entsprechender Konfiguration ausliest. (Anhang)
Nun habe ich mittels einer Simulation versucht zu erkennen, wie die Daten dann vorliegen. Allerdings gab es ein Problem, als ich mit dem Programm HTerm Daten an die den COM1-Port gesendet habe, da LabVIEW ebenfalls auf diesen zugreifen muss. (Error wegen zwei Zugriffen)
Gibt es Möglichkeiten, Bits an einer seriellen Schnittstelle zu simulieren, um deren Darstellung dann einschätzen zu können?
Oder kann mir jemand sagen, wie ich die Daten so aufbereiten kann, dass jeweils 2 gelesene Bytes (High/Lowbyte) als eine Gleitkommazahl dargestellt werden? Eigentlich müsste ich doch nur innerhalt von "VISA: Lesen" am Lesepuffer die Daten umwandeln, oder?
Was dann noch fehlen würde, wäre die Aufbereitung der 5 Parameter in z.B. ein Array, sowie das Auffüllen des Arrays.
Vielen Dank & liebe Grüße,
Eddi
11.11.2010, 09:38 (Dieser Beitrag wurde zuletzt bearbeitet: 11.11.2010 09:39 von Lucki.)
Antwort zum Posting #1:
Das Telegramm überträgt vorzeichenbehaftete Interzahlen im Format I16. 2-Byte-Geitkommazahlen gibt es gar nicht, zumindest nicht genormt. Man kann natürlich aus der Integerzahl durch z.B Division mit 100 eine Fixkommazahl mit 2 Stellen nach dem Komma machen - wahrscheinlich meinst Du so etwas in der Richtung, wenn Du von Gleitkomma sprichst.
Der Vorschlag von Gerd funktioniert mit I16 (vorzeichenbehaftet) nicht, und außerdem geht das viel einfacher mit einer einzigen Funktion:
dein VI habe ich bereits nachgebaut, weiß aber noch nicht wie genau ich es nutzen kann.
Ich würde gern z.B. durch eine For-Schleife gesteuert n-mal die genannten 16 bits von COM1 lesen, die mit high-und lowbyte eine Zahl darstellen (signed integer 16bit). Anschließend würde ich gerne die entsprechende Zahl angezeigt bekommen, sowie in weiteren Array-Feldern die nächsten konvertierten Zahl. Eventuell müsste ich die Zahl noch durch einen Faktor teilen, da die Werte zwischen 0,0 und 20,0 liegen müssten.
Dies würde mir sehr weiterhelfen, denn bisher habe ich leider nichts brauchbares gefunden.
Vielen Dank für eure Mühe, ich weiß das echt zu schätzen! =)
Gruß Eddi
12.11.2010, 08:33 (Dieser Beitrag wurde zuletzt bearbeitet: 15.11.2010 12:51 von Lucki.)
Es gibt da noch ein ganz anderes Problem, und das scheint Dir entgangen zu sein. Damit Datenbytes nicht mit Steuerzeichen <STX> und <ETX> verwechselt werden können, hat man sich im Datentelegramm (Siehe dein Bild) etwas Schlaues ausgedacht. Der eigentliches Datenblock (10bytes) kann also auch länger sein als 10 Bytes, auch wenn letztlich nur 10 Bytes an Daten übertragen werden sollen. Das wieder zu dekodieren auf die echten 10 Bytes muß die erste Maßnahme nach dem Datenempfang sein.
@ Lucki: daran habe ich zwar gedacht, wollte es aber zunächst unberücksichtigt lassen.
Da als Stoppbit immer ETX (0x03) gesendet wird, könnte man das als Schleifenabbruchbedingung verwenden bzw. als Bedingung für eine neue Zeile in einem Excel-Sheet.
Worum es mir in Moment geht ist, wie ich eine definierte Zahl von Bits der seriellen Schnittstelle auslesen (z.B. 8 oder 16bits) und in verschiedenen Datenformaten darstellen kann, oder aber auch erst mal binärkodiert. Als String habe ich es bereits hinbekommen (seltsame Zeichen/Ascii-Code?!?), aber als I16 z.B. noch nicht.
Über eine Antwort würde ich mich freuen, ich komme wirklich einfach nicht voran.
' schrieb:@ Lucki: daran habe ich zwar gedacht, wollte es aber zunächst unberücksichtigt lassen.
Da als Stoppbit immer ETX (0x03) gesendet wird, könnte man das als Schleifenabbruchbedingung verwenden bzw. als Bedingung für eine neue Zeile in einem Excel-Sheet.
Genau das geht eben nicht. Wenn z.B. ein gesendete I16-Zahl gleich drei ist ( - allgemein immer wenn das High- oder Low-Byte gleich 3 ist - ) dann führt das doch zum vorzeitigen Abbruch der Schleife.
Zitat:Worum es mir in Moment geht ist, wie ich eine definierte Zahl von Bits der seriellen Schnittstelle auslesen (z.B. 8 oder 16bits) und in verschiedenen Datenformaten darstellen kann, oder aber auch erst mal binärkodiert. Als String habe ich es bereits hinbekommen (seltsame Zeichen/Ascii-Code?!?), aber als I16 z.B. noch nicht.
Das war Deine usrprüngliche Frage, und GerdW und ich hatten sie beantwortet. Waren diese Antworten wirklich solcher Schrott, daß Du jetzt wieder fragen mußt? Was ist da schief gelaufen?
' schrieb:Waren diese Antworten wirklich solcher Schrott, daß Du jetzt wieder fragen mußt? Was ist da schief gelaufen?
eure Antworten waren natürlich KEIN Schrott (ich bin dankbar für jede Antwort), nur sagte ich bereits, dass ich nicht weiß wie ich diese nutzen kann bzw. wenn ich sie einbaue, kommen unlogische Werte heraus. An dieser Stelle hängt es bei mir auch leider noch.
Jetzt eine Frage für's Verständnis:
' schrieb:Genau das geht eben nicht. Wenn z.B. ein gesendete I16-Zahl gleich drei ist ( - allgemein immer wenn das High- oder Low-Byte gleich 3 ist - ) dann führt das doch zum vorzeitigen Abbruch der Schleife.
Ich verstehe das im obersten Beitrag beschriebenen Bild des Telegramms so, dass wenn ein 0x02 oder 0x03 kommen WÜRDE, stattdessen ein 0x05 und 0x12 bzw. 0x05 und 0x13 gesenden werden würde. Die Anzahl der Bytes könnte sich also erhöhen, jedoch könnte man 0x03 sehr wohl als Abbruch einer Schleife definieren, oder sehe ich das falsch?
' schrieb:Ich verstehe das im obersten Beitrag beschriebenen Bild des Telegramms so, dass wenn ein 0x02 oder 0x03 kommen WÜRDE, stattdessen ein 0x05 und 0x12 bzw. 0x05 und 0x13 gesenden werden würde. Die Anzahl der Bytes könnte sich also erhöhen, jedoch könnte man 0x03 sehr wohl als Abbruch einer Schleife definieren, oder sehe ich das falsch?
Hast Recht, habe mich falsch ausgedrückt, 03 läßt sich direkt als TerminalChar verwenden.
Das Kodieren/Dekodieren könnte man so machen (Leider funktionierte des herunterkonvertieren auf V9 nicht bei mir) Dekoder.vi (Größe: 13,9 KB / Downloads: 256)
/
Auswertung eines Datentelegramms
