Scripting Named Unbundler Selection

[jaegen]

As far as I can see, the only property we have for selecting which cluster element is unbundled in a named unbundler is the "Element Names[]" property. But this doesn't seem to work for selecting elements out of a sub-cluster.

I've attached 2 VIs which demonstrate what I'm talking about. Open both of them and run "Test Unbundle Script.vi" - it doesn't seem to work.

Anyone have ideas?

Jaegen

Download File:post-932-1157142434.vi

Download File:post-932-1157142445.vi

[martin@aerodynamics]

As far as I can see, the only property we have for selecting which cluster element is unbundled in a named unbundler is the "Element Names[]" property. But this doesn't seem to work for selecting elements out of a sub-cluster.

I've attached 2 VIs which demonstrate what I'm talking about. Open both of them and run "Test Unbundle Script.vi" - it doesn't seem to work.

Anyone have ideas?

Jaegen

Hello it does Work!?!

You can easy change the number of unbundle Elements and you can easy change their values (if they are maching to the "default" cluster)

:beer:

[jaegen]

Hmmm, maybe it only works in the German language version.

Here's what I get: (I made some minor mods to make mine look like yours)

Note: I'm using LV 7.1.1 (though it doesn't seem to work in 8.2 as well)

Jaegen

[martin@aerodynamics]

Hmmm, maybe it only works in the German language version.

Here's what I get: (I made some minor mods to make mine look like yours)

Note: I'm using LV 7.1.1 (though it doesn't seem to work in 8.2 as well)

Jaegen

Hello It doesn't work any more :headbang:

since I played around with the Methode Node (Resize, Add Output, Remove Output)

But I don't now why, it's strange.

But I am still able to select the elements in the Main Cluster (Sub 1 and Sub 2) when I then add a second unbundler to Sub 1 or to Sub 2 I am also able to select A or B. But I can't anymor directly a "Subcluster"..

[Mike Ashe]

Hello It doesn't work ... it's strange.

But I am still able to select the elements in the Main Cluster (Sub 1 and Sub 2) when I then add a second unbundler to Sub 1 or to Sub 2 I am also able to select A or B. But I can't anymor directly a "Subcluster"..

Ditto here. Sometimes I was able to get to a subcluster directly, but mostly only at the same time as resizing. After a short while it doesn't seem to work except for the main cluster elements. Oh well, at least we have some part working. I might try to add all the elements with a resize next, then selectively delete the ones I don't want to try to arrive at the final desired configuration.

[jaegen]

Hello It doesn't work any more

Shoot, there goes my theory that it actually had something to do with German vs. English, or ANSI vs. Unicode, or the like.

... I might try to add all the elements with a resize next, then selectively delete the ones I don't want to try to arrive at the final desired configuration.

I thought of this, but I don't think there's a way to do this that handles everything - it has to do with the way LabVIEW handles resizes of an unbundle node in general. If you wire an unbundle by name and drag down, it automatically fills with all of the elements in the cluster, but doesn't drill down into sub clusters until you get to the end (i.e. if your last element is a sub cluster, then it starts automatically filling with the elements of that cluster - I'd love it if they changed this by the way). So, with scripting you could work out a way to get into the last sub cluster, but not any others.

Are you guys sure that you actually had this working? The end result is very dependent on which values are in the unbundle before you run, and which values you're asking for. Another annoying thing is that it doesn't return an error if you ask for something that doesn't exist.

