Ich habe bald die Aufgabe mit einer seriellen Schnittstelle Daten zu übertragen, die im Hex-Format vorliegen. 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? Wenn ich da jede einzelne Hex-Ziffer in Ascii umwandeln muss, dann werde ich ja wahnsinnig. Oder geht das einfacher?
Gruß Markus
' schrieb:Eine Zahl habe den Wert 65. (Alleine das Hinschreiben dieses Satzes birkt das Problem, dass eine Darstellungsform für die Zahl benutzt werden muss).
Für diese Zahl gibt es mehrere Darstellungsformen: HEX = 41 (Beachte: zwei Zeichen); DEC = 65 (Beachte: zwei Zeichen, beachte weiterhin, dass z.B. 129 aus drei Zeichen steht); ASCII = 'A' (Ein Zeichen); Binär = 0100.0001 (8 bzw. 9 Zeichen, der . ist Ansichtssache).
Dieser Wert kann nun wie folgt übertragen werden:
Binär: Bei dieser Übertragungsart wird ein einzelnen bzw. ein einziges Byte übertragen. Beachte dass hier nicht die Binärdarstellung des Wertes übertragen wird - die hätte nämlich 8 Zeichen = 8 Byte.
ASCII: Auch bei dieser Übertragung wird ein einzelnen bzw. ein einziges Byte übertragen. Für die Übertragung besteht also kein Unterschied zwischen ASCII und Binär. Jemand der auf der Strecke mithört kann nicht feststellen, ob die Übertragung Binär oder ASCII ist. Der Unterschied liegt im Protokoll. Ein ASCII-Protokoll kann z.B. das Zeichen LF (oder CRLF oder ETX oder EOT etc.) als spezielles Steuerzeichen auffassen.
Wenn nun einer verlangt (warum auch immer), dass die Zahl in Hexformat (oder Dezimalformat) übertragen werden soll, dann will er, dass "41" übertragen wird - d.h. es sollen zwei Zeichen übertragen werden. Um aber über die Strecke "41" zu übertragen (jemand der mithört würde die beiden Zeichen "4" und "1" erkennen), müssen die ASCII- bzw. Binärwerte von "4" und "1" übertragen werden. Diese selbst sind 0x34 und 0x31.
Mark_LabVIEW hat deswegen gesagt, er will ASCII übertragen, weil sein Display nur ASCII-Zeichen darstellen kann. Das sind die Zeichen von 0x20 bis 0x7E. Der Bereich unter 0x20 ist nicht darstellbar, weil es sich in der "ASCII-Darstellung" bei diesen Zeichen um Steuerzeichen handelt. Es wird also kein Zeichen dargestellt, sondern eine Funktion ausgeführt. Um in einem Binärkanal (also einer per se protokollfreien Übertragung, wie sie Mark_LabVIEW benutzt hat, davon gehe ich aus) ASCII-Werte zu übertragen, muss man aber keine Anpassung machen - der Übertragungsstrecke ist es egal, ob das Zeichen darstellbar ist oder nicht. Ob das Zeichen nun als ASCII-Zeichen oder als Binär-Zeichen aufgefasst werden soll, liegt im Ermessen des Empfängers. Wenn der Empfänger weis bzw. verlangt hat, dass eine HEX-Übertragung stattzufinden hat, dann wird er immer zwei Bytes zusammenfassen und aus den zwei Zeichen "4" und "1" wieder 0x41 machen. Weiterhin gehe ich davon aus, dass Mark_LabVIEW mit "Konvertierung nach ASCII" den Befehl "Bytearray nach String" gemeint hat: Er kann dann im String die Darstellungsform "A" sehen. (Bei "Zahl nach String" hätte er "65" gesehen). Würde das VISA-Schreiben-VI auch mit einer Zahl bzw. einem Zahlarray als Eingangsparameter funktionieren, würde man nicht die "Konvertierung" nach String brauchen, die eine ASCII-"Wandlung" vortäuscht. Strings pflegen von sich aus eine ASCII-Darstellung zu machen - auch wenn der Inhalt binär ist.
