LabVIEW botches unbundle when cluster is changed

[jdoyle]

• Define a cluster (typedef) like Wave Characteristics.ctl and a VI that unbundles from that cluster like Cluster Rename Bug.vi.
• Remove one element (Amplitude) from the cluster and add another one at the end (Noise Floor), so that the cluster still contains 3 elements, like Wave Characteristics 2.ctl,
• Apply Changes.
• The unbundle now uses Phase Shift twice.  The first occurrence of Phase Shift is incorrectly wired to Amplitude; it should still say Phase Shift, be in black, and the VI should be unrunnable.

The same problem happens if the VI that uses the cluster is not in memory when the cluster is changed.  This problem happens to us quite frequently and is a major source of bugs and cause of wasted time.  We understand that LabVIEW cannot determine whether the change in the second element name was intentional or an error on the part of the programmer.  We would prefer to get a broken VI and to resolve the problem ourselves, rather than have LabVIEW make incorrect assumptions.

[Wiebe@CARYA · Accepted solution]

I can't reproduce this in LV8.5.1. What version are you using?

What happens if you:

delete one element,
apply changes,
add the other element,
apply changes.

Regards,

Wiebe.

[Ben]

I can confirm that bug.

Sorry I don't have a CAR# handy.

The recomendation I recieved was too only dit the type defs when the callers of the type def are not open. AS you noticed this does not always avoid the issue.

What I can recomend:

This recomendation arises from fact (unless your scenario is different from mine) that when you delete an element from the cluster and the value that is now at the offset where the delete element was in the cluster is the same data type as the one deleted, the cluster bundle/unbundle by name  will switch to the wrong element and since the data types is the same >>>> No errors.

So if you want to delete an element....

Open the type def and change the data type of the element you want to delete to a type that will break all code that uses it. Like change a numeric to a string. This will break all of the VIs that use that field. Edit your app to remove refs to that element. THEN you can delete the element as you planned.

So ingeneral the idea is the same but rahter than breaking the VIs by deleting the element, you break it by changing the data type.

This same bug affects (as far as I understand) also affect dynamic event registration wires.

Just trying to help (and just as frustrated (maybe more!) as you with this bug),

Ben

[BCho]

Hey Jdoyle,

I was able to reproduce this performance after walking through your steps to reproduce in LabVIEW 8.6. CAR #153461 has been filed on this issue. You can use this number to track fixed issue in future releases of LabVIEW. Currently, the best work around for this is to manually change the duplicate entry in the Unbundle by Name to the third element in your cluster.

Thanks for pointing out this bug!

Hope this helps.

-Ben

[Ben]

Hi Ben,

Please make sure the CAR reflects the severity of this bug. In  large application this can be catostrophic hemm... bad.

If my "over Pressure Limit" suddenly gets replaced by  the "applied pressure" filed durring a safety check, only the safety relief valve is protecting the system.

Ben

[pincpanter]

I remarked this behaviour some time ago, see the first post here: http://forums.ni.com/ni/board/message?board.id=170&thread.id=233257&view=by_date_ascending&page=2

[PaulG.]

"We would prefer to get a broken VI and to resolve the problem ourselves, rather than have LabVIEW make incorrect assumptions."

You bring up a very good point. I fought this bug in a very big way on a recent project and just accepted it as "normal" behavior and that it was up to me to keep track of my data. My application was medium sized and it was a pain going back to every single subVI that bundled and unbundled data from a recently changed cluster. I can't imagine the chaos if it were a large application.

[Ben]

---

pincpanter wrote:
I remarked this behaviour some time ago, see the first post here: http://forums.ni.com/ni/board/message?board.id=170&thread.id=233257&view=by_date_ascending&page=2

---

That one was fixed.

This is a new one. Just as serious but new.

Re: Happening in a large app.

The LV 7.0 version of this bug hit me in a big app. In my case I had a start time and a stop time that was being used to determine the date range of history files that should be loaded at app start-up. The "Start Time" filed got hosed so as a result the longer the app ran, the longer it took to start-up and the worse it ran. In my case it was VI Analyzer that spotted two unbundles of the same value in a sub-VI about seven layers deep. Since I did not know about this bug at that time I "fell on my own sword" and claimed responsibility.

If you have a large app, I strongly urge using the method I outlined above to "break your app" first, then edit the cluster.

Ben

[Wiebe@CARYA]

"Wiebe@CARYA" <wiNOebe.walsSPtra@carAMya.nl> wrote in message
news:49bf8e1b$1@PYROS.natinst.com...
> I can't reproduce this in LV8.5.1. What version are you using?
>

Anyone?

[Ben]

---

Wiebe@CARYA wrote:

"Wiebe@CARYA" <wiNOebe.walsSPtra@carAMya.nl> wrote in message
news:49bf8e1b$1@PYROS.natinst.com...
> I can't reproduce this in LV8.5.1. What version are you using?
>

Anyone?

---

I believe this bug is in most of the LV 8 versions.

The situation that leads to this issue is when there are two or more elements in a cluster that are of the same data type and the cluster containing them is configured such that the two or more elements follw each other in the cluster order. When an element is deleted the new (wrong) field is now at the same index inside the cluster and is of the right data type so the "switcheroo" happens.

Editing the type def with the callers closed minimizes the occurence.

I hope that help,

Ben