Fortlaufender Datenstrom an RS-232: Daten extrahieren

Hi,
ich erfasse mit bis zu 115,2kBaud Messwerte von einem Lasermicrometer OptoControl2500 von MicroEpsilon. Das Gerät sendet einen fortlaufenden Datenstrom mit einer Paketgröße von drei Byte (Low, Mid, High). Im Lowbyte werden die Bits 0-5, im Midbyte die Bits 0-5 und im Highbyte (im meinem speziellen Fall) die Bits 0-3 als Nutzdaten gesendet, die beiden höchstwertigen Bits pro Byte identifizieren die Position des Bytes im Paket (Low: 00 / Mid: 01 / High: 10). Im Anhang ein Auszug aus dem Handbuch, der den Aufbau der gesendeten Daten beschreibt.

Ich habe so den Eindruck, dass die Methode, wie ich das bisher lese (mit "Bytes at serial port") und extrahiere - ich sag's mal vorsichtig - nur sub-optimal ist... Hat jemand Verbesserungsvorschläge? Das Problem an der ganzen Sache ist u.a., dass kein Trennzeichen zwischen den Paketen versendet wird. Wenn man ein solches hätte, könnte man im Datenstrom danach suchen und dann die folgenden drei Bytes rausziehen und wandeln. Ohne Trennzeichen besteht bei meiner Variante aber immer die Gefahr, dass man im Eingangspuffer kein vielfaches von drei (Bytes pro Paket) hat, d.h. so wie im angehängten Beispiel (mit willkürlich aus dem Datenstrom rauskopierten Daten) unterschiedlich viele Bytes (siehe im Beispiel: 63:61:60) hat, und so eine "Verschiebung" der Messwerte hat...Da die Messwerte nur im µ-Bereich schwanken, ist ein Fehler zwar nur schwer wirklich zu sehen, aber...

Hat jemand einen Vorschlag, wie man das optimieren könnte?

   

  test_optocontrol.vi (Größe: 26,31 KB / Downloads: 379)


Gruß
Achim

Anzeige

So wie ich es verstanden habe sollen die Bits:

00 im L-Byte
01 im M-Byte
und
10 im H-Byte

der Synchronisierung dienen.

Also musst du drei Bytes auslesen und diese Bits vergleichen. Wenn die Anordnung stimmt, dann bist du schon Synchronisiert. Ab dann kannst du normal lesen und aber diese Bits immer wieder vergleichen. Wenn die Bits nicht mehr stimmen, musst du dich neu synchronisieren.

Gruß

Ich hab mir das VI jetzt noch nicht angekuckt, würde aber vorschlagen: In manuellen Ringpuffer einlesen mittels VISA-Read. Immer wenn min. drei drinnenstehen, Ringpuffer auslesen - und zwar Zeichenweise: Erstes muss sein '00xx.xxxx', zweites '01xx.xxxx', drittes '10xx.xxxx'. Sind drei richtige da, Daten übernehmen. Fehlt eins, abbrechen und von vorne anfangen. Der Ringpuffer muss lediglich groß genug sein und das Auslesen etc. muss schneller gehen als das Daten reinschreiben. Dann sollte das funktionieren. Der Ringpuffer ist ein festes Array, für das es noch einen Schreibzeiger (Index), einen Lesezeiger und ggf. einen Anzahlzähler gibt. Alle drei/vier liegen letzlich in einem Schieberegister einer Whileschleife. Wählt man die Puffergröße günstig - Potenzen von 2 - kann man die Zeiger schneller manupulieren.

Vielleicht.

-immer Byteweise auslesen.

-Die ersten beiden Bits anschauen und der Zahl entsprechend in ein Array schreiben. Aber in zelle 2 erst reinschreiben wenn in Zelle 1 was drinsteht, ansonsten ab in den Müll. In Zelle 1 Erst reinschreiben wenn in Zelle 0 was drin steht, ansonsten ab in den Müll.

- Wenn in alle Zellen ein Wert drinsteht das Ganze Array das ja dann aus drei Zellen besteht in ne Queue schreiben und das Empfansarray wieder löschen.

- Was und wo du dann mit der Queue anstellst ist dann das nächste theme.

so würd ich das mal testen.

Wenn das jetzt nicht besonders gut erklärt ist, dann sags, dann bau ich dir ein Beispiel.

Grüße
Achimedes

Ein weiteres Muster.

Hi,

danke fürs Feedback, ich mach's jetzt so:


  ME_UmrechnungReadBuffer.vi (Größe: 44,06 KB / Downloads: 343)


@IchSelbst: Ich hab mal eine Menge(!) Daten als Eingangsstring verwendet, um eine zeitliche Tendenz zwischen deiner und meiner Variante zu sehen...das bleibt sich nahezu gleich...Eine sichtbare Verzögerung ergibt sich durch die Umrechnung der Rohdaten in den Messwert, aber das ist halt nicht zu vermeiden!

Gruß
Achim

Anzeige

' schrieb:Hi,

danke fürs Feedback, ich mach's jetzt so:

[attachment=38695:ME_Umrec...adBuffer.vi]

@IchSelbst: Ich hab mal eine Menge(!) Daten als Eingangsstring verwendet, um eine zeitliche Tendenz zwischen deiner und meiner Variante zu sehen...das bleibt sich nahezu gleich...Eine sichtbare Verzögerung ergibt sich durch die Umrechnung der Rohdaten in den Messwert, aber das ist halt nicht zu vermeiden!

Gruß
Achim

Hi Achim,

