Leaderboard

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've developed a few experimental XNodes to assist with running VIs asynchronously. The ones pictured here are LV-Async.xnode and LV-Await.xnode. You can drag a VI onto LV-Async. It will open or check out (more on this later) a VI reference with code x100. LV-Await.xnode will Wait on Asynchronous Call, but instead of closing the reference it will check it in to a lookup table to be later used by LV-Async.xnode. The benefit of this is that when used with a reentrant VI, the asynchronous hierarchy will not go idle, so reference types created in the hierarchy will not go bad. There is an example in the VI package that demonstrates this behavior. The downside is that the memory the hierarchy uses does not get freed (subsequent async/await calls do not leak memory though since the hierarchy is being reused). LV-Async-And-Forget.xnode opens the VI reference with code x80 and closes it after running the VI asynchronously. LV-Async-Or-Show.xnode is meant for non-reentrant UI VIs. If the VI's front panel is not open, it will run the VI with option x80. If the front panel is open, it will bring the front panel to the front. Attached is a VI package that will add these nodes to your palettes, along with a couple package dependencies. Source code for LV-Async is here: https://github.com/erdosmiller/lv-async LV-Async requires LabVIEW 2015 or later. Let me know what you think! lv_async-1.0.0.12.vip lv_scripting-0.7.0.6.vip lv_vi-0.0.0.5.vip

Attached is a VI Package that will add LV-Control-Refs.xnode to your palette. This node, when dropped on the block diagram or double clicked, will update its output to a cluster of references to all controls in the VI. Controls in tabs show up as <Tab Control Name>:<Page Name>.Control Label. Nested tab controls with arbitrary depth are supported. You can bind the output of the node to an existing typedef by right-clicking on it. I've used this node for awhile, but the tab support was added very recently and was a significant change. I've also attached a scripting library I maintain that this XNode depends on. And source for the scripting library is here: https://github.com/erdosmiller/lv-scripting I wrote this node because several times I've found myself bundling nearly all the control references in a VI into a cluster. It requires LabVIEW 2015 or later. Let me know what you think! lv_scripting-0.7.0.6.vip

We have upgraded sausage to ribs! Every time I work on this I get hungry. Mmm, ribs...

This is an experimental set of XNodes that puts a set of values in a DVR, lets you access them, and generates user events when one of the elements changes. LV-Create-Signals.xnode takes a cluster at the input, and outputs a cluster of a DVR with the input cluster in it, and an event for each element in the cluster. The output can be bound to an existing typedef by right-clicking on the node. The data is accessed via LV-Read-Write-Signals.xnode. It's similar to a property node, and allows access to cluster elements, array elements, and array subsets. If you write an element and change its value, the corresponding event is generated. Attached is a VI package that will add these nodes to your palette, along with a scripting library that these nodes depend on. LabVIEW 2015 or later is required. The source code can be found here: https://github.com/erdosmiller/lv-signals I made these because I commonly use a DVR & user events for exposing data from a module. Let me know what you think! lv_signals-0.0.1.7.vip lv_scripting-0.7.0.6.vip