Should I file a bug report for this??? (Or is scripting in its entirety a "bug" in NI's world ).

Jaegen

[Barrie]

Are you guys sure that you actually had this working? The end result is very dependent on which values are in the unbundle before you run, and which values you're asking for. Another annoying thing is that it doesn't return an error if you ask for something that doesn't exist.

Should I file a bug report for this??? (Or is scripting in its entirety a "bug" in NI's world ).

Jaegen

This is really bugging me. :headbang: The timing is such that I was just about to start on a sub VI that needs to do exactly this.

I'm not sure if I ever got the sample VI to work, so, not calling anyone a liar, can someone confirm that it did work consistently, at least for a while? if so, I can start working backwards to try to figure out what's going wrong. any other clues would be greatly appreciated. (Fresh copy of LabVIEW, window minimized, first run only etc.) It appears a reference is getting trashed, or some data is non-persistent, but that should create an error.

The only way I have been able to do this reliably, is really clunky. I create a tree of unbundles to get the item I want and then I wire the final unbundle to the original cluster and delete the intermediate unbundles. Not for the faint of heart.

I agree, no feedback (error) for non-existent items is a real pain. As for a bug report, I remember Jeff K. saying something about "It's ok to use scripting, just don't expect us to support it", so that's a non starter.

Scripting: The final Frontier.

[jaegen]

The only way I have been able to do this reliably, is really clunky. I create a tree of unbundles to get the item I want and then I wire the final unbundle to the original cluster and delete the intermediate unbundles. Not for the faint of heart.

Very clever - I'd given up on this being possible at all (not that this is really a realistic solution though).

Joking about bug reports aside, perhaps we need someone with access to the "source code" to at least give some insight into this ...

Jaegen

[MikaelH]

Confirming!!

It worked for me yesterday perfect.

But today, it doesn't , I can't select items in sub-clusters anymore...

[MikaelH]

Hi scripting lovers.

Since bundle and unbundle of clusters in cluster don't work, I've had to do it in an diffrent way.

(See attached project-LV8.2).

The application is not nice written, it's just a proof of concept

Cheers,

Mikael

Download File:post-941-1164798434.zip

[Mike Ashe]

Interesting way to walk down the tree. I'm going to try this, and then disconnect the bottom most unbundle and rewire it to the top cluster and see if it maintains the low level unbundle. If so, then we can then delete the intermediate unbundles.

[crelf]

Since bundle and unbundle of clusters in cluster don't work, I've had to do it in an diffrent way.

That's pretty neat Mike - consider the concept prooved

[jaegen]

Interesting way to walk down the tree. I'm going to try this, and then disconnect the bottom most unbundle and rewire it to the top cluster and see if it maintains the low level unbundle. If so, then we can then delete the intermediate unbundles.

Unfortunately this won't work properly if you have 2 sub-clusters which are identical (i.e. 2 instances of a type def) or which contain an element with the same name. The problem is that if you have an unwired unbundle containing the name of just the low-level element you want, and you wire it to the top-level cluster, LV will always assume you want the first instance of that name, not any subsequent ones (it's not LV's fault - it doesn't really have any way of knowing which sub-cluster you want to drill into).

I'm probably not explaining this clearly - check out the attached VI. Delete the first unbundle and wire the second one directly to the control - it will always revert to "Sub 1.Num 1", not "Sub 2.Num 1".

Jaegen

Download File:post-932-1164820867.vi

[Barrie]

<snip>

I'm probably not explaining this clearly - check out the attached VI. Delete the first unbundle and wire the second one directly to the control - it will always revert to "Sub 1.Num 1", not "Sub 2.Num 1".

Jaegen

Ok, now I'm really torqued.

I tried exactly that about a week ago and I am 99% sure it did not revert.

I just tried it again, and it did revert. :headbang: As you pointed out, if the 2nd level unbundle names are unique, it does not revert. That said, if I go back to the original scripting test VI and make the element names unique, it still doesn't work.

Any suggestions for tracking down this elusive secret?

Incense, chants, incantations or aligning the cpu with magnetic north will all be considered.

B.

[Mike Ashe]

Unfortunately this won't work properly if you have 2 sub-clusters which are identical (i.e. 2 instances of a type def) or which contain an element with the same name. ... I'm probably not explaining this clearly ...

Actually, you explained it quite well.

However, I'm not to worried about this behavior and I'm happy that we have a workaround at the moment. Besides, since we at LAVA always use good style and never do things like unnamed elements or fail to use unique names in our clusters or other programming faux-pas we won't have this problem, will we? *

*with our own code of course ...

[sam]

Besides, since we at LAVA always use good style and never do things like unnamed elements or fail to use unique names in our clusters or other programming faux-pas we won't have this problem, will we? *

This is an issue is if you have a Cluster Point (int X, Int Y) or Cluster Resolution (int X,int Y)

Now this naming is quite common practice. But if you now have some objects (Clusters)

that use the above(point or Resolution ) as parameters, then you are going to run into Problems. I am speaking of this as unbundle by name is now a bug in LabVIEW ever since I can remember. So maybe you can get it right.

[LAVA 1.0 Content]

Besides, since we at LAVA always use good style and never do things like unnamed elements or fail to use unique names in our clusters or other programming faux-pas we won't have this problem, will we? *

*with our own code of course ...

There is a very good reason to create unnamed clusters, namely they consume less memory... LabVIEW is not optimal in memory usage when creating clusters. Especially it wastes memory when you create a named cluster.

[crelf]

There is a very good reason to create unnamed clusters, namely they consume less memory... LabVIEW is not optimal in memory usage when creating clusters. Especially it wastes memory when you create a named cluster.

Sure, creating unamed clusters uses less memory, but it's certainly not a good reason to do it. It may not be efficient, but I sure wouldn't call it a waste of memory...