LabVIEW Bundle Magic Plugin
Watch a video showing what BundleMagic can do.
Bundle Magic is a LabVIEW plugin that augments right-click menu options for manipulating by dialog:
A dialog is presented to search and select cluster items, properties, methods, and LabVIEW classes, automating the placement of bundle- and unbundle-by-name nodes, property nodes, and invoke nodes when clicking on the appropriate terminals or wires.
You can also add, remove, or rearrange elements from bundle- and unbundle-by-name nodes and property nodes; browse and change methods on invoke nodes; and select and apply class types for LabVIEW class constants.
Zyga's Insert Bundle By Name was the primary inspiration for this plugin. That inserts one item at a time through a tree of flyout menus, and I saw in this an opportunity for improvement. I borrowed some code in order to learn how to get a data type from a wire. Thank you.
The code used to rearrange named un/bundle/unbundles while preserving wiring was modified from Alexander Sobolev's Drag Bundles Quick Drop called DragBundles, and corrects a bug there which does not always preserve wire branches during cluster rearrangement.
Function Overview
Block Diagram |
|||
Block Diagram Objects Affected |
Right-Click Menu Options |
Has Dialog? |
Notes |
Cluster Source Terminal Class Source Terminal |
Bundle... |
*Y |
|
Unbundle... |
*Y |
||
Cluster Sink Terminal Class Sink Terminal |
Bundle... |
*Y |
Creates a constant if unwired and selected without a corresponding source terminal |
Unbundle... |
*Y |
Only allowed for wired sink terminals |
|
Cluster Wires Class Wires |
Bundle... |
*Y |
Inserts named bundler on wire |
Unbundle... |
*Y |
Inserts named unbundler on Wire |
|
Unbundle By Name Element Terminals Bundle By Name Element Terminals |
Add Elements... |
Y |
Click on a specific output terminal to add items before or after that terminal |
Remove Elements... |
Y |
||
Remove Unwired Elements |
N |
If all elements are unwired, the last element will remain after this function executes |
|
Rearrange Elements... |
Y |
Change order of elements in un/bundler node |
|
Refnum Terminals Refnum Wires |
Drop Properties... |
Y |
Drop Property Node and connect to terminal or insert property terminal on wire |
Drop Method... |
Y |
Drop Invoke Node and connect to terminal or insert Invoke Node on wire |
|
Property Node Element Terminals |
Add Properties... |
Y |
Insets properties before or after the clicked property. If only the default element is displayed, this function will replace the default element |
Remove Properties... |
Y |
Select items to remove from the node |
|
Remove Unwired Properties |
N |
||
Rearrange Properties... |
Y |
Change order and./or read/write of displayed properties in node. Setting R/W status of an element to false will remove the element from the node. |
|
Invoke Node |
Browse Methods... |
Y |
Set method of Invoke Node |
Class Constant |
Browse Classes... |
Y |
Change class of class constant |
Copy Class Name to Clipboard |
N |
||
Front Panel |
|||
Refnum Control |
Browse Classes... |
Y |
Change class of refnum control |
Outstanding Issues
Installation
Bundle Magic requires a patch to the LabVIEW core, so manual installation is not recommended. Use the supplied VI Package Manager installer.
Planned Improvements
Properties and Methods dialogs can be slow to load because they are built on the fly from a list of all available properties. Prebuild all properties and methods by data type.
Known Issues
Author: Russell Wagner, Little Sphaeroid Design
Looks nice.
I haven't tried it yet, but a couple of suggestions:
OK, now that I looked at this a bit more, I am impressed with the amount of work. One thing specifically I was looking at, after I saw you said you can insert properties, was whether this supports properties for nested objects, and I was surprised to see that it did. I went spelunking inside to find out how you did it, and while it's convoluted, the important thing is that it works and I don't think there is any more practical way of doing it.
For those wondering, the basic idea is to start with a VI with a class specifier constant and a couple of property nodes chained from it, get the classes from the constant, make a tree out of them and then iterate over that, set the constant to the specific class and set the first property node to each of the properties. If the data type of a property is a refnum, then check the second property node to get the dotted properties. Then save all of that, so that it's cached.
A couple of feature requests:
Very interesting plugin and useful. Congrats.
I noticed it works with OOP as well.
Although I noticed the plugin is about 7 MB, is this correct? Does anyone know if it impacts on LV Performance? Or is it ok after compiling?
Regards,
felipe.foz wrote:
Although I noticed the plugin is about 7 MB, is this correct? Does anyone know if it impacts on LV Performance? Or is it ok after compiling?
I have not investigated this particular LLB, but I wouldn't worry. The design of the right-click framework is such that only the builder VI loads to build the menu. These are typically very small, single VIs. The bulk of any of the LLBs is the execution VI, which is only loaded if/when you actually pick that menu item. I have some fairly complex builder VIs shipping with LV -- see the channel endpoint creation menu items, if you're interested -- and we are still quite far away from breaking the 10th of a second response time between right-click and menu appearance that is what humans tolerate.
As long as the developer of the LLB turned on source-only on all the VIs in the LLB, you should be fine after the first right-click. If they did not turn on the source-only setting in VI Properties, then you could have a recompile hiccup on every right click that includes that menu item. As a general note, I strongly recommend that everyone except TestStand (ab)users* turn on source-only settings on all existing VIs and enable the Tools>>Options setting to turn it on for all future VIs.
* By which I mean the people who want TestStand to load loose VIs (i.e. VIs not built into a PPL or DLL) into the run-time engine (instead of calling the IDE). It's a seriously problematic model of operation for LV, but it is very common among TestStand users.
@AristosQueue wrote:
I have not investigated this particular LLB, but I wouldn't worry. The design of the right-click framework is such that only the builder VI loads to build the menu.
Thanks for the reply.
As long as the developer of the LLB turned on source-only on all the VIs in the LLB, you should be fine after the first right-click. If they did not turn on the source-only setting in VI Properties, then you could have a recompile hiccup on every right click that includes that menu item.
That was I thought originally. I didn't check about this option inside the llb either, but it appears to be very responsive after the first click.
Hi. Thanks you very much for this magic tool. Impressive work.
I have just find one small bug. When i try to Bundle or unbundle cluster with one Class as element in another place than first , your tool always create first element (AK.Bool). However the class is correctly display in dialogbox and correctly select i think.
It's not very critic bug, but better without.
Thanks again
Eric
Hi Russell,
thanks for that powerfull tool! 😀
Unfortunately I do get a reproducible LabVIEW crash 😖 when I use the Insert Elements... on an already wired bundle node of an actor class.
Im using LabVIEW 2020 32bit on Windows 10 Enterprise 64bit
Crash Info:
Similar crash when using Remove Elements...
When using Insert Elements... on an already wired bundle node of a simple class then nothing happens for a few times and then still a crash:
Remove Elements... works on simple class.
Remove Unwired Elements always works.
Do others have similar problems?
Is this a LabVIEW bug or a bug in this Plug-In?
Thanks & Regards,
Luxamor
code-lux: The fact that it is crashing means it is a LabVIEW problem. As I've said often over the years, the only two sources of LV crashes that are not LabVIEW's fault are calling external code (Call Library Node, .NET nodes, etc) or the Type Cast primitive casting refnums (you lie about data types, there's not much LV can do to check it until it is way too late!).
I'll flag a tech support engineer to replicate your bug report and get it filed to R&D to investigate.
Meanwhile I found out a main cause of the problem: I had a control in the class private data that contained a point (.) in its name.
I noticed that Bundle... and Unbundle... would not work as soon as I included that control with the point.
Now that I removed that point (.) I do not get imediate crashes anymore - but Insert Elements... still does not work and eventually causes a crash (like discribed above for simple class).
I added a "Request Deallocation" function to the block diagram of the "LSD_Get All Properties_3.vi" and the crash went away. Not sure why the 'Insert Elements' menu option is no-opping but that's likely something that will need to be debugged in the plugin scripting code.
Thanks for a very useful tool! I've been using it for a few months and am impressed with how useful and polished it is.
One of my favorite plug-ins! I discovered one "quirk" that I'm not sure is a bug or if it's functioning as designed. The "Remove Unwired Elements" also removes elements with broken wires. Personally, I would prefer that connections to wires with errors remain, just as in the "Remove Unused Terminals" plug-in https://forums.ni.com/t5/LabVIEW-Shortcut-Menu-Plug-Ins/Remove-unused-terminals-llb/ta-p/3517977. Also, just a cosmetic comment - shouldn't there be a divided after the last item, "Rearrange Elements..." ?
I added a "Request Deallocation" function to the block diagram of the "LSD_Get All Properties_3.vi" and the crash went away. Not sure why the 'Insert Elements' menu option is no-opping but that's likely something that will need to be debugged in the plugin scripting code.
The "Insert Elements" for a class is not opening because the "Get Cluster Information.vi" in "LSD_Traverse_Cluster.vi" cannot access the private data and the returned array of cluster elements is empty.
There is surely someway of getting the private data elements with vi scripting and adding a cluster/class check there.
> There is surely someway of getting the private data elements with vi scripting and adding a cluster/class check there.
Not really. There are some complicated approaches I've seen some people take, but the whole point of it being private data is that it's private.
>> There is surely someway of getting the private data elements with vi scripting and adding a cluster/class check there.
>Not really. There are some complicated approaches I've seen some people take, but the whole point of it being private data is that it's private.
However, not having access to the private data makes it impossible to e.g. serialize the data, without violating the single responsibility principle. It's quite a pickle.
Getting the private data elements isn't that hard (hint: myclass.lvclass has a control myclass.ctl). Esp. in development simply getting the controls, the first is the cluster, and use controls again, works OK. In an exe, you can't use that, but Get Controls By Index still works, unless the cluster is empty (then it's very slow)... Of course you have to traverse all parents.
Flattening (to JSON, to XML) only works when the data isn't default...
I found a repo for BundleMagic on github: SqueakyFloors/BundleMagic: LabVIEW plugin for Un/Bundle, Method, and Property node manipulation (git...
Which branch would be best to start looking at if want to add fixes or new features (QuickDrop Integration)?
HI JoGra, I am preparing a new release (hard to find time, but I've made a lot of improvements!), and would love your input. Let's discuss how to collaborate.
v1.1 of BundleMagic is now available.
New Features
Bug Fixes
Changes and Improvements
The class-related bundle issues you noted are not resolved in v1.1, @JoGra. However, since it is already possible to get the class elements for the Bundle and Unbundle functions of the plugin, I suspect that getting the Insert Elements... feature to work on class bundler nodes is possible. I have added this as an issue to the git repository.