[CR] Variant Repository

[hooovahh]

Name: Variant Repository

Submitter: hooovahh

Submitted: 04 Sep 2014

Category: XNodes

LabVIEW Version: 2011

License Type: BSD (Most common)

Description

 

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.

 

XNode Disclaimer

 

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).

 

Dependencies

 

OpenG Comparison Library-4.0.0.3

OpenG Variant Configuration File Library-4.0.0.5

OpenG String Library-4.1.0.12

OpenG LabVIEW Data Library-4.2.0.21

OpenG Error Library-4.2.0.23

OpenG Array Library-4.1.1.14

LAVA Palette-1.0.0.1

Variant Repository-1.0.0.7

Variant_Probe-2.4.1

 

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.

 

Click here to download this file

[Antoine Chalons]

I love the "write once" option, great job!

I use variant attributes alot because it's flexible and fast for searching by name, this package makes it even easier to implement.

 

Cheers 

[crelf]

You're right, this has been done before, but your version is the best and most feature-rich example I've seen. Nice work!

[torekp]

Noob question.  I read Adam Rofer's "XNodes - A Crash Course", but I didn't see any guidance on building EXE's from Xcontrol-laden VIs.  Can it be done?  If so are there any special tricks to it?

[hooovahh]

I assume you meant XNodes not XControls.  After an XNode is interacted with it will make the VI using scripting.  And so in an EXE this VI should be what is used, and therefore no XNodes exist in a EXE, only the VIs they make.  Besides NI uses XNodes all the time.  A common one is the match regular expression so you shouldn't have any issues.

 

...that being said I just tried to make an EXE with my VR package and it fails...so yeah I need to look into that.

 

EDIT:  It looks like this does work.  I've been making a few changes since this release and something in that version broke which doesn't allow EXEs to be made.  This version works fine.

 

Double EDIT:  So it looks like from source works, from the files on the palette it doesn't so something got messed up in the package making process.  But this shows that that XNodes themselves can be in EXEs.

 

Tripple EDIT: Okay so I found the issue was with the Post-Install VI that was being used in the package making process.  It wasn't all that necessary and I got rid of it and uploaded a new version 1.0.1.11 that I have built into EXE without a problem.  The new version uses the UpdateData ability so older copies of the XNode should be replaced with newer ones after opening a VI that used the older version.

[hooovahh]

Some have asked for the Variant Repository VIs to be available as non-XNodes.  So I wrote some scripting code to make polymorphic instances, edit VI icons, and make the polymorphic VIs.  But what I hope this illustrates is just how useful XNodes are.  

 

The Non-XNodes version is 252 VIs and one control.  That's a lot of VIs to have to load into memory when using these polymorphic instances.  That's 60 normal VIs inside each of the 4 polymorphic VIs.  And it doesn't even support all of the features the XNode counter parts do.  

 

From a reusability stand point polymorphic VIs have many things that make using and maintaining them difficult.  From the number of files loaded, to custom help, icons, and terminals from each instance, along with supporting more types than the polymorphic could.  Don't get me started on when a bug is found and it isn't something you can easily fix with scripting.  So then you need to open up each of the polymorphic types and make changes to each one.  Oh and ever try to use the polymorphic editor with 60 instances?  Yeah I've stopped trying and use a combination of tools so I never need to.

 

Some day, hopefully NI will be able to invest the time needed to make XNodes an official feature.  But until then I'll likely need to support many polymorphic types, when XNodes aren't trusted.

Variant Repository Non-XNode.zip

[Kahrma]

Hi

Great tool. Considering using it for sharing data between vision functions in a plugin based architecture. Passing the variant repo reference as a DVR to the modules. Though I need some more datatypes Specifically from VDM (point, line, reference coordinate system, ROI etc.). Anyway to do that ?

 

Thanks

[hooovahh]

Yeah the XNode version works with any data type.  It can read and write references, and ROI's which I think are clusters.  The non XNode version would need to have those types added to the polymorphic VI types.

[Neil Pate]

Very nice indeed 

 

I am thinking about using this in a project where I have to interface with some external equipment via OPC-UA and some other custom protocol. I have lots of "variables" (tags) and want to experiment how things can be done as much as possible by just using a channel name in my code rather than individual element access.

 

Anybody given any thought as to how best to share the variant between processes? Lots of options here, as Kahrma mentioned perhaps a good technique is a DVR? 

Edited March 17, 2016 by Neil Pate

[smithd]

It wouldn't be hard to change the XNode to take a DVR of a variant rather than the variant itself. I did something similar so it would take an object and it was a lot easier than I thought it would be.

 

For OPC UA in the past I've used the CVT and just made a small process which reads each OPC UA data value and copies it into the CVT. Then you can define groups for each of your tags and read data by group.

 

NI made something very similar recently, although not as nice as this variant repo. The advantages though are that it has some metadata (last update timestamp, whether or not the value is valid, and then another variant for metadata):

https://decibel.ni.com/content/docs/DOC-47108

[Neil Pate]

Yup, I had the same thought actually about modifying the x node to take a DVR. Going to tinker with this when I get a moment.

