Hallo,
ich sende per sockets (in C++) ein int:
int sz='z';
bytesSent = send( m_socket, (char*)(&sz), 4, 0 );
Nun will ich den mit LabVIEW empfangen. Das klappt auch. Wenn ich ein 'z' sende, wird mit das auch als 'z' angezeigt. Nur kann ich leider die gelesenen Daten mittels Typenformung nicht in eine Zahl umwandeln. Anbei mein Versuch (LabVIEW 8.5). Was mache ich denn falsch?
Danke - Curtis
Die Typformung ist ein zusätzliches AddON für forteschrittene Benutzer und immer mit Vorsicht zu benutzen. Warum versuchst Du es nicht erst einmal mit den normalen String zu Zahl Konvertierungsfunktionen? (Unter String-Funktionen). Die sind viel leistungsfähiger, als man zunächst glaubt.
' schrieb:Hallo,
ich sende per sockets (in C++) ein int:
int sz='z';
bytesSent = send( m_socket, (char*)(&sz), 4, 0 );
Nun will ich den mit LabVIEW empfangen. Das klappt auch. Wenn ich ein 'z' sende, wird mit das auch als 'z' angezeigt. Nur kann ich leider die gelesenen Daten mittels Typenformung nicht in eine Zahl umwandeln. Anbei mein Versuch (LabVIEW 8.5). Was mache ich denn falsch?
Danke - Curtis
Ganz einfach! Du übersiehst die Endianess. Das ist die Reihenfolge der Bytes in einem Bytestream. Intel CPUs möchten das gerne in Little Endian (LSB first). C Programme die für Intel-Plattformen geschrieben sind gehen ohne besondere Vorkehrungen im allgemeine von dieser Bytereihenfolge aus.
LabVIEW bevorzugt aber Big Endian (MSB first) und dasselbe gilt im Prinzip für viele TCP/IP Protokolle die oft Network Byte Order vorschreiben, was wiederum dasselbe ist wie Big Endian.
Vor LabVIEW 8.0 war Big Endian das einzige Format das LabVIEW für Typecast und Flatten To/Unflatten From String unterstützte. Seit LabVIEW 8 unterstützen die Flatten und Unflatten Nodes einen Parameter mit dem man die Endianess des binären Datenstromes vorgeben kann.
Aber auch vor LabVIEW 8, genau so wie für Dein Beispiel mit Typecast, kann man sich in LabVIEW gut behelfen indem man die Swap Words und Swap Bytes Nodes in die numerischen Wires einfügt.
Rolf Kalbermatter
...weil ich z.B. auch mal 6504 senden will. Und das hat ja keine ASCII-Repräsentation. Sorry, mein Beispiel war dahingehend wohl verwirrend. Aber so läßt sich wenigstens schauen, ob die Daten richtig gesendet und empfangen wurden.
Curtis
' schrieb:Ganz einfach! Du übersiehst die Endianess. Das ist die Reihenfolge der Bytes in einem Bytestream. Intel CPUs möchten das gerne in Little Endian (LSB first). C Programme die für Intel-Plattformen geschrieben sind gehen ohne besondere Vorkehrungen im allgemeine von dieser Bytereihenfolge aus.
LabVIEW bevorzugt aber Big Endian (MSB first) und dasselbe gilt im Prinzip für viele TCP/IP Protokolle die oft Network Byte Order vorschreiben, was wiederum dasselbe ist wie Big Endian.
Vor LabVIEW 8.0 war Big Endian das einzige Format das LabVIEW für Typecast und Flatten To/Unflatten From String unterstützte. Seit LabVIEW 8 unterstützen die Flatten und Unflatten Nodes einen Parameter mit dem man die Endianess des binären Datenstromes vorgeben kann.
Aber auch vor LabVIEW 8, genau so wie für Dein Beispiel mit Typecast, kann man sich in LabVIEW gut behelfen indem man die Swap Words und Swap Bytes Nodes in die numerischen Wires einfügt.
Rolf Kalbermatter
Hallo,
irgendwie stelle ich mich zu doof an. Anbei mal mein Versuch. Hmmm? Anstelle von 't' (=116) erhalte ich 7602176.
Curtis
' schrieb:Hallo,
irgendwie stelle ich mich zu doof an. Anbei mal mein Versuch. Hmmm? Anstelle von 't' (=116) erhalte ich 7602176.
Curtis
Natürlich! Hast ja ein int32 und der hat 4 Bytes!
Sagte ja Swap Bytes UND Swap Words. Das Erste swapped die Bytes innerhalb eines Words, also
1 2 3 4 -> 2 1 4 3
und das Zweite swapped die Words selber, also
2 1 4 3 -> 4 3 2 1
Capiche?
Rolf Kalbermatter
