Leaderboard

I'm rather fond of applying behaviours en masse via callbacks. Ctrl CB.zip

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

Yeah another XNode question. This isn't a need but I think it would be a nice feature if it can be done. Has anyone thought of a way to have an XNode behave like other primatives, where the init defines the data type to be used, and the other functions know the data type and change their output based on it? So lets say you drop a Obtain Queue and wire a string to the Element Data Type terminal. Now when you use the Dequeue Element, the output changes to a string. Also the wire color changes but I'm less concerned with that at the moment. The first step in this I thought would be easy but I was wrong. I made an XNode where it has an input terminal that is adaptive. I planned on wiring to this a queue and then having this XNode change the output based on the queue data type. But to get the queue data type I need to read the terminal type which gets returned as a variant, then cast it to a queue, then use a function like preview queue and use the type of the output of that. The problem is to cast the variant to the queue, you need to know the type of queue it is. I think there are a few more tricks I could try but I was curious what others thing. Anyone done this? Anyone got any ideas?

You wouldn't happen to be freemason would you? In any case here are some links I just gave out for doing SVN stuff. https://decibel.ni.com/content/groups/large-labview-application-development/blog/2010/03/29/using-subversion-svn-with-labview Ultimatly it is what ever works best for you, but this is a good start. Oh here are a few other articles that have very good information, but some of it looking dated showing older versions of SVN. http://thinkinging.com/category/tortoisesvn/

source control. try svn, git, or any other flavor you like. I like tortois svn myself.

Do either of these help? (I have no clue why there are two, they're basically the same ) http://digital.ni.com/public.nsf/allkb/410F2EC66F60F9B0862569EE006F4FA0 http://digital.ni.com/public.nsf/allkb/705C2ECA081F3C7986256C0F00559B02?OpenDocument The real question I have to ask is if you need the call to be dynamic, or just asynchronous? If it does not need to be dynamic, just use a static VI reference. This will ensure app builder finds, includes, and loads the appropriate code into the exe. This is what many of the labview examples do, so take a look in the example finder (specifically the section on controlling applications programmatically, which is code for "VI server"). If it absolutely needs to be dynamic, then you're better off following the KB steps to set the VI in question (St1-TCP.....) as always included, specify a specific folder relative to the exe (for example ../dynamic dependencies), and use a relative path rather than the fixed path you have there.

OMG. I just read through this thread in its entirety. My opinions on many LAVA members has been irrevocably changed. I almost wish I had never read the entire thread. The thing which popped into my head most while reading this thread was the following link. http://en.wikipedia.org/wiki/List_of_fallacies Shane.