I think I've finalized my example for the XNode UpdateState ability.
This is a very important ability. Failure to properly manage the update process can have dire consequences.
Here are some of my XNodes, packaged by Brian Hoover.
One of the difficulties with editing XNodes without the license is that invoke nodes for the XNode class don't show any methods.
This XNode acts pretty much like a real Invoke node, but it allows access to all possible methods.
You can also right-click and replace it with a real Invoke node.
By hooovahh8 Years ago the first version of the XNode Manager was posted to the code repository in an attempt to allow the editing of XNodes. Being a fan of XNodes, but knowing that the XNode Manager is pretty limiting because of its age, I set out to make a new version with similar functionality.
The XNode Manager had a blank XNode, and blank Abilities that it just made copies of. This is fine but then the abilities and XNode are quite old. There were many new Abilities added since version 8.2 and you can't add them using the XNode Manager. My XNode Editor reads your LabVIEW resource and populates the list of abilities to create from the ones that are possible to create. Then VI server is used to create the XNode, State control, and Abilities. This sets up the connector pane like it should and should work with all future versions of LabVIEW, until NI changes something that breaks it. It also reads in the XNode Ability descriptions to help understand how to use the new ability VIs.
In addition to being able to create and edit XNodes, you also can edit the XNode icon, and description, along with adding any new abilities.
Be aware this uses several private functions, and several undocumented features that could be potentially bad. I did a decent test to make sure memory leaks weren't a problem and I made several XNodes and Abilities and it seems stable. But at the end of the day if it blows up and crashes, don't be surprised, you've been warned. The original thread with discussion and progress on this tool was started here.
By hooovahhDescription This package contains functions for maintaining a circular buffer. Create the Circular Buffer using the Initialize Circular Buffer function. This makes a DVR, and the data type of the DVR changes based on the data type specified for the circular buffer. The data type can be any type as long as it is not an array. It must be a scalar. The size of the buffer is specified on initialization but can be changed using the Change Circular Buffer Size function. Add data to the circular buffer using the Write Circular Buffer function. Scalar values can be added, or a 1D array of data can be added. The data type of the values to be written is the data type defined in the initialize function. Read the data back out of the circular buffer using the Read Circular Buffer function. The data type of the read values will be the data type defined in the initialize function. Cleanup the program by destroying the DVR on exit. An example VI Circular Buffer Demo shows how a Circular Buffer can be used. XNode Disclaimer The Initialize, Read, Write, Get Status, and Change Size 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 LAVA Palette-220.127.116.11 How It Works The source is all open and the template VIs for each XNode is what is executed when the XNode is generated. This means you are welcome to try to further optimize these XNodes by editing the templates. A new instance of the XNode will need to be placed which will force the new code to be used. If anyone finds performance improvements for these functions please feel free to post in the support topic. Because the size of the buffer is practically unbounded, I wanted to avoid unnecessary data copies, which is why it is designed around DVRs. There exists 3 things in the DVR, the buffer size, a pointer to the current write location in that buffer, and the array of scalar values, whos data type is defined during the initialization.
This zip contains an XNode which makes finding references to objects easier. The core of the attached XNode is a modified version of the Find References by Label VI that can be found in the vi.lib. This VI will return the first match of a control that has the label provided. This modified version has the ability to find all references that match a label given a string which the label contains, starts with, ends with, or it can be an exact string. So for instance it can find all objects that start with "Numeric".
This XNode still has the ability to return a single scalar reference like the original, which can be done by right clicking the XNode and un-selecting "Find All References". By default it returns an array of references found.
If multiple references are chosen, the order of those references can be changed. An enum is used to change the sort method from String Sort, Numeric Sort, Sort from Left to Right, Sort from Top to Bottom, or Sort from Top to Bottom then Left to Right. This is most useful when you have controls on a front panel arranged in a grid.
Another improvement over the native function, is the output reference type is changed to a selected class. Right click the XNode and go to Select VI Server Class to select an object type. There is also a browse button which brings up a dialog where the list can be alphabetized, and a simple string can help find the type desired.
Other features of the native function are still provided like using caption labels on controls, and searching the front panel, block diagram, or other owning reference types.
Below is a video showing the basic operation of the XNode. It demonstrates how to find control references, and how the sort, and search features work. It then shows that the same technique can be used to find any object type on the block diagram too.
NI does not provide support XNode development. It is an experimental technology and neither I, nor NI can be held accountable for unexpected operation.
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 Error Library-18.104.22.168
OpenG Array Library-22.214.171.124
OpenG String Library-126.96.36.199
OpenG LabVIEW Data Library-188.8.131.52
By hooovahhDescription 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-184.108.40.206 OpenG Variant Configuration File Library-220.127.116.11 OpenG String Library-18.104.22.168 OpenG LabVIEW Data Library-22.214.171.124 OpenG Error Library-126.96.36.199 OpenG Array Library-188.8.131.52 LAVA Palette-184.108.40.206 Variant Repository-220.127.116.11 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.
By gb119OpenG Array XNodes v18.104.22.168 by University of Leeds
Author: Gavin Burnell
Copyright: Copyright © 2011, University of Leeds, 2002-2007 Cal-Bay Systems, Inc., Jim Kring. 2006-2007 MKS Instruments, Inc
Compatible LabVIEW Versions: >= 2012.
Compatible OS Versions: ALL.
This package simply reimplements the OpenG Array tools as a set of XNodes. This has the advantage that any array time (apart possibly from arrays of LVOOP classes) can be worked with rather than just those that have polymorphs in the original OpenG versions. The disadvantage is that you can't inspect the code, but it's the same honest !
What is an XNode ?
An XNode is a type of LabVIEW library (like a LVOOP class, XControl) that defines a collection of vis that provide on-the-fly scripted nodes on on the block diagram in LabVIEW. In other words, they allow you to create a node whose code is generated programatically as it is dropped on the block diagram or when inputs are changed. This allows the developer to simulate some of the effects of LabVIEW's builtin primitives such as polymorphism, node resizing and edit time configuration.
Unfortunately, it is not possible to edit XNodes in the regular IDE (unless you work for National Instruments) as they are locked in the IDE. However, the individual vis are not necessarily locked and either by editing the xml file of the XNode directly, or with the help of some third party tools listed below, it is possible to edit and implement new XNodes.
For a fuller introduction, you are rrecommend to read Adam Rofer's "XNodes - A Crash Course" presentation (http://lavag.org/files/file/56-xnodes-a-crash-course-powerpoint).
For developing XNodes I use (a slightly modified) XNode Manager by Aitor Solar (http://lavag.org/files/file/57-xnode-manager).
There are also a couple of ini file settings that make it easier (but still not trivial) to debug XNodes:
At all times remember that XNodes are not a supported technology as far as NI is concerned (as of LV 2010Sp1 anyway) and you should expect neither sympathy nor support from NI if bad things happen as a result of using them.
The algorithms used in this toolkit are taken from:
oglib_array v3.0.0-1 by OpenG.org
Author: Jim Kring <firstname.lastname@example.org>, Doug Femec <email@example.com>
Copyright: 2002-2007 Cal-Bay Systems, Inc., Jim Kring. 2006-2007 MKS Instruments, Inc. All rights reserved.
The array package contains several routines for operating on array data.
By gb119lava_lib_LabVIEW_API_array_xnodes v22.214.171.124 by University of Leeds
Author: Gavin Burnell
Copyright: Copyright © 2014, University of Leeds
Compatible LabVIEW Versions: >= 2012.
Compatible OS Versions: ALL.
This is a collection LabVIEW 2012Sp1 XNodes.
XNodes are a hidden and unsupported feature in LabVIEW >8.x. As such, this code may not necessarily work in versions of LabVIEW > 2013 and the technology is not supported by NI. On the otherhand they are really quite useful.
Because XNodes are scripted at edit time they offer a form of polymorphism far superior to polymorphic vis as they will support any array type and not just ones that the developer has provided polymorphs for.
This package contains the following XNodes:
* Array Dimension Array
This XNode operates in a fashion similar to the Array size primitive Xnode except that it always returns an array
of sizes of dimensions. For a 1D array, this is an array with 1 element, for n-D arrays where n>1, this is the same as the primitive and for scalar inputs, returns a zero length array.
* Array Dimension and Index
* Array Size and Unbundle
These are slightly different versions of the same XNode. It will take in an n-dimension array and return N I32 outputs with the dimensions of the input array. Array size and unbundle is perhaps the better named version.
* Array Dimension
This is equivalent to the Array Dimension Array coupled with an Index Array node to return as an I32 the specified dimension of the input array. If the specified dimension is greater than the dimensionality of the input array, -1 is returned.
* Filter Array
This XNode splits the input array into two sub arrays according to a boolean array input - one for elements where the boolean filter was true and the other where the filter was false.
* Foreign Key Sort
Sorts one array based on the sort order of a second array - useful when you have an array of items and an array of keys and you want the first array elements in order of their keys.
* Shuffle Array
The inverse of an array sort - randomises the order of the elements of an array. For 2D arrays it can randomise either the rows, columns or both rows and columns.
* Unindex and Unbundle.xnode
Performs the inverse of Index and Bundle Cluster Array. Takes an input array of clusters and un-indexes and unbundles each cluster and returns arrays of each element of the original clusters. This is equivalent to feeding
a cluster array into a for loop with auto-indexing turned on, unbundling all elements, and wiring back out of a for
loop with auto-indexing turned on in order to generate arrays of each element.
* Minimum Array Size
This XNode will take the input 1D array and either make it at least n elements long, or exactly n elements long. If additional elements are needed, the default value for the element is used and the new elements are appended to the end of the array. For the fixed-size variant, if elements are to be removed, they are removed from the end of the array.
One of the palette entries is (a bit) broken: Array Dimension and Index appears as "Help" in the palette, but otherwise works fine.
By psdvAutomatic Input Output Xnode_Adapt v1.0.0
Copyright © 2009, Variant Sistemi, IT
All rights reserved
Author: Pasquale Scotto di Vetta
LAVA Name: psdv
Contact Info: Contact via PM on lavag.org or email firstname.lastname@example.org
Diagram Password : zxcvbnm ---> If you are not experts XNode forget the code :-)
XNodes are a hidden and unsupported feature in LabVIEW 8.x. As such, this code may not necessarily work in versions of LabVIEW > 8.2 and the technology is not supported by NI. On the otherhand they are really quite useful.
This Xnode is useful becouse automatically adjusts the output terminal, in according to previously set with the mode SetData.
There are two operating modes selectable from the right click on Xnode popup-menu
Read Mode :
you can select Attribute via right click popup-menu in this way the output terminal will automatically adapt.
Write mode :
you can add Attribute via double click on Xnode, A dialog box in which you enter the name of the terminal connected to the "value in"
Installation and instructions:
To use the XNodes, place the *.xnode files in a labview Diagram.
Example folder find Example.vi. This example shows how does the XNode Mode Read and Write
v1.0.0: Initial release of the code.
v1.0.0: added readme.txt
NOTICE -- YOU MUST LEAVE THIS NOTICE IN PLACE. PER THE TERMS OF THE LICENSE BELOW, YOU MAY SUBLICENSE THIS SOFTWARE
IN ANY WAY THAT DOES NOT CONFLICT WITH THIS LICENSE.
BSD License (http://www.opensource.org/licenses/bsd-license.php)
If you have any problems with this code or want to suggest features:
please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and
search for the "Automatic Input Output Xnode_Adapt" support page.
This code was downloaded from the LAVA Code Repository found at lavag.org
By Aitor SolarCopyright © 2007, Aitor Solar
All rights reserved.
--see readme file for contact information.
This is an application for creation and management of XNodes. The program allows to open or create XNodes, to add or remove abilities and to easily access the ability VIs. It's prepared for all the LV82 abilities.
The application requires the Internet Toolkit for LabVIEW 8.2
1.5.2: Added managament of the XNode icon.
1.5.0: Added descriptions for the XNode (read/write) and the abilities (only read).
1.4.3: Now, removing an ability also disconnects the VI from the XNode Library. Solved the "absolute path" bug.
1.4.0: Initial release in the Repository Code
By AdamRoferThis was presented at the 02/22/07 LAVA meeting.
Discusses the various aspects of both XNodes and External Nodes, shows comparisons, and shows example usage.
I ended up skipping over two of the "Creating XNodes" pages since Aitor Solar's XNode Manager is a much better place to create your XNodes with.
View the comments page
By mike_spacexCopyright © 2006, Mike Lacasse
All rights reserved.
--see readme file for contact information
To use this VI: Put it in the same directory as the VI you want to "wrap" and rename this VI to ";Dxxx_targetVI.vi" where 'xxx' can be anything, and 'targetVI' is the name of the VI you want to "wrap". The target VI must have a 'type' input terminal and a 'data' output terminal (these can be wired anywhere on the connector pane).
Now you can drop this VI on block diagrams instead of your target VI. The 'data' output terminal will conform to be whatever datatype is wired to the 'type' input. Your target VI will still appear in the VI Hierarchy as a subVI. Double-clicking this node on the block diagram will open the target VI..
This is accomplished within the xnode by altering the terminal specifications and by typecasting the output data from the target VI to the datatype wired to the 'type' input.
Much of this implementation was done in LabVIEW 7.1 using VI scripting which is available by adding the following lines to LabVIEW.ini:
Here's the disclaimer:
DO NOT contact NI for support on VI Scripting.
DO NOT use these features for released code or applications to your customers.
DO NOT count on the implementation to stay the same for future releases of LV. It will change and your code will not be upgradable.
The code is pretty well commented. White text boxes describe how the xnode functions. Yellow text boxes are implementation details.
Thanks to Adam Rofer for the XNode documentation available at
- In LabVIEW 8, the VI description doesn't update correctly from the target VI. It works in LV7.1 to get the target VI's description to show up in the context help window, but not in 8. Not sure why.
- Terminal Labels don't appear in context help window. The icon image of the subVI is succesfully copied, but not the terminal labels. This would be a nice fix. 'Get Conpane Image' gets what I want from the target VI but there is no 'Set Conpane Image'.
- Is there any way not to require ';Dxxx_' in the VI name, but still have it work right?
- If the target VI is not executable, the errors list only says 'External Node: Code could not be generated correctly for this VI'. Thats not very helpful.
- Still working on finding a way to automatically rescript the xnode when changes are made to the target VI. This would be nice so if a control or indicator name is changed on the target, the terminals on the xnode will be renamed accordingly.
Initial release of the code.