Jump to content

Strict Variant <-> Numeric conversion


Recommended Posts

Is there a way to get the real numeric type from the Variant, so that it can correctly be cast to either Int or Double? Variant To Data silently converts for you, and I don't want that...

Br, Mike

Link to post
Share on other sites

Never knew that OpenG had that function. I did find what appears to be the same functionality in the vi.lib.

<LabVIEW DIR>\vi.lib\Utility\GetType.llb\Get Type of Variant.vi

Found that when digging around the TDMS viewer. Using some more code from the viewer you can convert many data types to string.

post-6627-127436310578_thumb.png

Link to post
Share on other sites

Also check out vi.lib\Utility\VariantDataType\*. There's a lot of useful VIs in there. Specifically for your case, GetTypeInfo.vi.

Link to post
Share on other sites
  • 4 years later...

Reviving this topic instead of creating one... vi.lib\Utility\VariantDataType\VariantType.lvlib seems to be similar to vi.lib\Utility\GetType.llb

 

Is there a reason for both to exist? Is there an old implementation (the llb) and a new implementation (the lvlib)?

 

This whole concept seems very important to understand, I would like to get to the bottom of this.

 

Thanks

Link to post
Share on other sites

The llb is older. I can't remember when the lvlib came around, but it's been around for several versions now.

I can't say I'm familiar with the old implementation, but I've used the newer one extensively. Works great.

Link to post
Share on other sites

The GetType.llb VIs were added in LabVIEW 7.0, and they were used to parse the legacy I16 Array type descriptors. 

 

The VariantDataType VIs were added in LabVIEW 8.0, when we switched to using Variants to define data types instead of I16 Arrays. At this time, the internals of the old GetType.llb VIs were updated to use Variants as well.

 

So there's no need to use the VIs in GetType.llb. They are deprecated. And it's a little late in the game, but we are planning on marking them as deprecated in a future LabVIEW version.

Link to post
Share on other sites

Yes OpenG also has their versions of getting data type of a variant.  It bugged because in version 2011 the OpenG version was about 10 times faster than the NI version from the lvlib, but in 2012 and newer the NI version was about 10 times faster than the OpenG.  At one point I had some goofy code that would know the version and pick the right one, but I convinced myself it wasn't worth it and to just go with the native (NI) solution whenever possible.

Link to post
Share on other sites

The OpenG does have feature that the NI lvlib doesn't though, like getting the values of the elements of an array. The lvlib GetArrayInfo.vi only gives the element type of the array. So my code uses OpenG when necessary, and VariantType.lvlib when possible, in order to use as much native NI code as possible.

Link to post
Share on other sites

The OpenG does have feature that the NI lvlib doesn't though, like getting the values of the elements of an array. The lvlib GetArrayInfo.vi only gives the element type of the array. So my code uses OpenG when necessary, and VariantType.lvlib when possible, in order to use as much native NI code as possible.

 

Yes, it’s important to note that NI provides a VariantType library, rather than a full Data library like OpenG does.  I wish NI would add the necessary VIs to make its library a complete VariantData solution.  I’ve been toying with the idea of doing it myself.

Link to post
Share on other sites

The OpenG does have feature that the NI lvlib doesn't though, like getting the values of the elements of an array.

Are you referring to the Index Array under the VArray palette?  I'd recommend using a Variant to Data converting the variant, into an array of variants, then you can use the native array functions to index the values out of the array.

Link to post
Share on other sites

Are you referring to the Index Array under the VArray palette?  I'd recommend using a Variant to Data converting the variant, into an array of variants, then you can use the native array functions to index the values out of the array.

Variant to Data will also convert a cluster to an array of Variants; something I did not know for a long time.  

 

— James

 

PS> A related idea.

Link to post
Share on other sites

That was a fun little XNode and didn't take much time at all.  More people should know about the neat features of Variant to Data when it comes to arrays and clusters.

Link to post
Share on other sites

I know these existed in 7.x, not sure about 6.x or 5.x which is when most of the OpenG stuff was made.  Still it is possible it existed, but because it was a relatively new function, maybe the OpenG community didn't know of its full potential.

Link to post
Share on other sites

The Reshape Array can do that, but you'll likely need some extra math to determine the size of each dimension.  But what is wrong with the OpenG solution?

Link to post
Share on other sites

I mean the Reshape array that takes a variant as an input and generates another variant as the output, the data manipulation happening on the type descriptor side. The OpenG lib seems to be a bit old, plus you said that it sometimes perform 10 times slower than the LV lib. So I try to avoid it when I can...

Link to post
Share on other sites

I wasn't trying to say all OpenG functions are slow.  You should perform your own testing to determine if they work fast enough for you.

 

In any case I started making two XNodes to go from 1D to MultiD array and back but I realized it was much easier to just make a VI that works well enough.  Attached is a VI that goes from MultiD to 1D and back in a way that I think is pretty efficient.  The only thing I'd try to improve is a better way of knowing an array size of the array.  Also this method only supports up to a 5 dimension array.  Feel free to add more, but a better solution would be to do it programatically with an XNode.

Array Dimension Converter.vi

Link to post
Share on other sites

This is really cool. This quick test returned TRUE and TRUE! I guess the Variant to Data didn't exist at the time the OpenG library was made...

 

It existed at least in 6.1 but you have to consider that while the node maintained appearance and principle operation, its implementation was many times improved to handle various more complex data transformations.

 

Initially it didn't do much more than transforming a variant that was a pretty exact representation of the target data.

Link to post
Share on other sites

consider that while the node maintained appearance and principle operation, its implementation was many times improved to handle various more complex data transformations.

That's a very good point.  Variants are the first real example of a loosely coupled data type, in LabVIEW, a strictly typed language.  I mean sure you can express any data type as an array of bytes, and therefor a string.  But still Variants are an interesting thing that I'm guessing had some internal debate at NI on if and how they should be implemented.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.