Rebuilding a single precision float from 4 discrete bytes

[Gerrr]

I am sending data over a serial link and need to pass single prec floating point numbers. I have used the join bytes to reassemble the bytes in the past for other data types. In this case it does not seem to work for the SGL data types. I have joined the bytes which gives me an integer output. I then tried the SGL conversion icon without any luck. Is there some secret here? I could parse through the bits and reconstruct the value that way but I figured that there was an easier way.

When I use the SGL conversion icon does it just add a decimal place or does it look at the physical bits?

Thanks for your help,
Jeremy

[tbob]

Are you sure that you are joining in the proper order? Maybe you have the bytes and/or words reversed. How was the number split before transmission? They need to be joined in reverse order. Also, the bytes need to be converted to a string to send over the serial port.
For example, 32 bit number is split into 16bitA(top output) and 16bitB(bottom output). Then 16bitA is split into 8A(top) and 8B. Then 16bitB is split into 8C(top) and 8D. Build a byte array with 8A thru 8D. Use the ByteArray to String function to convert to characters suitable for sending over serial port. The order of sending is 8A, 8B, 8C, 8D. On the receiving end, use String to Byte Array to get the 4 bytes, 8A will be received first. Join 8A(top input) and 8B(bottom input) to make 16A, join 8C(top) and 8D to make 16B. Then join 16A(top) and 16B to make the original 32 bit number.

[chilly_charly]

Once your bytes are assembled in the right order, you have to tell LV that the assembly IS a single float. This is a process different from converting to a single float! Use the "Type Cast" function in the "Advanced/Data manipulation" subpalette. Wire a Single float constant to the center connector, and that should do the trick.

CC

[tbob]

CC, can you explain the difference between using the To SGL conversion function and the Type Cast function with a SGL as the center input?
Merci Beaucoup!

[altenbach]

tbob,

To SGL converts the data type and keeps the number the same (within the limits of the representation). For example 5566(U32) (actual bits: 00000000000000000001010110111110) will become 5566(SGL) (actual bits: 01000101101011011111000000000000). LabVIEW needs to get the significant digits and calculate the correct exponent to generate the new bit pattern of the SGL. In general, the bit pattern changes!

Typecasting leaves all bits untouched and simply tells the LabVIEW that from now on these 32 bits are of a SGL data type. In many cases, they will represent an entirely different number in the new representation.

Message Edited by altenbach on 03-09-2005 04:16 PM

[tbob]

Thanx for the explanation. Now according to the attached vi, the type cast gives the wrong number. Can you please tell me why anyone would use type casting when converting to a SGL, as suggested by CC in his answer? Seems like splitting then joining numbers would procude the correct bit pattern, and type casting to SGL would give the wrong results. Also, how do you split a SGL into bytes? How do you display a SGL or DBL into bit patterns.
Thanx for your answers. Even veterans can learn new things.

[Gerrr]

Chilly Charley / Altenbach

Thanks for your response, the first time I have ever had to use the type cast device works great and makes sense.

Regards,
Jeremy

[Donald]

tbob,

I can't take a look at your Typecast.vi, but as far as:

Q: "How do you display a SGL or DBL into bit patterns"

One A:
Typecast to a string OR use Flatten to String. Display the resulting string in 'Hex' mode. There's your bit pattern(s).

Sincerely hope this doesn't get your head spinning too much again. If it does I'll try to post something in today's earlier thread.

[altenbach]

tbob,

There is no right or wrong number, the initial data is just a string of 32 innocent bits. Only once you know what data type it is supposed to be, you can extract the correct number by typecasting.

Example: If you need to send a number via TCP it needs to be cast as string. On the receiving side you can only obtain the original data back if you know what data type it originally was. In the situation discussed in this thread, the bits represent a SGL number (This fact MUST be known, because it cannot be independently determined), thus they MUST be typecast using a SGL type to get the correct result. After that, you can do whatever you want with it, for example convert it to DBL or I32 in the old fashioned way.

The attached example (LV 7.1) shows how to display the bits of U32 vs SGL. It also shows four different 4-byte strings, each representing the number "1234" (U32, SGL, or string). You need to know the type before you can extract the corret number.

Typecasting is universal. You can typecast a complex cluster containing arrays, booleans, strings, etc. to a simple string. Later you can recreate the original data by typecasting the string using an equivalent cluster as type.

[chilly_charly]

tbob,
There are various possible ways of getting the byte values of a float.
What you need to remember is that the destination must be compatable with the origin. You cannot convert an extended precision float into a long integer, just because there is not enough room for all the bytes !
See the attached vi.

BTW, could somebody try to explain me why extended precision numbers use only 10 bytes. I believed that 12 bytes was the standard.

CC