Lock un/bundle by name functions

[PhilipJoeP]

I am having an annoying problem because of my implementation.  I’m creating a sub-VI that will accept a cluster type def with named numeric control signals.  The code of the sub-VI will not change, but the cluster type def might change.  (“Change” meaning that the ordering of the elements within the cluster might not be consistent and the element names might vary slightly... “New_Time” might change to “NewTime”)

The problem I’m having is that when this cluster type def changes, the bundle by name and unbundle by name functions within the sub-VI will sometimes randomly pick new signal names to bundle/unbundle.  (Specifically, it will just pick a different signal element in the cluster.)  This is a problem because it doesn’t appear as an error in my code.  My code will execute, but just not correctly.  And then comes the long effort of searching through my sub-VI and fixing all the bundle and unbundle functions.

My question is this… Is there a way to lock the bundle/unbundle by name functions such that if a type def changes it will throw an error (if it can’t find the exact signal name in the type def) and prevent the VI from executing (in lieu of it just picking a different signal to work with?)

 

Thanks

[NitinD]

If you're not changing the ordering within the typedef cluster, then you'd be better off using 'unbundle' compared to 'unbundle by name'

[tst]

Which version of LabVIEW are you using? I believe that this should be considered a bug and that it should have been fixed in recent versions.

Do you have a specific example you can upload? I tried a simple one in 2009 (I deleted an element) and it did break the code.

Here are some things you can try:

1. Make sure you have the VIs in memory when you modify the cluster.
2. Use classes. I think they're supposed to have better tracking of these changes (at the very least, they make sure all the VIs that use the cluster are in memory).

[parthabe]

---

tst wrote:

(I deleted an element) and it did break the code.

---

I think Philip said only about reordering & renaming of the cluster elements. Deletion will break the code for sure.

Philip, 

I remember that reordering & (or) / renaming the cluster elements wont break the exsiting code's Unbundle by Name function. Thats the very purpose of it.

Also make a note that after reordering, if you place a Unbundle by Name function, it will list the elements in the new order. Maybe you can try the simple Unbundle function as Nitin has already suggested.

Or, try changing the Typedef cluster into a Strictly Typedef cluster with the Unbundle by Name function.

[parthabe]

---

PhilipJoeP wrote:

The problem I’m having is that when this cluster type def changes, the bundle by name and unbundle by name functions within the sub-VI will sometimes randomly pick new signal names to bundle/unbundle.  (Specifically, it will just pick a different signal element in the cluster.)  This is a problem because it doesn’t appear as an error in my code.  My code will execute, but just not correctly.  And then comes the long effort of searching through my sub-VI and fixing all the bundle and unbundle functions.

---

Philip, straight from the LV 8.6 Help, see the attached pics...

Message Edited by parthabe on 08-18-2009 04:21 AM