LabVIEW 7.x variable type descriptor conversions?

[Tinkerer]

Hello -

There has to be a better way to do this... "better" in the sense of upward portability.

YEARS ago I wrote a VI that would accept a cluster and write everything in it to a human-readable disk file.  The restriction was that only basic data types were allowed.  At the time, I didn't know what the final collection of data in that cluster and so wanted something ..flexible.. enough so that reading and writing data didn't have to be revisited every time the cluster was changed.

Then I found "Type Descriptors".  Oh, there were warnings posted along the lines of, "This is version specific and you're playing with dynamite if you ever have to upgrade."

Surprise.  And there will be more data in the clusters, too.

I could break everything out of the cluster and use Scan from File or Scan from String and Format into File or Format into String .. but it looks like a nightmare when the clustered data changes form.

If I continue to use Type Descriptors then (gulp!) I'll need to select which number means what to a couple different versions of LabVIEW when reading/writing information..

Is there a better way?

Thanks.

Mark

[rolfk · Accepted solution]

The type descriptor format didn't really change that much over time other than that new types keep getting added to the whole. In LabVIEW 4 or 5 they changed the Boolean representation in memory from an I16 to an U8 and introduced the type code 0x21 for that while 0x20 meant the old type, later timestamps got added and variants and what else, but the old types are still the same since LabVIEW 3. LabVIEW 8 modified the typedescriptor to allow for very large datatypes resulting in typedescriptors that exceed 2^16 bytes length but if you get such a monster you have many other problems to fix first in your software.

So no, typedescriptors don't break between LabVIEW versions just like that but there can be differences that can trip you up.

But are you sure you didn't reinvent the wheel here? There is an OpenG LabVIEW Data Library in the Tools Network which implements the entire parsing and what else and the OpenG Variant Configuration File Library which uses the OpenG LabVIEW Data Library to implement anything to INI storage and vv.

Also newer LabVIEW versions include Vis in vi.lib\Utility\GetType.llb that do basically the same. In 2015 they even were added as officially supported library to the function palette, for earlier LabVIEW versions there exists a LabVIEW package "Hidden Gems in vi.lib" in the Tools Network that adds these functions to the palette.

[Hooovahh]

Great comments rolfk, the only thing I'd add is that while OpenG has their read write cluster to INI, I'm more of a fan of MGIs Read/Write Anything when it comes to large data structures.  The OpenG method under the hood uses the NI configuration writing VIs, which aren't bad perse, but they have a performance hit for each call and it can be significant if you have a cluster of arrays, of clusters etc.  The MGI read/write anything creates the INI string manually, and then uses a single write to disk which is much much better in terms of time needed to execute.

As for other methods of turning anything into a string.  There are the Flatten to and from string which isn't very human readable, there is the to and from XML, and the to and from JSON both of which are pretty decent with a modern text editor.  So in general this has been done many different ways and I too would suggest using one of these already made methods.

[Tinkerer]

I think both of these are great suggestions and I will be looking into them.  Doing what I did... well, it was a bandaid and I knew that going in.  That... and I'd added a boatload of comments as to what was going on (remember, it was written years ago).

Gentlemen, thanks.  Kudos to both.