Serielle Komunikation mit Mikrocontroller

' schrieb:Ich habe bald die Aufgabe mit einer seriellen Schnittstelle Daten zu übertragen, die im Hex-Format vorliegen.

So ausgedrückt hast du aber gar keine Probleme. Wenn die Daten bereits vorliegen, kannst du sie ohne weiteres übertragen. Liegen sie aber (wie es sich eigenlich gehört) als Binär (z.B. ByteArray, Stream) vor, dann musst du eine Konvertierung machen.

Zitat:Reicht es da nicht, wenn ich in LabVIEW die Hex-Darstellung bei meinem "String Control" einstelle und das dann über "VISA Write" an den Controller rüberschicke?

Die Darstellung im String-Control macht nichts weiter als eine Konvertierung von Binär nach HEX. Du siehst also zwei Zeichen anstelle von nur einem. Die Frage ist nur, ob die Darstellung übertragen wird oder der Wert - ich Tippe auf Wert.

So schwierig ist die Wandlung von Binär nach Hex auch nicht: (Im schlimmsten Falle) Schleife über Byte-Array mit Befehl "Formatiere in String" mit Formatierung "%2.2x".

Nachtrag:

Zitat:Wenn ich da jede einzelne Hex-Ziffer in Ascii umwandeln muss,

Eine Hex-Ziffer selbst ist bereits ASCII, da musst du nichts mehr wandeln.

Wenn du die Daten als Bytesarray vorliegen hast, dann musst du quasi mittels %2.2x konvertieren. Das Ergebnis ist quasi ASCII. Hast du bereits "Hex-Darstellung" vorliegen, so ist das schon ASCII und du musst nur noch übertragen.

So, jetzt mal mit Zahlenwerten.
Den Controller, den ich ansteuere erkennt z.B. 21 01 20 04 44 4C 34 38 00 (HEX).
Das will ich ihm jetzt mit LabVIEW über die RS 232 schicken. Es gibt das Beispiel aus dem Example-Finder für die serielle Übertragung. Was schreibe ich dann in dem Fall in VISA-Write?
Dann wird es noch klarer.

Gruß Markus

' schrieb:So ausgedrückt hast du aber gar keine Probleme. Wenn die Daten bereits vorliegen, kannst du sie ohne weiteres übertragen. Liegen sie aber (wie es sich eigenlich gehört) als Binär (z.B. ByteArray, Stream) vor, dann musst du eine Konvertierung machen.

Die Darstellung im String-Control macht nichts weiter als eine Konvertierung von Binär nach HEX. Du siehst also zwei Zeichen anstelle von nur einem. Die Frage ist nur, ob die Darstellung übertragen wird oder der Wert - ich Tippe auf Wert.

So schwierig ist die Wandlung von Binär nach Hex auch nicht: (Im schlimmsten Falle) Schleife über Byte-Array mit Befehl "Formatiere in String" mit Formatierung "%2.2x".

Nachtrag:
Eine Hex-Ziffer selbst ist bereits ASCII, da musst du nichts mehr wandeln.

Wenn du die Daten als Bytesarray vorliegen hast, dann musst du quasi mittels %2.2x konvertieren. Das Ergebnis ist quasi ASCII. Hast du bereits "Hex-Darstellung" vorliegen, so ist das schon ASCII und du musst nur noch übertragen.

' schrieb:Den Controller, den ich ansteuere erkennt z.B. 21 01 20 04 44 4C 34 38 00 (HEX).
Das will ich ihm jetzt mit LabVIEW über die RS 232 schicken. Es gibt das Beispiel aus dem Example-Finder für die serielle Übertragung. Was schreibe ich dann in dem Fall in VISA-Write?

Wenn du genau dieses übertragen willst, so wie es da steht - also mit den Spaces zwischen den Zahlen - dann füllst du einen String mit dem Text "21 01 20 04 44 4C 34 38 00" und gibst diesen String auf das VI. Ohne Space sieht der String dann so aus: "21012004444C343800". (Übrigens: In ASCII sähe das möglicherweise so aus: !<SOE>SPACE<EOT>DL48<NUL>) Was im String steht, kommt dann auf der Gegenseite genauso lesbar wieder heraus - also "2", "1", " ", "0" usw.

Ein Beispiel in LV kann ich dir jetzt nicht machen, da ich hier kein LV auf dem Rechner habe.

Also dann klappt es einfach, einen String anzuschließen, ohne davor irgendwo einzustellen, dass es HEX ist?
Dann ist ja alles klar und doch nicht so kompliziert, wie es sich angehört hatte.
Vielen Dank für Deine Hilfe.

Gruß Markus

