Build array bug?

[Yamaeda]

Noticed in LV2011, don't know if it's changed. Also, i can't quite reproduce it in a fresh VI ...

1. So i have a build array which concatenates several string arrays, incl. an earlier build array.

2. I remove one wire which ofcourse breaks the VI.

3. I connect another array and it's broken! The Build Array removed the concatenation option and now tries to build a 3D array (which break due to the indicator).

Strange.

/Y

[altenbach]

Can you show a series of step-by-step pictures?

(Yes, there are always cases where disconnecting something switches the mode (build<>concatenate), for example if due to some editing actions upstream one of the inputs temporarily changes dimensions)

[Alexander_Sobolev]

It seems I understand situation. Try to force recompile VI (press Ctrl+Click on the broken arrow).

Now you can not set/remove concatenate arrays check mark from the build array - it is concatenating 1D arrays into 2D array. If you connect constant, it will show error. Seems obvious: you are trying to add constant to double array. You can not remove checkmark because you can not build 3D array. Recompile happens only for the node you are modifyng.

If you connect constant and recompile full VI, it will understand the situation, that it needs to change not only build array node, but also shift register. 

[billko]

---

@Alexander_Sobolev wrote:

It seems I understand situation. Try to force recompile VI (press Ctrl+Click on the broken arrow).

Now you can not set/remove concatenate arrays check mark from the build array - it is concatenating 1D arrays into 2D array. If you connect constant, it will show error. Seems obvious: you are trying to add constant to double array. You can not remove checkmark because you can not build 3D array. Recompile happens only for the node you are modifyng.

If you connect constant and recompile full VI, it will understand the situation, that it needs to change not only build array node, but also shift register. 

---

That was actually pretty awesome.  Kudos.

[Yamaeda]

Yes, that is pretty similar to my original code. The bug, is that it dropped/changed the Concatenate when one wire is disconnected. I'd say it should stay the same until something new is connected, or is there some benefits to this behaviour?

/Y

[Alexander_Sobolev]

Aha, I found this bug.

Build array resets to default mode (build arrays, not concatenate them) when I disconnect top constant.

Looks like internal state is stored by checkmark "increase output size based on first element?", that affects user "Concatenate?" and works in undefined modes.  Conflict between reasonable for programmer vs reasonable for user.

Disconnecting bottom constant instead of top one does not change behaviour.

I wonder if this is different in higher LVs...

[RavensFan]

I wouldn't call this a bug.

Anytime you wire or unwire something, LabVIEW checks the datatypes as a part of the recompile process.  If something doesn't quite fit together anymore, then it will break the wires.  LabVIEW should've be trying to change underlying properties of nodes to try to anticipate what the programmer is trying to do and "fix" it.  Suppose this was a more complicated piece of code with multiple Build Arrays combined together in series.  "Fixing" the setting on a given node might cause a cascade of changes up or down the wire chain as more things might break and then need to be fixed.

It's the same reason I can't stand the auto feedback node and turn that option off in the settings.  If I accidentally wire to the wrong spot to create a cycle, I'd prefer the wire break and let me go and fix it rather than it "fixing" the code by inserting a feedback node which definitely changes the intention of the programmer, and possible not even noticeable if the feedback node gets placed offscreen.

Rather than LabVIEW guessing what I'm trying to do, I'd prefer it tell me something is wrong with a broken wire and let me go and solve the problem according to my needs.

[Alexander_Sobolev]

I agree in general case, but in this particular case it changes behaviour of the node based on hidden rules, not user actions.

It is concatenating inputs, making 1D array, mode is fixed.

Disconnecting constant (only top one) gives build array possibility to change mode. And it forgets the old mode and changes to a different one. Both modes, new and old one do not contradict to inputs.

If multiple modes are allowed and not affected by other elements, I prefer LabVIEW to keep behaviour, rather than reset to default one.

PS. Yes, there are properties that are not stored within element  (Build array does not store element type connected to it) and I do not request them to be stored in current instance, but mode is a configurable property, it should not change.

[RavensFan]

---

@Alexander_Sobolev wrote:

I agree in general case, but in this particular case it changes behavior of the node based on hidden rules, not user actions.

It is concatenating inputs, making 1D array, mode is fixed.

Disconnecting constant (only top one) gives build array possibility to change mode. And it forgets the old mode and changes to a different one. Both modes, new and old one do not contradict to inputs.

If multiple modes are allowed and not affected by other elements, I prefer LabVIEW to keep behavior, rather than reset to default one.

PS. Yes, there are properties that are not stored within element  (Build array does not store element type connected to it) and I do not request them to be stored in current instance, but mode is a configurable property, it should not change.

---

Maybe there is a difference between LV 11 and LV14.  I was playing with your snippet in the oldest version of LV I have installed which is 2014.

In LV 2014, it didn't really seem to change the mode of the Build Array.  If it was in concatenate mode before mixing array dimension inputs (scalar and 1-D,  or 1-D and 2-D, ....), then it stayed in concatenate mode after deleting the other inputs that had the other dimensionality.  If it was NOT in concatenate mode before mixing inputs, then it stayed out of concatenate when it went back.  It never changed the underlying Concatenate setting.

However, when Build Array did have mixed inputs, it assumed Concatenate mode (there is no other logical choice), the right click menu showed "Concatenate Inputs" as disabled, and checked.  That makes sense because you can't change it, and it IS concatenating.  There is no way to visualize at that point of time what the underlying setting of the node was before it was forced to concatenating/disabled because of the mixed inputs and no way to no what it will go back to when removing the other inputs.  But at least in 2014, it did always go back to what the original setting was.

There is one exception.  If you had concatenate mode on for multiple 1-D arrays,  then wire in scalars, of course it goes to concatenate checked, and disabled.  If you go an unwire the 1-D arrays, the node will show as concatenate mode unchecked disabled, which also makes sense since you can't concatenate scalars.  Concatenating scalars is really the same thing as building a 1-D array.  But reverse the process, it will still remember what the underlying mode was for the Build Array back when you can option to choose the mode is enabled in the right click menu.

Again, this is all in LV 2014 and it all behaves as I expect it to.  I don't have LV 2011 installed to be able to try it there.