Is there a byte swapping side effect to the type cast function?

[bmfstop]

I am developing a PC based program that reads from a TCP connection (network byte order), yet doesn't require byte swaps? There is a non-labVIEW program on the PC which receives the same byte stream and does need to swap!

[rolfk]

bmfstop wrote:

> I am developing a PC based program that reads from a TCP connection
> (network byte order), yet doesn't require byte swaps? There is a
> non-labVIEW program on the PC which receives the same byte stream and
> does need to swap!

LabVIEW data flattening and unflattening does always assume the binary
side to be in big endian (network byte order) and does the approapriate
byte and word swapping on all x86 platforms. For non x86 platforms no
byte swapping is necessary as those platforms work with Big Endian byte
format already.

Rolf Kalbermatter

[altenbach]

You have to remember that LabVIEW is platform-independent and always big-endian, even under Windows (which is otherwise little-endian). A nice feature!

[bmfstop]

Okay. So I guess is doesn't matter if the data source on the other end of the socket was labVIEW or not. By using the type cast function in my code, the bytes get swapped for me, behind my back so to speak.

Would the unflatten from string function do the same thing?

[rolfk]

bmfstop wrote:

> Okay. So I guess is doesn't matter if the data source on the other end
> of the socket was labVIEW or not. By using the type cast function in
> my code, the bytes get swapped for me, behind my back so to speak.
>
> Would the unflatten from string function do the same thing?

Yep, these two functions work symmetrical. Typecast is also doing
byteswapping and is in that similar to flattening but with some
limitations. It only can handle flat data (no embedded pointers or
arrays) and does not prepend an int32 value indicating the size of
variable sized data in the casted bytestream.

Rolf Kalbermatter

[grahamwebb]

I'm having a similar problem with a data stream read using the TCP/IP Read function - I cast the data but the cast function was producing different results on different PCs (2 Dell, same build! One sony laptop, all WinXP sp2), so before reading this thread I was fiddling about with the data representation and found I64 worked for one Dell, double precision for the other and so on.

I'll have a look at byte order now, but I would like my code to be processor independent, is there a way to check which processor is being used, with LabVIEW?

[grahamwebb]

The three PCs I am using:

x86 Family 15 Model 2 Stepping 9

x86 Family 6 Model 15 Stepping 11

x86 Family 6 Model 23 Stepping 6

.. what is my cast function doing?!

[Coq_Rouge]

I guess you have to repack your string before sending it to the non Labview program(se posted picture). I think visual C uses litlle endian. As an example. In Labview the sgl number 123.123 is equal to to the hex byte array 42 F6 3E FA. Doing the same in  visual C for a float, will give  FA 3E F6 42. The same bytes but in a different order. The flatten to string function will hanlde this job for you. Use the ditailed help for pointer to examples. On this page http://www.61131.com/download.htm You will find a tool if you want to toy with number (Floating point to/from hex/binary conversion).

@grahamwebb

I think you should look at your code. Perhaps you lose or get some ekstra unwanted bytes in your programming/transmission.

[altenbach]

---

grahamwebb wrote:

I'm having a similar problem with a data stream read using the TCP/IP Read function - I cast the data but the cast function was producing different results on different PCs (2 Dell, same build! One sony laptop, all WinXP sp2), so before reading this thread I was fiddling about with the data representation and found I64 worked for one Dell, double precision for the other and so on.

I'll have a look at byte order now, but I would like my code to be processor independent, is there a way to check which processor is being used, with LabVIEW?

---

If it is I64 vs. DBL, byte order is not your problem!!!

I seriously doubt that your analysis is correct. If the typecast handling would depend on processor stepping, we all would have fallen on our nose many times before. 🙂

Create a string indicator after the TCP read, run the VI so the string indicator contains data, then change the indicator to a diagram constant. Disconnect the broken wire to the diagram constant. This way the constant contains typical raw data. Now attach the VI. Tell us what kind of numeric data is expected to be in the string.

 I suspect one of the following:

1. race condition.
2. framing error.
3. Corrupt network driver (does the network work otherwise?)

[grahamwebb]

Will do thank you, but it will take me a while to cut down the code to something I can post here, and I'm going home now so perhaps over the weekend ..

There is no handshaking with the source, it simply chucks out data to a TCP/IP port at about 100Hz, I'm using producer-consumer loops with a queue to prevent losing anything when the network load changes.

One data packet contains one frame of motion capture data (xyz coordinates for n number of markers). Packets are sent with packing to ensure they are the same size, so I use the 'packet size' byte to read the right amount of data to sync with the source, (and hope I can find the packet size byte!). But once it's reading and queuing data that all works nicely and each coordinates data appears when and where I expect it. On my PC up here it displays double precision nicely, but on other PCs the data get cast as silly numbers, eg: 1.3245x10^312. At one stage I scaled and shifted the data and found it is just that scaled and shifted by ^312.

I'll send more details later.