HEX-Code über Visa Schnittstelle ausgeben

Hallo,

habe folgendes Problem, ich möchte Hexcode und Acsii über die VISA-Schnittstelle senden, ich kann auch anhand eines Zeichens das ich beim lesen des Strings detektiere, unterscheiden ob ein Hex String oder Ascii String vorliegt, ich möchte das der HEX-Code ohne jegliche konvertierung über die VISA-Schnittstelle geht, ein Konvertierung Hex-Code in Ascii scheidet leider aus, da der Entwickler des Gerätes auf Hex-Codes zurückgreift die meines Wissens keine Ascii Entsprechung haben (z.B. Hex 81)

Hat jemand eine Idee wie man das angehen könnte? habe gelesen das LabVIEW keine Hex codes über VISA schickt und alles in Bytes umwandelt, bin nun etwas ratlos.

Danke. MfG jojo

Anzeige

' schrieb:ich möchte Hexcode und Acsii über die VISA-Schnittstelle senden

"ASCII" und "HEX" sind Darstellungsformen von Zahlen.
Das, was du am Bildschirm liest, ist eine Darstellungsform. Das, was im Speicher abgelegt ist, ist eine Zahl. Das, was im Speicher abgelegt ist, kann man nicht sehen. Übertragen über VISA werden immer Zahlen - egal ob sie in HEX, ASCII, BINÄR oder DEZIMAL dargestellt werden.

Eine Zahl möge 65 sein. Dargestellt in Dezimal ist das dann "65", in ASCII "A", in HEX "41", in BINÄR "01000001", etc.

Wenn die Zahl 65 (129) übertragen werden soll, geht das am einfachsten mit nur einem Byte: Das Byte 65 (129) - dargestellt als HEX 41 (81 oder auch 0x81) oder als ASCII A (??) - wird eben übertragen. In der ASCII-Darstellung hat jede Bytezahl [0..255] ein spezifisches Symbol in der (sog.) ASCII-Tabelle, eben 65="A". Auch für 129 gibt es ein Zeichen. Weil jede Zahl genau durch ein einzelnes ASCII-Zeichen darstellbar ist, kann man eine "Einzel-Byte-Übertragung" auch als "ASCII-Übertragung" beschreiben.
In der HEX-Darstellung wird jede Bytezahl durch zwei Zeichen dargestellt, eben 65="41". Demzufolge werden zwei Zeichen übertragen, wenn man eine "HEX-Übertragung" macht. Die beiden Zeichen sind dann die Buchstaben (ASCII) "4" und "1", was den Zahlen 52 (0x34) und 49 (0x31) entspricht.

Zitat:ich kann auch anhand eines Zeichens das ich beim lesen des Strings detektiere, unterscheiden ob ein Hex String oder Ascii String vorliegt,

Das geht per se nicht.
Empfangen werde "31313131313131" - ist das ein Hex-String oder ein ASCII-String? Als letzterer hat der resultierende String den Wert "31313131313131". Eine Übertragung im Hexformat könnte als Wert "1111111" meinen. Maßgebend ist, was die Beschreibung der Schnittstelle sagt.
Wenn man eine Übertragung mit "HEX-Zahlen" macht, kann man eine gewisse Sicherheit einbauen - weil nur Zahlen aus dem Bereich [0..9, A..F] übertragen werden. Alle anderen Zahlen sind nicht erlaubt. Ein Empfang derer würde auf einen Fehler in der Datenübertragung hindeuten.

Nun zu deiner Aufgabe:
Wenn einer 0x81 als Zeichen überträgt, dann macht er eine reine binäre Übertragung - also ASCII. Als ASCII-Zeichen heißt das dann "SOH mit gesetzten 8. Bit" (guckst du hier). Das Zeichen, das du als HEX bezeichnest, ist also lediglich ein Zeichen, das in HEX mit 0x81 dargestellt wird. Die anderen Zeichen, die du als ASCII bezeichnest, haben genau das selbe Format wie das Zeichen 0x81.

Wenn du 81 übertragen willst, dann kannst du das wie folgt machen: Nimm eine Stringkonstante, geht ins Kontextmenü und stell die Darstellungsform(!) auf HEX(!) um, schreib dann 81 (also die beiden Zahlen "8" und "1") rein. Der Inhalt des Strings ist dann ein Zeichen mit dem binären Wert 129, also 0x81. Willst du was ASCII-mäßiges übertragen, z.B. den Text "Muster", dann schreibst du den Text "Muster" ganz einfach in eine normale Stringkonstante.

Es gibt auch folgende Möglichkeit: Mach ein Array of U8 und schreib da die Werte rein, die du übertragen willst. Dieses Array kannst du per "Bytearray nach String" in einen String konvertieren.

