CVI code to LabVIEW

[DTR]

Currently I am using LV 7.0

Maybe try a .txt file

[rolfk]

---

@DTR wrote:

I am reading a binary string from a UDP port and am trying to convert it to numeric data.  A colleage is doing this in CVI and I am just trying to convert his code into LabVIEW code.

Below is the CVI code:

next=(0x00ff0000&(buf[4*x+1]<<16))|(0xff000000&( buf[4*x+0]<<24))|
       (0x000000ff&( buf[4*x+3]))|(0x0000ff00&( buf[4*x+2]<<8));

                  ff=(double)next; //*16.0; 
                     g_waveform[x]= ff/65536.0;

Attached is a picture of my LabVIEW code.

I am not getting the correct data.

Can anyone see an obvious problem?

---

This is interpreting the stream as 32bit integer array and then byte and word swapping the 32bit elements. After that it interprets the 32bit integer as a single precision floating point value and scales it with 65536.

Basically what Altenbach showed you in his last post is supposedly exactly the LabVIEW equivalent and you don't even have to put this in a loop at all as the C code obviously is, eventhough you don't show it.

LabVIEW by default assumes Big Endian byte order and therefore swaps bytes and words on flattening/unflattening (the typecast is also a flattening /unflattening operation on already flat data) and that is exactly what your collegue has to do in C himself and tries to do in a somewhat complicated way.

Rolf Kalbermatter

[altenbach]

Your binary file does not seem to contain data patterned according to what you would expect from the rest of the discussion.

There seems to be a 8byte repeat, each with  the first 4 bytes at /00, two bytes highly variable, the next byte at /20 or /21 and the last byte always at /40 (see image as read from your "binary file". Are you really sure that your attached file should give data starting with 3.270294??? Maybe you could attach the full binary file instead.

We have several options:

• The data is 32 bits and all odd values are zero.
• The data is actually 64bits
• There are some spacers in the data
• Currently, I cannot find any reasonable algorithm that would give data starting with 3.270294 using your binary file.

Message Edited by altenbach on 04-14-2007 05:59 AM