' schrieb:Wenn du genau dieses übertragen willst, so wie es da steht - also mit den Spaces zwischen den Zahlen - dann füllst du einen String mit dem Text "21 01 20 04 44 4C 34 38 00" und gibst diesen String auf das VI. Ohne Space sieht der String dann so aus: "21012004444C343800". (Übrigens: In ASCII sähe das möglicherweise so aus: !<SOE>SPACE<EOT>DL48<NUL>) Was im String steht, kommt dann auf der Gegenseite genauso lesbar wieder heraus - also "2", "1", " ", "0" usw.

Ein Beispiel in LV kann ich dir jetzt nicht machen, da ich hier kein LV auf dem Rechner habe.

' schrieb:Also dann klappt es einfach, einen String anzuschließen, ohne davor irgendwo einzustellen, dass es HEX ist?
Dann ist ja alles klar und doch nicht so kompliziert, wie es sich angehört hatte.

Langsam, langsam, langsam.

Wie kommen denn die Daten in den String rein? Es besteht ein Unterschied zwischen der Anzeige des Stringinhaltes im Control und dem Inhalt selbst. Übertragen wird der Stringinhalt, nicht die Darstellung. Nur wenn "normale Darstellung" gewählt ist und du dann die HEX-Darstellung siehst, dann ist es das, was du willst.

Ich mach' dir heute Abend mal ein Beispiel.

' schrieb:Langsam, langsam, langsam.

Nur wenn "normale Darstellung" gewählt ist und du dann die HEX-Darstellung siehst, dann ist es das, was du willst.

Ich mach' dir heute Abend mal ein Beispiel.

So habe ich es auch verstanden. Aber ein Beispiel wäre auch nicht schlecht, falls auch mal jemand anders vor dem "Problem" steht.

Gruß Markus

Anzeige

' schrieb:Ich mach' dir heute Abend mal ein Beispiel.

Es ist zwar nicht ganz so geworden wie ich es mir gedacht hab - geht aber auch.

Danke. Ich habe sogar halbwegs durchgeblickt.
Was ich nicht ganz verstehe, ist, ob das mit dem STX, Trenner,... immer benötigt wird. Weil unsere Microcontroller haben ein eigenes, nämlich folgendes Protokoll.
Funktionsfeld-Zählfeld-Sicherungsfeld-Längenfeld-Datenfeld-Sicherungsfeld (F Z S N D D D ..... D S)
Da müsste es doch reichen wenn ich die jeweiligen Hexwerte für die einzelnen Felder rüberschicke. Trenner wüsste ich jetzt nicht, ob es die auch gibt.

Gruß Markus

' schrieb:Es ist zwar nicht ganz so geworden wie ich es mir gedacht hab - geht aber auch.

' schrieb:Was ich nicht ganz verstehe, ist, ob das mit dem STX, Trenner,... immer benötigt wird. Weil unsere Microcontroller haben ein eigenes, nämlich folgendes Protokoll.
Funktionsfeld-Zählfeld-Sicherungsfeld-Längenfeld-Datenfeld-Sicherungsfeld (F Z S N D D D ..... D S)
Da müsste es doch reichen wenn ich die jeweiligen Hexwerte für die einzelnen Felder rüberschicke. Trenner wüsste ich jetzt nicht, ob es die auch gibt.

Wichtig ist nicht, wie das Protokoll im speziellen aussieht (ob das Trenner drinnen sind oder nicht), sondern dass es eine "konstante Struktur" hat - eben z.B. so wie du beschrieben hast. Ohne "Konstante Struktur" müsstest du ggf. viele kleine Unterprogramme machen, eben für jede Struktur eines. Und bei vielem ist eines dabei, was du vergessen hast. Bei "Konstanter Struktur" kannst du ein Unterprogramm machen, das alle möglichen Datensätze generieren kann. Im übrigen kann auch ein in der Länge variables Datenfeld unter "konstant" fallen: Man übergibt als Parameter ein Array mit variabler Länge. Das eine Unterprogramm muss dann nur eben die Anzahl der Arrayfelder in den DÜ-Frame aufnehmen.

Vielen Dank für Deine Hilfe und Geduld! Das habe ich jetzt soweit verstanden.
Wenn ich dann Fragen habe, wenn ich am Umsetzen bin, dann komme ich wieder auf Dich zu, wenn Du nichts dagegen hast.

Gruß Markus

' schrieb:Wichtig ist nicht, wie das Protokoll im speziellen aussieht (ob das Trenner drinnen sind oder nicht), sondern dass es eine "konstante Struktur" hat - eben z.B. so wie du beschrieben hast. Ohne "Konstante Struktur" müsstest du ggf. viele kleine Unterprogramme machen, eben für jede Struktur eines. Und bei vielem ist eines dabei, was du vergessen hast. Bei "Konstanter Struktur" kannst du ein Unterprogramm machen, das alle möglichen Datensätze generieren kann. Im übrigen kann auch ein in der Länge variables Datenfeld unter "konstant" fallen: Man übergibt als Parameter ein Array mit variabler Länge. Das eine Unterprogramm muss dann nur eben die Anzahl der Arrayfelder in den DÜ-Frame aufnehmen.