One of my issues with the CVT is that as it stands everything is a double right?

[hooovahh]

Yeah I have other issues with the CVT, like performance.  And when writing a messaging library that is uses a wrapper constantly for variant data, I wanted it to be light weight, and generally I didn't find a wrapper for a look up table that wasn't better when it comes to performance than Variant Attributes.

[smithd]

One of my issues with the CVT is that as it stands everything is a double right?

No, numerics, bools, strings, and arrays of the same.

 

Yeah I have other issues with the CVT, like performance.  And when writing a messaging library that is uses a wrapper constantly for variant data, I wanted it to be light weight, and generally I didn't find a wrapper for a look up table that wasn't better when it comes to performance than Variant Attributes.

Doesn't sound like you're using it for an appropriate use case -- if every access is completely dynamic then yes there is no point to it vs a lookup. where it shines is neil's use where there are a fixed set of tags which you want to share globally but, being fixed, you can cache the lookups for. An equivalent but sometimes slower implementation would be using your variant repo where every contained value is a dvr or queue or notifier. The dvrs can be slower if, as in the opc ua situation, you want to access a large number of elements in one go. 

Edited March 21, 2016 by smithd

[hooovahh]

Doesn't sound like you're using it for an appropriate use case -- if every access is completely dynamic then yes there is no point to it vs a lookup. 

It sorta is dynamic.  Actors can unregister or register to new events at run-time, but in practice is never really needs to.  And the messaging structure is based on user events, and you can't register for an array of user events, unless each of the data types of each event are the same, which is where I used the variant as the data type.  Also there are times when I might only want some information from the variant, and I don't pull out all of the payload, something like meta data instead, and I believe this is most efficient with a variant attribute, where you don't have to read everything.

[bbean]

I've been having problems with intermittent crashes and LabVIEW hangs recently using the Variant Repository xnodes in LV2015SP1.  More specifically Read Variant Repository.xnode.  Has anyone else had problems in LV2015SP1?

 

http://www.screencast.com/t/tj15qFGRc

 

 

[hooovahh]

Well that is concerning for sure.  Unfortunately I don't have 2015 SP1 yet, but this might be as good of reason as any to start the long download process of that whole software suite.  But the fact that this happens on the save makes me even more confused.  If it were on the wire operation then I could do some debugging and look into the VIs that get ran, when the wire operation takes place.  But the fact that the wire operation works just fine, and it is just on the save, makes me think it might be something more difficult to troubleshoot and resolve.  Well I guess I'd send the report to NI...and hope for some support.

[bbean]

I can't really narrow down what causes it.  But it seems like if you copy the read var xnode from the existing diagram and wire the same cluster type to it, its fine.  But if you select a new instance of the xnode from the addons pallette and place it on the diagram and wire to the same constant, then save it crashes.  I don't know if that helps narrow it down to an ability or not.  Also it doesn't seem to happen with the string data type.  So far I have just seen it on clusters.  It may be a labview bug and be unrelated to the xnode.  I have no idea.

[Neil Pate]

So anybody want to give me a license to edit these xnodes? 

[hooovahh]

Well you shouldn't need a license to edit them, they are just XML and can be read in a text editor.  I haven't yet figured out how to link to a specific post in this new format, but the New XNode Editor 2012.zip I posted here should allow you to look at all the abilities in an XNode and do some basic editing like add other abilities.

 

EDIT:  Oh I figured it out, this is the actual post.

[Neil Pate]

I still must be doing something stupid, how do I actually made modifications to an existing (or a copy of) XNode?

I can open the ability VIs fine, but they are locked.

All I want to do is try and modify your XNode to make it accept a DVR to a variant rather than a plain variant. This is my first real foray into XNodes, so I am probably missing something obvious even though I have tried to read as much of the literature as I can.

[LogMAN]

Not sure if this helps, but hooovahh secretly explained the XNode editor on YouTube (I recommend watching the entire video btw ):

It is closely followed by a quick introduction to the Variant Repository https://www.youtube.com/watch?v=R2En7yMANi8&feature=youtu.be&t=34m44s

Wow, new Lava embeds videos now

[hooovahh]

On 4/23/2016 at 9:51 AM, Neil Pate said:

I can open the ability VIs fine, but they are locked.

This is probably because a copy of the XNode is in memory.  Just like an XControl you can't edit an XNode while it is in memory in another instance.  At least I think that is what is going on here.  They shouldn't be locked.

On 4/23/2016 at 9:51 AM, Neil Pate said:

All I want to do is try and modify your XNode to make it accept a DVR to a variant rather than a plain variant. 

Neat addition feel free to post your contribution if you get anything working.

On 4/24/2016 at 4:49 AM, LogMAN said:

Wow, new Lava embeds videos now

Super cool BTW.

[Neil Pate]

What magic is this that allows a variant to be displayed as a tree? Or am I just being really dense after a long week?

 

[Neil Pate]

OK, so this seems to be native behaviour of variants with attributes, but how did you create the Variant Tree control?

[drjdpowell]

It’s Ton Plomp’s XControl, I’d guess.