10-06-2011 01:26 PM
Hi all,
I have noticed unexpected behaviour of the in place structure at edit time. This VI illustrates the behaviour I see. Essentially, if you add items into the cluster above the element being unbundled in the structure, the structure changes the element it is operating on. This is not seen with the while loop. This is causing me a headache, but is it a bug, or expected? Does anyone agree this is a bug?
Kind regards,
Michael.
10-06-2011 02:02 PM
I don't think this a bug. You are defining the cluster on the run so to speak and the inplace structure is always using the nth element of the cluster. What you may want to try is using a typedef for your cluster. It is rarely a good idea to programmatically define structures simply because there is very little way for users down the line to know the cluster content other than by position within the cluster.
10-06-2011 02:29 PM
Hi Mark,
I wouid usually use a typedef, but in this case i dont want to. The cluster is the data running through a state machine and it changes frequently. This cluster is never passed into subvis and all elements are named. I think this is a special case where this is OK. Why should the inplace structure use the Nth when the while loop does not? that be the question...
Thanks for the interest,
Michael
10-06-2011 02:43 PM
I happen to think this is a bug. I also happen to think that it is very easily avoided and the effort to "fix" it is not worth it.
You do not have to TypeDef, you could simply create a constant to feed into the middle of your Bundle Node. This should avoid the "bug", and you can bundle your values by name this way which I think looks better. Relying on Cluster ordering is a recipe for disaster.
I usually Bundle and Unbundle (by location) for one purpose: to perform common math operations on multiple values. Everything else is Bundled/Unbundled by Name.
10-06-2011 02:46 PM
Yes I agree. I always name cluster elements. I also see how this can be avoided, its just not nice...
Thanks
03-13-2014 01:31 PM
NI please say this is a bug and fix it. I was just bitten by this and my code did not break because the data type of the Nth-1 item was the same as the Nth item.
I use the unbundle and bundle to modify a value in the cluster based on the name of the data which is how clusters work. I then do the same operation on the same data in the IPE structure.
If you make the bundle grow by one, and add an item to it, the VI will be runable, but the two operations are no longer the same because the IPE is now modifying different data.
Attached is my exampe saved in 2013 (not SP1).
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
03-13-2014 02:23 PM
I'm not seeing what the OP saw in 2013 (OP sourced in 2011)
The fix should be moot for current versions of LabVIEW since the optimizer recognizes the unbundle repace element bundle and acts in-place without the IPE.
e.g this snip is faster than the equivallent IPE in versions where the optomizer has been trained (2011-to current) since the IPE adds two sync boundaries that really are not needed
03-13-2014 02:23 PM
I'm not seeing what the OP saw in 2013 (OP sourced in 2011)
The fix should be moot for current versions of LabVIEW since the optimizer recognizes the unbundle repace element bundle and acts in-place without the IPE.
e.g this snip is faster than the equivallent IPE in versions where the optomizer has been trained (2011-to current) since the IPE adds two sync boundaries that really are not needed
03-13-2014 02:32 PM
I opened the OP VI in 2013 (again no SP1 yet) and it behaves as described the bottom IPE turns into str instead of num.
So are you saying that I should never use the IPE for unblundle / bundle operations in 2011 and newer? Not that I used it much to begin with but still.
Even so I am still under the opinion that this is a bug. The unbunble in an IPE should stick to the name of the element the user picked, not the Nth item in the list that was selected.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
03-13-2014 02:40 PM
Based on the example Hooovahh attached I agree that this is a bug. I believe it is being caused by the lack of typedefs and way that bundle works vs bundle by name. The main reason I feel it is a bug is the inconsistency between the unbundle by name and the IPE structure node. Filed as CAR 458466.
Regards,
Jeff Peacock
Product Support Engineer | LabVIEW R&D | National Instruments