Ich sitze momentan an einer ähnlichen Aufgabe, habe aber erst seit einer Woche mit LabVIEW zu tun und deshalb noch nicht so viel Ahnung von der ganzen Materie.
Könntest du mir mal etwas genauer erklären was du da mit dem Eingangsstring anstellst (bzw. wie die Überprüfung auf L- M- oder H- Byte genau funktioniert)

mfg.
Maddin

' schrieb:danke fürs Feedback, ich mach's jetzt so:

Hast du mal folgendes überprüft: In deinem zuerst geposteten VI (das was ich erweitert habe) hast du Daten (die im String), die nicht konsistent sind. D.h. da fehlen Bytes in der Reihenfolge (mindestens einmal das Hi-Byte)). Und das nicht am Anfang, sondern in der Mitte. Durch das Verfahren der Sortierung der Bytes mit der selben Kennung kommst es automatich zu falschen Gesamtdaten, wenn irgendwo eins in der Reihenfolge fehlt. In deinem zweiten Posting hat das Low-Array 63 Werte, das Mid-Array 61 und das Hi-Array 60.

Dieser Effekt mag für manche Applikationen irrelevant sein - aber immerhin.

' schrieb:Könntest du mir mal etwas genauer erklären was du da mit dem Eingangsstring anstellst (bzw. wie die Überprüfung auf L- M- oder H- Byte genau funktioniert)

Im VI steht doch alles drin...genauer ist's nicht zu erklären! Die wichtigsten Infos stehen in meinem ersten Post! Die gesendeten Daten beinhalten die Info (Bit 6+7), an welche Stelle im Messwert-Paket sie gehören, und das wird mit der Maskierung mit "11000000" überprüft. Entsprechend dem Ergebnis wird dann sortiert.

Wenn man zu einem willkürlichen Zeitpunkt anfängt zu lesen, kann es aber vorkommen, dass man nicht von Beginn eines Datenpakets (00xxxxxx = Low) liest, sondern erst ab dem zweiten (01xxxxxx = Mid) oder ab dem dritten Byte (10xxxxxx = High). Unvollständige Pakete müssen aber abgeschnitten werden, damit beim sortieren nicht Elemente eines Pakets mit Elementen eines anderen Pakets vermischt werden. Danach sollten im Eingangspuffer immer Bytes in der richtigen Reihenfolge stehen...

@IchSelbst:
Die Inkonsistenz der Bytes hab ich gesehen, konnte sie mir bisher aber nur durch einen "rauskopier-Fehler" erklären...ich guck's mir aber noch mal an. Wie oben gesagt, kann es aber eigentlich außer am Anfang nicht vorkommen, da das Lasermicrometer immer komplette Pakete schickt und diese dann auch komplett im Buffer stehen sollten. Wenn man unvollständige Pakete am Ende des Puffers hat, sollte das nichts ausmachen, das die "Extraktionsschleife" ja nur so oft läuft, wie das kleinste angeschlossene Array Elemente hat. Den Rest des unvollständigen Datenpakets liest man dann ja beim nächsten Mal aus und durch die Überprüfung wird das dann wieder abgeschnitten. Man verliert so zwar zwischendrin ein Paket, aber das ist IMHO zu vernachlässigen. Stimmst du mir zu?

Gruß
Achim

' schrieb:Die Inkonsistenz der Bytes hab ich gesehen, konnte sie mir bisher aber nur durch einen "rauskopier-Fehler" erklären...

Machst du Fehler in deiner Software (ich nicht )? Nee. Das Byte fehlt, weil es auf der seriellen Leitung kaputt gegangen ist. Und das passiert prinzipiell überall innerhalb des Datenstreams.

Zitat:Wie oben gesagt, kann es aber eigentlich außer am Anfang nicht vorkommen, da das Lasermicrometer immer komplette Pakete schickt und diese dann auch komplett im Buffer stehen sollten.

Eben: Sollten. Zwischen Senden und Empfangen liegt aber die Strecke - und die ist fehlerbehaftet. Deswegen muss ja eine Sicherung gemacht werden.

Zitat:Wenn man unvollständige Pakete am Ende des Puffers hat

Aus datentechnischer Sicht (bezogen auf die Applikation) ist ein Datenaussetzter eines kompletten (!) Paketes vernachlässigbar. Ob das am Anfang, in der Mitte oder am Ende passiert ist dabei egal.

Zitat:Stimmst du mir zu?

Im allgemeinen Ja. Aber:

Überlege folgnedes:

Normalerweise sieht der Datenstream wie folgt aus:

H1 H2 H3 H4 H5 H6 H7
M1 M2 M3 M4 M5 M6 M7
L1 L2 L3 L4 L5 L6 L7

Nun fehle mitten im String - warum auch immer - ein Mid-Byte:

H1 H2 H3 H4 H5 H6 H7
M1 M2 M4 M5 M6 M7
L1 L2 L3 L4 L5 L6 L7

Ersichtlich ist jedenfalls, dass der Wert 3 (H3M3L3) jetzt plötzlich H3M4L3 heißt. Wenn ich richtig überlegt habe, könnte hier eine Ungenauigkeit von L-Max auftreten. Für alle nachfolgenden Werte gilt eine analoge Überlegung. Stimmst du mir diesem Effekt zu?

In wie weit dieser Effekt die (ich sag mal allgemein) Applikation beeinflusst respektive deren Daten verfälscht muss man erst noch verifizieren. Ist die Streuung der Werte nicht allzugroß und die Dynamik des Signals eher langsam (in bezug auf die Baudrate) könnte dieser Effekt vernachlässig werden.