Search the Community

Hi, just a work I've done few years back, toolkit for power systems simulation. All elements are Xnodes. Cosmin

Name: Circular Buffer Submitter: hooovahh Submitted: 24 Sep 2014 Category: XNodes LabVIEW Version: 2011License Type: BSD (Most common) Description 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-1.0.0.1 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. Click here to download this file

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

TL;DR: Linux and Mac users, you can enable NI's hidden XNode development feature by adding the following line to your LabVIEW configuration file: XNodeDevelopment_LabVIEWInternalTag=True After doing this, you can create a new XNode from the File->New dialog, and edit existing ones without them just showing up as locked. Original post: LabVIEW's built-in XNode editing tools are enabled using a license file, rather than a simple INI toggle. Presumably they do this for stronger discouragement from unofficial use, as hacking one's way past that feels a lot more "shady" than just adding a line to a config file. But what about the Linux and Mac versions? They don't have a license manager, so how is XNode development enabled there? One might guess that those features simply aren't compiled into the released builds of those versions, but there is actually precedent to suggest otherwise. VI Scripting used to be similarly restricted using a license, but then they made it public. At the time, LabVIEW didn't have a toggle in the Options for it. But they didn't need to release a patch to add one. Instead, they simply published their formerly-internal license file, and set their activation server to accept requests to activate it. And yet, Linux/Mac users weren't out of luck: it turned out that for them, it actually was just a configuration key. The VI Scripting license had the internal name "LabVIEW_Scripting(_PKG)". The Linux/Mac configuration key was "Scripting_LabVIEWInternalTag". At 17:48 in this video, several XNode-related configuration keys are shown, likely found in strings in the EXE or resource files. One of them is called "XNodeDevelopment_LabVIEWInternalTag". Guess what the internal name of the XNode Development license is. I don't have the Linux/Mac version to test with, but I know a pattern when I see one. The following command was given in the readme for the VI Scripting package for Linux: echo -e "labview.Scripting_LabVIEWInternalTag:\tTrue" >> ~/.labviewrc Here are the Mac instructions: If you have either of those versions, it's probably worth a try: follow those instructions, but replace "Scripting" with "XNodeDevelopment", and see if you can open an XNode in the IDE, or create one from File->New. (Also, in the case of Mac, replace 8.6 with your actual LabVIEW version if necessary.) (Here's where I got my information about enabling scripting: https://forums.ni.com/t5/LabVIEW-APIs-Documents/LabVIEW-Scripting/ta-p/3535340?profile.language=en)

View File XNode Editor 8 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. Submitter hooovahh Submitted 03/15/2017 Category XNodes LabVIEW Version

I'm trying to read the icon of an xnode by reading the NI.Lib.Icon property, which is encoded zipped binary data of the image. This code generally works for reading any LVLib icon (note dependency on OpenG Zip Library). I've noticed that for many XNodes, the icon data looks very weird, almost scrunched up. Any ideas why this would be the case? And others look fine:

After working on the set cluster element by name xnode, it made me realize i could use the same concept to convert a variant array to a cluster. The technique is actually pretty simple, the xnode generates a case structure for each element in a cluster in cluster order, wherein a bundle by name is used to set the value and an unbundle by name is used to get the type, a variant to data is used to convert the data. This has some benefits over some methods, you are not limited to 255 elements, although that is not usually the case some of us are paranoid that clusterosaurus giganticous will be larger than expected. It also has a draw back that is that when converting from a variant array all the elements must have unique, non-blank names, and this is usually the case. I think this technique (though very brute-force) might be useful for some other things let me know what you guys think. VariantArrayToCluster.zip

This Xnode allows setting a cluster element by label string without using references. I pulled a great deal of inspiration from Hooovahhs Variant Array to cluster xnode, which i suppose this could be used for, another benefit is its not limited to 255 elements. Its mostly experimental because I haven't used it much. SetClusterElement.zip SetClusterElementLV2013.zip

I've been working a lot lately with by-reference architectures that still cooperate completely with LabVIEW's implementation of OOP and polymorphism. I've also recently taken an interest in trying to speed up development with secondary providers (similar to GOOP) to enable automatic creation of accessor VIs hidden behind the DVR, automatic creation of the private data type and constructor/destructor, etc. within the project window. I'm generally not a fan of the extra stuff that goop adds in to classes, I'd prefer to keep the source code looking as close to a normal class as possible. That said, I've started on my first ever XNode and it's a cross between an unbundle by name node and the -> operator in C. It functions just like a normal UBN, however it was also pull items out of DVRs. Having to plop down a UBN to pull out the reference from the class, an in place node to dereference, and then another UBN to pull the data out gets tiresome after about the 100th property VI gets written. So far I've gotten the node drawing completed (except for data type coloring of the labels), the type inferencing from the input wire, and the popup menu for selecting an item. Next up will be the menu selection code so that the names will finally show up in the terminals! Then I get the daunting task of scripting up the GenerateCode ability >_> Anyone interested in something like this? Following this will be a match to the Bundle by Name node that serves the same purpose except to write the items.

In response to this Idea, and to refresh my xnode coding, here's a compact form of Index Array with fixed indices (double-click to change). Thanks to hoovah for his XNode Editor! CompactIndexArray.zip

I put together a simple xnode to relabel event registration reference wires that feed into dynamic events of event structures. With the increasing use of event based messaging systems, I found myself manually changing the name of event registration references to clarify the event name when multiple event registration references were used in an object. I did this by manually creating a cluster constant on the build cluster before the dynamic registration terminal on the event structure and renaming each registration reference. Being a lazy programmer, this seemed tedious after a few times so I decided to attempt to create an Xnode to accomplish the same thing faster. This video shows the "problem" and the potential solution using the xnode: Re-Label Xnode - Event Registration Here's another example showing another use case with ShaunR's VIM HAL Demo code: Re-Label Use Case ShaunR HAL Demo This may have been done before or there may be an easier way to do this, but I wanted to throw it out here to see if there's any interest and to see if people will try it out and give feedback. I've found it works best using quick drop for initial use (highlight wire, CTRL-Space,type re-label, CTRL-I, type new name in dialog) and for replacing or renaming an existing instance on the diagram (highlight existing xnode, CTRL-Space, type re-label, CTRL-P, type revised name in dialog). You can also use directly from the palette, but I found much faster from quick drop and also seen a couple crashes replacing through the pallete. The Double Click ability is also a work in progress. Its purpose is to allow you to quickly rename the relabel with the same dialog box, but when it executes it breaks the wire on the output connection. You can still re-wire it to the event structure, but you will have to open the Event Structure Edit Events menu to get the event to "Re-link". Something I'm trying to avoid. The Xnode generated code is simply a pass through wire with the output terminal renamed to the label of your choice. This seems to update attached event structures. - B sobosoft_llc_lib_diagram_tools-1.0.4.1.vip

Name: Find References XNode Submitter: hooovahh Submitted: 03 Feb 2015 Category: XNodes LabVIEW Version: 2012License Type: BSD (Most common) Description 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. Demonstration 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. http://screencast.com/t/gFBen503rg XNode Disclaimer 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). Dependencies OpenG Error Library-4.2.0.23 OpenG Array Library-4.1.1.14 OpenG String Library-4.1.0.12 OpenG LabVIEW Data Library-4.2.0.21 Click here to download this file

Hey guys, I'm trying to do some scripting on a Realtime-VI wich uses the FPGA Interface "Read/Write Control". I open a Reference to a VI containing a Read/Write Control, and when scrolling through the BD-Objects I find it with the class-name "nirviReadWriteControl". I used the "to more specific class"-VI to check wich class i can cast it to, and i tracked it down to be child of the GObject->Node Class. But i can't cast it to any of the childs offered in the class specifier constant. I also found out, that the "nirviReadWriteControl" is a xnode. I have never worked with those, is there a way to access theyr methods (I think they're called "abilities" for xnodes)? The goal of the application is to make the Read/Write Control display all available FPGA FP-Elements, and connect Controls/Indicators to them. There is the same Problem with the "Open FPGA Reference"-Node (Classname "nirviOpenFPGA"). I really hope somebody dealed with the xnodes a bit and can help me programmatically controlling them! Best, Trip

A while ago I developed an Xnode that has an ondoubleclick ability which opens up a configuration window. I noticed that every time that ability was called, even if you immediately closed out of that configuration window that it would produce a dirty dot in the owning VI. This seemed to happen with the ondoubleslick and onoperateclick abilities even if there were no replies or added code to the abilities themselves. I attached my Xnode which demonstrates this behavior. I was wondering if there was any way to prevent a dirty dot in the owning VI if nothing has changed in the Xnode's state or generated code. -Matt J Random Xnode.zip

Name: VIM HAL Demo Submitter: ShaunR Submitted: 25 Sep 2015 Category: *Uncertified* LabVIEW Version: 2009License Type: MIT This is an experimental demo to investigate VIMs (vi macros). It was a bit of fun to see if VIMs could be used to encapsulate events in LabVIEW which was a bugbear of mine for quite some time. You can see the entire thread here. VIMs are a NI experimental technology similar to Xnodes but less mature. The purpose of this release is to clarify the previously unstated licence since other forum topics are building on the original demo so they need a permissive licence (MIT). This release serves as an unambiguous statement to that effect. There are a few differences from the original which I have decided to call version 0.1 but they are minor. Note: This may or may not work for you out of the box. If it doesn't then please do not post. The purpose is to clarify the licence for others to build upon; not to provide a working example. The VIM technology is itself experimental and unsupported by NI so most issues you will encounter will be due to this and It is unlikely there will be another version posted here. Click here to download this file

Hello my fellow XNode scripters, I recently ran into an issue developing my latest XNode. I want to break certain wires connected to my xnode, based on the results of the "GenerateCode" ability. Basicially I generate the code, check certain wires in that code and if they are broken, I want to break the corresponding wires to my XNode. But LabVIEW keeps ignoring my "UpdateTerms"-reply in the GenerateCode ability. Has anyone else had a similar problem and probably solved it? Interesting fact: the reply "UpdateImageAndBounds" is also ignored, whereas the reply "UpdateImage" is processed correctly... Merry X-mas, Sebastian PS: The XNode I am working on is basically a wrapper around the FormatIntoString() node, that accepts (nested) clusters and simply unbundles them (recursively). See attached screenshot. When this and some other minor issues are solved, I will publish the XNode here @LAVA.

Hi guys! I'd like to have my XNode to behave differently when the input is a (strict) typedef but also differently according to the typedef path (or name) if any. In a regular VI, this is easily done by extracting the path of the typedef: Terminal>Control>TypedefPath, but in Xnodes it's another story! So far I managed to get the regular type in the 'AdaptToInputs' ability (which is the common use of this ability!) and to see if it is a typedef or not by reading the properties of the control in the 'GenerateCode' ability. But in this last ability VI, an error occurs when I try to obtain the TypedefPath (Error 7). This error apparently occurs in Xnodes and especially Express VIs when "one of the internal paths is hard coded incorrectly" Is there a limitation due to the XNode or else? I guess that I could get around the problem by scripting the owning VI and retrieve the typedef of the control connected to the XNode directly but it would be quite cumbersome and ugly. Any thoughts on the subject?