About This File
This package contains functions for reading and writing Variant Repositories. A Variant Repository is a variant which behaves similar to a look up table with key value pairs.
Using the Write Variant Repository tags can be written using any data type. Similarly the Read Variant Repository can read back the data. The type of the data can be specified and the output of the read will be of that type. Provide the type as an input, or right click the read and select the data type to read. If the type isn't specified the read function will try to look at the data type upstream from the read and set the type to that. Errors will be generated if the tag doesn't exist, or if it exists but is the wrong data type. Multiple tags can be written or read, by right clicking the read or write function. These multiple read/write functions deal with arrays of data to read or write, and an array of tags to go along with the data.
Multi-Level Variant Repositories can also be written or read. This will write a Variant Repository, as a tag to another Variant Repository. Because of this, two levels of keys are needed for reading and writing, the Section, and the Tag. Type selection, and multiple reads or writes behave like the normal read or write Variant Repository functions.
When writing values into a Variant Repository there is an optional Write Once input. This is set to false by default, but if a tag is written when this is true then attempting to write this tag again will return an error.
Variant Repositories can be saved to a semi-human readable INI file. This data can also be read back from the INI file.
The Read, Write, Read Multi Level, and Write Multi Level functions are implemented as XNodes. NI does not provide support XNode development.
For an introduction to XNodes read Adam Rofer's "XNodes - A Crash Course" presentation (http://lavag.org/files/file/56-xnodes-a-crash-course-powerpoint).
OpenG Comparison Library-188.8.131.52
OpenG Variant Configuration File Library-184.108.40.206
OpenG String Library-220.127.116.11
OpenG LabVIEW Data Library-18.104.22.168
OpenG Error Library-22.214.171.124
OpenG Array Library-126.96.36.199
The attachment is in the form of a Package Configuration and contains the Variant Probe package found here. The reason I included it is because it is the only package that is needed but can't be found on the Package Network. This package is only needed to demonstrate one of the examples and isn't critical to any Variant Repository function.
This Has Been Done Before
Yup it sure has. Having a look-up table with key value pairs has been done many different ways, from CVTs, the LabVIEW Container, and native Variant Attributes just to name a few. But some of these have really poor performance, while this implementation is meant to be as little over head as possible.
But the real benefit is the XNode type adaption, and type prediction. Just write anything, and then read it using the correct type without needing to perform any explicit type conversion.
Because the data type is really a variant, no extra functions are needed to get to the data. This can be good or bad. Yes a class could be used to restrict the data, but with a simple implementation I feel like that would get in the way. My opinion may change in the future but for now I love that a normal tool like the Variant Probe can just look at the tree view of a Variant Repository without any extra tools or conversions.
Variant Repositories also combine the WORM (Write Once Read Many) paradigm. A write can be set to write once, and then attempting to write again will generate an error.
What's New in Version 188.8.131.52 See changelog
- - Removed Post-Install VI, it caused issues
- - Added Load/Save to the palette
- - Removed ability to use OpenG or NI version for reading Variant name based on LV version, it now just uses OpenG