Strange Problems with Bundle, Unbundle and initializing Shift Registers...

[Logic]

Hi all,

I found strange problems with Bundle and Unbudle clusters with shift Registers in my application.
I believe following points are correct.

1. Once I unbundle some values from a cluster in the shift register and use it for some purpose, it wont reflect in the shiftregister values unless I bundle it and pass it again.
2. If I initialize the shift register outside the loop using a constant, whatever the value that shift register value takes inside the loop, it will be initialized again when i stop the vi and run again. The constant value in the block diagram should remain as a constant value.

But the VI I have attached does not behaving in the way I said above.
1. The Shifregister value also changing.
2. The constant value in the block diagram changing to the shiftregister value when i click on that.
I have attached 3 images to explain what happened when i run the VI.
I have attached the VI also.

Anybody faced such problems before, looks something wrong in basic level.
Hope it is not my PC problem, because i already tested in two other PC.

thanks,
Logic

[alkazaa]

I can confirm the behavior. I looks like a (very subtle) bug.
I even rewrote the VI from scratch, it behaved the same.

Even worse: one cannot edit and save it: I tried to modify the constant which initializes the shift register (SR). The constant is a cluster containing a cluster of four I32. I used the inner cluster and a 'bundle' to make the same data structure. I could connect that instead of the original constant to the SR but when saving the VI Labview crashed...

Playing a bit more with the VI I found a small modification which lets it work as expected: I use a separate unbundle by name for unbundling 'Test.AllElements' in the ">Test" case. The modified VI is attached.

You should report your finding as a bug to NI

[alkazaa]

Sorry, looks like I forgot the attachment

(seems to be a bug in the forum software: when you attach something, then press 'Preview Post', the attachment is removed and you have to select the attachment again)

[altenbach]

Curious problem!

---

@fahlers wrote:
Playing a bit more with the VI I found a small modification which lets it work as expected: I use a separate unbundle by name for unbundling 'Test.AllElements' in the ">Test" case.

---

It also behaves correctly if you simply omit that unbundling of 'Test.AllElements' entirely. It is not needed.

[alkazaa]

---

@altenbach wrote:
It also behaves correctly if you simply omit that unbundling of 'Test.AllElements' entirely. It is not needed.

---

That is true, but I assume that the attachment of the original post was stripped down in some way already. So the observed (mis)behaviour may strike you sooner or later when you access a more complex cluster in that way...

It seems very strange to me that the value of a BD constant can change due to such an exotic bug (that's what it did after I saved the VI). But I have no insight into the guts of labview...

[chilly_charly]

---

@fahlers wrote:
It seems very strange to me that the value of a BD constant can change due to such an exotic bug (that's what it did after I saved the VI). But I have no insight into the guts of labview...

---

Agree...
we are not far here from a method of varying constants programmatically !! That reminds me of the time I loved to write self-modifying code in assembly language. 🙂

CC

[Ben]

Paraphrasing Rolf K.

"Self modifying code is a bad idea!"

Let me go out on a limb and say that thinks like onother variation of the bug reported recently on the event structure.

See this link

http://forums.ni.com/ni/board/message?board.id=170&message.id=92467#M92467

I played with this VI a bit and can confirm the work-arounds mentioned above and found some others.


All of the variations that work differ from those that do not in their buffer allocations.

Procedure
1) Open "Tools >>> Advanced >>> Show Buffer Allocations"
2) Select "Clusters" and punch "Refresh" (repaet as desired to see all flashing dots).
3) Notice that the cluster constant outside the loop AND the output tunnel (set as use default if un-wired) flash.
4) Surround offending code in ">Test" state with a for loop.
5) Wire a "1" to the For Loop iteration terminal and right click on the output tunnel and disable indexing.
6) Repeat step #2 and notice that the Bundle function is now allocating a new buffer.

Un-supperted conclusion:
In the original code the bundle function is operating in-place and modifying the buffer of the shift register. This buffer is shared by the cluster constant that initializes the SR.

So...
1) I vote bug!
2) I suspect this is the same bug Weibe found.
3) Now I know why I never trusted the "Use default in un wired" (aside from it encouraging bad code).

Ben

[Ben]

I have reported this.

See SR #630279

I will update when I have more info.

Ben

[AG123]

Hello All,

I would like to let everyone know that I was able to reproduce the problem and have filed an official Corrective Action Request to our R&D department to further investigate the issue. Please rest assured this issue will handled carefully.

Thank you for your patience,

Aluma G.
Applications Engineer, NI.

[JeffBoettcher]

Yes, this is a bug. Unfortunately we found out about this too late to include it in the recently released LabVIEW 7.1.1. The good news is that it is really quite an uncommon set of circumstances under which this problem occurs. This problem has existed since LabVIEW 5.1 and this is the first report of it we are aware of. We will be working to resolve this issue in a future version of LabVIEW, but for the time being, be aware that only if all of the following conditions are met will this issue occur. If you avoid any of the following situations, you will not experience this bug:

• You have a single-element cluster with multiple elements in the inner cluster (cluster of cluster of four numerics, in this case).
  
• You use Unbundle By Name to access elements in the inner cluster using the dotted-notation in the same Unbundle By Name node where you access the inner cluster - all elements ("Test.A", "Test.B", "Test.C", "Test.D", and then "Test" itself, in this case).
  
• You use the inner cluster - all elements ("Test", in this case) to specify the cluster type input of the bundle node. You then must also wire the output of the bundle to something.

See the VIs in the attached ZIP file for clarification. Thank you for your understanding.

Jeff Boettcher
Product Support Engineer
National Instruments - LabVIEW R&D