Zitat:habe gelesen das LabVIEW keine Hex codes über VISA schickt und alles in Bytes umwandelt,

Das liegt eben daran, dass HEX zuerst mal eine Darstellungform ist. Übertragen werden in erster Linie mal nur "binäre Werte". Eine "HEX-Übertragung" im weiteren Sinne (nämlich im Sinne eines Protokolles) würde bedeuten, dass der Treiber aus jedem Zeichen (Bereich [0..255]), das er senden soll, zwei Zeichen (Bereich jeweils [0..9, A..F]) machen muss. Das ist aber nicht im Sinne eines "transparenten Treibers" (wie ihn VISA in erster Linie darstellt).

Dein Problem besteht darin: "Wie bekomm ich eine Zahl, für die ich beim Eintippen zwei Zeichen brauche, in ein einziges Zeichen gequetzt, damit es übertragen werden kann". Lösung: Siehe oben.

Das hat schon erstmal etwas Licht ins Dunkel gebracht. Danke.
kann man eigentlich Hex und Ascii mischen, also einen zusammengestzten string aus mehreren Stringkonstanten durch string addieren zusammenfügen und dann mit einen rutsch über Visa übertragen? wahrscheinlich nicht oder "merkt" sich LabVIEW das Format der einzelnen teilstrings?
werde mich heute abend oder nacht mal an die umsetzung der Idee machen und dann natürlich von meinen erfahrungen berichten.

mfg jojo

' schrieb:kann man eigentlich Hex und Ascii mischen, also einen zusammengestzten string aus mehreren Stringkonstanten durch string addieren zusammenfügen und dann mit einen rutsch über Visa übertragen?

Natürlich.

Da "HEX", "ASCII" und wie sie alle heißen (in erster Linie) Darstellungsformen sind, im Speicher aber immer das selbe Format haben (nämlich "binär"), kann man sie bedenkenlos addieren (wobei "addieren", wie eben HEX etc., auch schon wieder ein mehrdeutiges Wort ist: Eine Addition im mathematischen Sinne findet bei einem Verknüpfen von Strings nicht statt, wohl aber ein Anhängen, concatenate genannt. Die meisten sagen aber "String addieren", leider nicht "Strings verknüpfen").

Was du auf jeden Fall klären solltest, ist die Schnittstelle. Und die sollte irgendwo schriftlich fixiert sein. Aus der Schnittstellenbeschreibung muss nämlich eindeutig hervorgehen, ob du binär (also in etwa ASCII) oder HEX übertragen musst.

Noch was (bevor ich wieder in meinen Garten gehe und in Schweis zerfließe):
Es gibt ein Sicherungsprotokoll "HEX-Space". Dabei werden alle Zeichen, die eben übertragen werden sollen, in "HEX" mit einem nachfolgendem "Space" konvertiert. Tatsächlich übertragen werden nur Zahlen aus dem Bereich [32, 48..57, 61..66] (in ASCII dargestellt [' ', '0'..'9', 'A'..'F']). Sinn der Sache: Einfache Datensicherung. Wird ein Zeichen empfangen, das sich nicht im angegebenen Bereich befindet, so kann ein Fehler festgestellt werden.

In deinem Falle funktioniert die Datensicherung wahrscheinlich so: Start der Übertragung ist das Zeichen 0x81, also SOH mit gesetztem 8. Bit. Alle folgenden Zeichen sind ASCII, also Zeichen ohne gesetztem 8. Bit. So kann man praktisch auf den Beginn der Übertragung triggern. Der Inhalt des Datenpaketes sind möglicherweise Zahlen in Dezimaldarstellung(!). Eine Zahl z.B. 1203 kann man nicht in ASCII darstellen, wenn dann z.B. in Dezimal, nämlich: "1203" (oder HEX: "04B3"). Dieser String (die Dezimaldarstellung ist vom Typ her also ein String) wiederum besteht aus den vier ASCII-Zeichen "1", "2", "0" und "3" (oder den vier ASCII-Zeichen "0", "4", "B" und "3").


Hinweis:
Ich sehe gerade: Was ich in meinem ersten Posting als [0..9, A..F] geschrieben habe, muss korrekt ['0'..'9', 'A'..'F'] oder [48..57, 61..66] heißen.

Habe jetzt etwas rumprobiert, draussen war es mir eh zu heiss, habe mal 2 Screenshots hochgeladen, das Projekt darf ich leider nicht veröffentlichen.

