Replace Array Subset bug

[Dan Press]

I've got a nasty one. I have attached a VI that should generate a 2D array of booleans with a pattern defined inside a case structure and double For loops. I initialize an array of FALSE booleans 8 elements long and then use the Replace Array Subset function to flip some elements TRUE. The first time I run the VI I see a strange pattern effecting one of my cases. In that case, when I try to flip a single element TRUE, the elements before it turn TRUE as well. The second time I run the VI, all elements turn true regarless of what is wired to the Index input of the Replace function!

This happens under 8.0 and 8.0.1 but NOT under 7.1.

The AEs have it under request numner 7108423.

Download File:post-123-1142877375.vi

Dan Press

PrimeTest Automation

[Jim Kring]

It's a good thing that I only use Build Array in a loop.

[AutoMeasure]

Wow, that's a weird one. Good find. Trying many different simpler situations to duplicate the problem, I see that you need to have the unusual situation of nested For loops, and the incoming boolean array must come in without shift registers prior to the Replace function.

See attached much simpler VI that demonstrates this same problem. Warning: when I ran this twice then attempted a Save As, Labview crashed (LV 8.0.1).

Download File:post-3297-1142881770.vi

[crelf]

I've got a nasty one.

Yep - it's a particularly evil bug when not only is the result wrong, its behaviour changes between runs

It's a good thing that I only use Build Array in a loop.

I feel dirty...

[AutoMeasure]

Oh, bad news. It ain't just booleans! See attached VI using a 1D array of floating point numbers.

Fortunately, I don't think I would ever be replacing array elements inside a loop with an array that didn't pass through a shift register first. I will have to keep that in the back of my mind though, not that there's any space left back there.

Download File:post-3297-1142949315.vi

[Jeff Plotzke]

I've found a 'workaround', however definitely not memory-efficient. You basically need to do something in the inner loop which will cause LV to re-create the array in memory. It seems that LV is using the same memory pointer for the input and output tunnels of the inner loop, thus causing the uninitialized shift register effect.

In my quick example, I take my array, convert to a variant, then back, and throw it into Replace Array Element. The VI works OK now.

~Jeff

Download File:post-4078-1142978780.vi

[crelf]

I've found a 'workaround', however definitely not memory-efficient. You basically need to do something in the inner loop which will cause LV to re-create the array in memory.

Also, changing anything on the BD between subsequent runs causes the VI to recompile, meaning that the memory space is reallocated. These two methods sort-of demonstrate the different behaviour between runs, but they unfortunately don't fix the bug - that's NI's job :laugh:

[Travis H.]

Hi Guys,

This is a very significant bug. Fortunately, there is a very trivial workaround. If you're using Dan's original VI, change the constant to a control for either the "element" input on the second (size of 8) Initialize Array primitive or the "new element/subarray" input for the Replace Array Subset primitive in the 1..12 case. If you're using the simplified VIs provided by Joe, then use the same concept. Change the constant to a control for either the 2-element array or the "new element/subarray" input for the Replace Array Subset primitive. This has been reported to R&D (# 3VM99T3G) for further investigation.

Take care,

Travis

LabVIEW R&D

National Instruments

[Jim Kring]

I have found another variant of this bug.

Download File:post-17-1145600287.vi