Leaderboard

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

Aside that it looks awful if you do not have a least a 60 inch screen, you never let the loop terminate programmatically. So to terminate your program you have to abort it. That does NEVER let the Close VISA function execute and your port stays open until you shutdown LabVIEW.

Shaun's probably right, but in case you do need to sign-extend, one approach is this: http://forums.ni.com/t5/LabVIEW/24bit-hex-to-2-s-complement/m-p/1686050#M599007

It's a gift. Or at least you should look at it like that. I call it the Aura of Technical Doom - an innate ability to break anything technical sometimes just by mere presence. If you are a quality engineer with this special power, you are feared by corner-cutting engineers far and wide. These special people are also the bane of demonstrations and usually illicit the phrase "it was working earlier" from other engineers and sales people

That is a picture of a VISA control allowing you to select a COM port for some operation. What is your problem?

I like her - that girl's got moxy. Although I'm wishing I hadn't have donated all of those ribbons to here - Otherwise I would have reached the floor by now. Oh well, I guess I'll have to come back next year.

I have created a plugin for the Task Manager that can be used from inside an executable, thanks to Michael and his guide to Plug-in Architecture using Packed Project Libraries. If you aren't familiar with PPLs, I'd highly recommend at least a quick glance through this guide. LabVIEW Task Manager Application.zip I took Mike's example and created a plugin that launches the task manager. You can add it to your application as an Easter Egg (set it to load on some secret key combination). You don't have to distribute this plugin with your application, but if you are called to debug something on a deployed system, you can just take this plugin, drop it at the designated place (same as the exe in this example) and enter the key combination to launch it from within the application. To see this in action, launch ..\LabVIEW Task Manager Application\build\testApp.exe. If "LabVIEW Task Manager.lvlibp" exists in the same folder as the exe, your key combination will bring it up.