Convert binary bytes to Labview Extended Precision type

[ecc83]

Hello All:

I am reading a binary file that was written in Windows. One of the types used in the data structure
is the Delphi extended precision type, which is 10 bytes. When reading this in using Labview's
"read binary file" VI, there is only one choice, and that is to read it in as an array of 10 bytes
(Labview's extended precision is 16 bytes.) I have tried using the type cast with no results.
So....how to convert the data in the 10 byte array to a 16 byte extended precision format in
Labview? I guess part of the problem is not really understanding how the extended precision
 type is stored in IEEE format.

Has anyone performed this conversion before that could help out? I'm sure this must have
been done by someone....somewhere....I have no hair left....

Any help would be appreciated!

Thanks,
Gary.

[tst]

This might help you, although you will still need to know the Delphi format.

Personally, I think that instead of trying to match both formats, it will be easier for you to read the binary data and convert it directly to a LabVIEW numeric using a matching algorithm (e.g. take each byte, flip it, join the bytes, etc.), since that would require a single conversion. Obviously, the actual implementation will depend on the way the data is formatted, but whether this is better also depends on that.

[tbd]

Hi Gary,

      According to the reference document tst referred to, Delphi and LabVIEW use exactly the same arrangement and number of bits for sign, exponont and mantissa.  But LabVIEW stores EXTs using 16 bytes - with the trailing 6 bytes being padding.  You'll want to verify all this, but I think the conversion you're after might be as simple as demonstrated in the attached VI.

Cheers!

[ecc83]

Hi,

Thank you for the help!

The cast is something I have tried already...with no success.

Here's a  sample of what a typical 10 byte array looks like from my file (as seen on front panel of Labview):

0    0    0   0   0   0  136   235   81  184   30

This results in zero when pushed through the typecast!

Regards,
Gary.

[ecc83]

Hi tst:

As far as I know, there is no specific type to Delphi. It's a regular 10 byte IEEE extended precision type,
the same kind used on most windows platforms.

Don't feel bad...no one at NI has been able to help either.

Looks like NI might have gone down the wrong path when they decided to go with a 16 byte
ext.precision instead of the normal 10 byte IEEE standard. In the very least they should have
thought about how to get around this problem when they did that!

Gary.

[tbd]

Hi Gary,

      Quick question!  Are there really 11 values per float, (or, have you mischieviously provided an extra "0" )

[altenbach]

---

ecc83 wrote:
0    0   0   0   0  136   235   81  184   30

---

OK, I deleted that extra zero for 10 bytes, but it would help if you could tell us what value you actually expect from this.

Don't forget that it's probably little-endian while LabVIEW is big-endian.

[TCPlomp]

Uhm, something must have gone wrong, the link TST sent,
mentions that LabVIEW stores extended data as 80 bit (10 bytes) on Intel platform.
Complex double is stored as two doubles (=16 byes). My guess is that Altenbach's latest note mentioning the endianess should help you.

If the endiannes is right you should be able to just typecast the data:

[tbd]

Is it possible that what we see here is a no-hidden-1 form of the mantissa?  This link describes Extended Precision about half-way down the page.  If that were the case, then LabVIEW would need the mantissa shifted-left, and the exponent adjusted...

[ecc83]

Hi all,

yes...I threw in an extra leading 0 for good measure!  

I've checked the link regarding the extended precision and the extra bit stuffing
to make it long word aligned. Still is not clear though....how does it become
aligned when the mantissa is already 64 bits? Hmm....isn't a long word
32 bits, so the 64 bit mantissa is already on even boundary multiples?

As for the endian format, I have set the read binary when reading the 10 bytes
for both big and little endian, and there was no difference....go figure.

The value of the data is about 2200.0000 (approximately... I am not anywhere near the debugger today)

Thanks,
Gary.