Hintergrund ist der, um ein Messgerät besser steuern zu können, soll die Möglichkeit bestehen Scripte die in Textform vorliegen abzuarbeiten, die Scripte beinhalten eine Zeit und ein Kommando in einer Zeile und wechseln nach vorgegebener Zeit zur nächsten Zeile und damit zum nächsten Kommando. Der Mikrocontrollerentwickler von dem das Messgerät entwickelt wurde sah sich gezwungen, mit zunehmenden Funktionsumfang, weil Ihm die Buchstaben ausgingen auf Sonderzeichen zu zugreifen, die entweder keine Entsprechung in ASCII haben oder über Tastatur nur sehr schwer einzugeben sind. Bitte keine Angebote wie es gibt auch noch kleine Buchstaben oder Zahlen oder sowas, darüber habe ich schon genug diskutiert leider ohne Erfolg.

Das LabVIEW-Programm gibt es schon länger und die Script-Abarbeitung funktionierte bis jetzt auch ganz gut, aber jetzt kommen eben diese verflixten Zeichen.

Ich habe jetzt versucht folgendes umzusetzen, ich detektiere ob das erste Zeichen ein Dollarzeichen ist (hexcode 1.jpg), wenn ja heißt es jetzt kommt ein Hexadezimal-String mit einer Länge von 2 Zeichen, dann wird eine 3 Zeichen lange Dezimal Zahl angehangen und dann kann es rausgeschickt werden(hexcode 2.jpg), wobei 2 Fälle unterschieden werden (anhand des Dollarzeichens).

Ich habe die Stringvariablen auf Hex-Codedarstellung umgestellt, aber trotzdem teilt er mir das Hexzeichen in 2 Zeichen auf, wie könnte ich das Problem lösen. Ich habe um mich verständlicher auszudrücken mal als Beispiel die Einstellung einer Solltemperatur von 30°C aufgeführt.

Normal würde ich S300 und ein Enterzeichen eingeben. in Hexcode den das Gerät versteht sollte das sowas ergeben $53$33$30$30$0d , wenn ich den Transfer mitsniffe dann sehe ich das er die 53 in 2 Zahlen aufteilt.

Danke für Eure Hilfe.

MfG jojo

' schrieb:Ich habe jetzt versucht folgendes umzusetzen, ich detektiere ob das erste Zeichen ein Dollarzeichen ist (hexcode 1.jpg), wenn ja heißt es jetzt kommt ein Hexadezimal-String mit einer Länge von 2 Zeichen,

Das ist genau das, was ich mit "HEX-Übertragung als Protokoll" gemeint habe. C/C++-Programmierer schreiben ihre Hexzahlen in der Form 0x33, Pascal-Programmierer sagen $33.

Zitat:Normal würde ich S300 und ein Enterzeichen eingeben. in Hexcode den das Gerät versteht sollte das sowas ergeben $53$33$30$30$0d , wenn ich den Transfer mitsniffe dann sehe ich das er die 53 in 2 Zahlen aufteilt.

Wenn du "S300<CR>" eingibst dann sind das 5 Zeichen. "$53$33$30$30$0d" sind 3x5=15 Zeichen. Sagt dein Sniffer, dass da 15 Zeichen übertragen werden, oder dass 5 Zeichen übertragen werden?

Zweite Frage: Erwartet das Endgerät 15 Zeichen oder 5?

$53 (oder 0x53) ist das HEX-Äquivalent zu ASCII "S". Wenn der Sniffer das Zeichen "S" als zwei Zeichen sieht, dann handelt es sich um die Übertragung der Hexdarstellung des ASCII-Zeichens "S".

Weiter muss ich fragen: Erwartet die Gegenseite die beiden Zeichen "5" und "3", möglicherweise mit einem führenden "$"-Zeichen, wenn die Funktion "S" übertragen werden soll? Oder kommt jetzt nur bei deinem Programm, weil es falsch ist, zwei Zeichen raus anstelle von einem?

Anzeige

So viele Fragen???

Laut Aussage vom Mikrocontrollerprogrammierer kann er mit beiden Umgehen, sowohl Hex als auch Ascii Code, das kann ich auch Bestätigen, ich kann S300<CR> als auch auch $53$33$30$30$0d eingeben beides führt zur gewünschten Aktion, mitgeliefert dazu wurde ein Terminalprogramm, nicht das Hyperterminal, sondern ein anderes habe ich sonst noch nie im Netz gesehen, was genau da im Hintergrund passiert kann ich nicht sagen, auf jeden Fall muss bei der Eingabe als HexCode vor jedem Zeichen das $3 stehen, quasi als Trennzeichen wahrscheinlich und am Anfang das einzelne $

