cast U64 Long Long

[lmd2]

What I am working on is converting a client's device driver written in C into a library of VI's. They have asked for the initial release be written in 7.0
This particular function (one of some 220 for this DLL) retrieves the current value from the card’s 48-bit time tag register. The function's prototype:
S16BIT _DECL aceGetTimeTagValueEx(S16BIT DevNum, U64BIT* ullTTValue);
The documentation states:
UllTTValue * Pointer to a variable of type U64BIT

I tried getting an explanation from the client (some C people tend to talk down to LabVIEW developers)
If I understood correctly, they are pointed to two U32 which they cast to a U64

[TCPlomp]

Just instruct LabVIEW to read a dbl by pointer (*dbl), and typecast that to a an array of two U32's, that should do. Make sure you test a lot.

Ton

[lmd2]

worth a try - I'll post my success (or lack of)
either way, thanx for the help

[smercurio_fc]

---

@lmd2 wrote:
(some C people tend to talk down to LabVIEW developers)

---

Yeah, well, that's not too surprising. They should talk to some of the really experienced LabVIEW developers on this forum. I'm hardly in that league. I suspect their narrow-mindedness would soon evaporate once they see what these folks can do.

To your query:
I had initially also suggested using a DBL instead since that's 8 bytes. The thing you have to be careful about is that if you try to display the value in a DBL indicator, the displayed value will be meaningless. The bit pattern, however, should be correct, and you can typecast the value into something else.

What confuses me is your statement:

---

What I am working on is converting a client's device driver written in C into a library of VI's.

---

If you're using the DLL, what exactly are you converting? It seems to me you're just writing a library of accessor functions. The underlying code (DLL) is still C.

[tbd]

Hi Lawrence,

      It's certainly possible to bring in the long long as a byte array, and it's possible to convert that byte-array to an EXT.

http://forums.ni.com/attachments/ni/170/297714/1/Util.Time.U64ToEXT.vi

The only tricky part will be LSB/MSB ordering

I'm not sure about reading that DLL parameter as a (pointer to) DBL.  Though the DBL is 8 bytes, its binary representation only has a 54-bit mantissa, so you'll loose about 10 bits of precision when doing integer math,  However, the EXT has a 64bit mantissa, so can accurately handle the U64.

Cheers!

Message Edited by tbd on 06-29-2008 01:00 PM

[TCPlomp]

Here's my try, I think this should work.
Maybe some bit juggling with endianness.

Ton

[tbd]

Hi TonP,

      Here's 5 stars for a less complicated solution than mine, (I didn't read your post thoroughly):smileytongue:   however, the temporary DBL seems strange - why not just declare the parameter as a pointer to an array of DWORD and loose the need to cast?

Cheers.

Message Edited by tbd on 06-30-2008 12:10 AM

[smercurio_fc]

---

@tbd wrote:

I'm not sure about reading that DLL parameter as a (pointer to) DBL.  Though the DBL is 8 bytes, its binary representation only has a 54-bit mantissa, so you'll loose about 10 bits of precision when doing integer math,  However, the EXT has a 64bit mantissa, so can accurately handle the U64.

---

I wasn't actually recommending to do any kind of math with the DBL. The point of using the DBL datatype was to use an 8-byte datatype since 7.0 doesn't have a U64. Last Friday I did a quick DLL that has as one of its arguments a pointer to a U64. In the DLL I set the value of the integer to 8221322035851775305. In 8.2 I called the DLL using a pointer to a U64 and a pointer to a DBL. As you can see, the numerical display of the DBL is wrong, but the interpretation of the value as an array of U8s is the same:




It's still not clear what the user is actually trying to do with this number. Is it being passed to other functions? Is it being used in numerical calculations in a VI? Is it being displayed? I think knowing how it will be used is a factor in determining the best way to do this.

Message Edited by smercurio_fc on 06-30-2008 09:08 AM

[tbd]

---

smercurio_fc wrote:

The point of using the DBL datatype was to use an 8-byte datatype since 7.0 doesn't have a U64.

That's the part I didn't understand - why expose the 8 bytes as a double - which is useless in 7.0.

An array of U32s (instead) can be quickly converted to an EXT 

---

It's still not clear what the user is actually trying to do with this number. Is it being passed to other functions? Is it being used in numerical calculations in a VI? Is it being displayed? I think knowing how it will be used is a factor in determining the best way to do this.

Message Edited by smercurio_fc on 06-30-2008 09:08 AM

---

I expected some endian-ness clarification as well, but the thread's been quiet for a few days...

[smercurio_fc]

---

@tbd wrote:

---

@smercurio_fc wrote:

The point of using the DBL datatype was to use an 8-byte datatype since 7.0 doesn't have a U64.

That's the part I didn't understand - why expose the 8 bytes as a double - which is useless in 7.0.

An array of U32s (instead) can be quickly converted to an EXT

---

You are basing this on an assumption of what the user is trying to do. Yes, an array of U32s can be converted to an EXT. But so can a lot of other things. As I've noted several times, it's not completely clear what the user is actually trying to do with this value. To quibble about one specific way being "better" than another is pointless when you don't know what the specific requirements are.