Ich habe mal einen Auszug vom Sniffer eingefügt, beim dem ich versucht habe den Code in Ascii und in Hex einmal mit und einmal ohne $ zu übertragen, die Daten die ich übertragen möchte und aus meiner Scriptdatei entnommen werden rechts und was übertragen wird links dargestellt, was mir als LabVIEW Laien auffällt, die Interpretation des Dollarzeichens und die Aufsplittung meines aus 2 Zeichen bestehenden Kommandos (53) in 2 Teile. Ich habe den entscheidenden Teil nochmal Fett dargestellt.

[10/07/2010 16:31:53] - Written data
53 32 30 30 0d S200.

[10/07/2010 16:31:54] - Read data
31 38 31 33 35 20 32 37 37 33 39 20 32 38 30 30 18135 27739 2800
35 2c 30 33 20 32 36 39 31 39 20 30 30 30 30 30 5,03 26919 00000
20 30 30 32 34 30 20 30 30 30 30 30 20 30 30 30 00240 00000 000
30 30 0d 00.

[10/07/2010 16:32:03] - Written data
53 33 30 30 0d 24 35 33 24 33 33 24 33 30 24 33 <blockquote>S300.$53$33$30$3</blockquote>
30 0d 24 35 33 34 30 30 0d <blockquote>0.$53400. </blockquote>

[10/07/2010 16:32:24] - Read data
31 38 31 34 30 20 32 37 37 34 31 20 32 38 30 31 18140 27741 2801
34 2c 34 38 20 32 36 39 34 32 20 30 30 30 30 30 4,48 26942 00000
20 30 30 30 31 35 20 30 30 30 30 30 20 30 30 30 00015 00000 000
30 30 0d 4f 4b 0d 00.OK.

[10/07/2010 16:32:33] - Written data
53 33 30 30 0d 0d S300..


MfG jojo

' schrieb:So viele Fragen???

Ohne Beschreibung muss ich halt Fragen stellen. Du willst doch nicht falsch beraten werden.

Zitat:ich kann S300<CR> als auch auch $53$33$30$30$0d eingeben beides führt zur gewünschten Aktion

Komisches Endgerät.

Zitat:auf jeden Fall muss bei der Eingabe als HexCode vor jedem Zeichen das $3 stehen, quasi als Trennzeichen wahrscheinlich und am Anfang das einzelne $

Das $3 hat nichts mit Trennzeichen etc. zu tun. $3 ist ein Teil des Hex-Codes! $30='0' (ASCII 0), $31='1' (ASCII 1), $32='2' (ASCII 2), ... , $41='A' (ASCII A), ... , $53='S' (ASCII S), $54='T' (ASCII T), ... - und zur Verwirrung: $24='$' (ASCII $) (siehe Internet "ASCII-Tabelle")

Zitat:Ich habe mal einen Auszug vom Sniffer eingefügt, beim dem ich versucht habe den Code in Ascii und in Hex einmal mit und einmal ohne $ zu übertragen, die Daten die ich übertragen möchte und aus meiner Scriptdatei entnommen werden rechts und was übertragen wird links dargestellt

Beide Anzeigen stellen das selbe dar, nämlich das, was übertragen wird. Links steht die Anzeige als HEX-Darstellung, rechts als ASCII-Darstellung. Der Sniffer hat eine besondere Funktion: Er zeigt die gesnifften Daten in zwei verschiedenen Anzeigeformen an: einmal in HEX und einmal in ASCII. Je nach Darstellungsform kann ein erfahrener Beobachter (= Programmierer) das eine oder das andere besser interpretieren.

Zitat:was mir als LabVIEW Laien auffällt, die Interpretation des Dollarzeichens und die Aufsplittung meines aus 2 Zeichen bestehenden Kommandos (53) in 2 Teile.

Das Dollarzeichen wird deswegen übertragen, damit das Endgerät weis, dass jetzt zwei Zeichen folgen, die zu einem Zeichen zusammengesetzt werden müssen.

[code][10/07/2010 16:31:53] - Written data
53 32 30 30 0d

danke für deine ausführlichen antworten, ja ich komme damit zurecht, die Formatstrings habe ich mir dank Hilfefunktion gut "erarbeiten" können, vieles davon wußte ich auch schon, habe es aber wahrscheinlich noch nicht so verinnerlicht bzw. die praktische anwendung ist eben dann immer noch was anderes.

also müßte ich wenn ich meinen hexcodestring zusammen setzte die entsprechenden formatierungsoptionen auswählen bzw. den Formatstring ansetzen oder wo wäre der günstigste zeitpunkt dafür?

kann leider erst wieder ab heute abend probieren.


MfG jojo

@jojo: Bitte keine Beiträge im SMS-Stil (soll heißen fast alles klein geschrieben). Eine Computertastatur hat eine Shift-Taste, also diese auch sinnvoll einsetzen.

Gruß, Jens