Uniterated For Loops do not pass References

[AlexA]

This is kind of obvious I guess, but a for loop which is not iterated, will not pass a reference through. This means if you're controlling your loop using auto-indexing (as I was), and for the use case where there is no data in the input array, any operations which had pass through references will return an error in the next operation to require that reference. In my case, an enqueue operation.

I guess this is by design, though I don't see why it should be. I know I can handle this but manually checking the size of the input array and using case structure. Or just split the queue reference and not pass it through (order of operation is already ensured by error terminals in any case).

Just curious as to the logic of this, given we have the ability to control For Loops by auto-indexing.

Regards,

Alex

[Jon Kokott]

Shift register the reference.

~Jon

[GregR]

The solution is to use the shift register. The reason is because the language makes no connection between the left tunnel and the right tunnel. What if the reference goes through a node? We don't know if the node would normally pass through or not. To avoid ambiguity we always produce default default for non-indexing tunnels when run zero iterations.

[AlexA]

Of course... I am thumping my head on the table right now. Sorry for wasting everyones time.

[jgcode]

Of course... I am thumping my head on the table right now. Sorry for wasting everyones time.

Don't worry it's not like we never went through the same exercise figuring this out. Learning is fun!

[Wire Warrior]

Yes learning is fun, but sometimes it leaves these odd bumps on my forehead.

Jason

[Grampa_of_Oliva_n_Eden]

And for even more bumps... an adventure in emptiness...

experiment with a 2d array passed to nested For loops and then experiment with the difference between a 0 X 2 aray and a 2 X 0 array.

I changed my mind three times trying to decide if I was looking at a bug.

Ben

[Samapico]

Hmmm, how can you get a 0x2 or 2x0 array? Wouldn't both be empty arrays anyway (i.e. 0x0) ?

[Aristos Queue]

Do you have any suggestions for improving this? It's not like you're the first person to hit this bug, and it sometimes hits those of us who know what to do but we forget. I like to ask this of new people in case they have some insight into a better way for LV to detect and fix this for programmers. It is an annoying bug.

[Jordan Kuehn]

Do you have any suggestions for improving this? It's not like you're the first person to hit this bug, and it sometimes hits those of us who know what to do but we forget. I like to ask this of new people in case they have some insight into a better way for LV to detect and fix this for programmers. It is an annoying bug.

Well references and error wires could default to shift register terminals when wired into the loop? Much like arrays default to auto-indexing. This would also be useful for counteracting the auto-indexing of references and errors when exiting the loop.

[Saverio]

Hmmm, how can you get a 0x2 or 2x0 array? Wouldn't both be empty arrays anyway (i.e. 0x0) ?

Like this:

Are we considering this behavior a bug, or by design? Greg seems to indicate it's by design, but Aristos is implying it's a bug.

[Ravi Beniwal]

Are we considering this behavior a bug, or by design? Greg seems to indicate it's by design, but Aristos is implying it's a bug.

Is there any possible (special) use such an array? If not, there is no reason to design it and it is a bug. It certainly hurts the brain when you try to picture it

[Saverio]

Just to clarify: my question about whether the operation is a bug or feature had to do with the "uniterated" loops not passing references through, and not about the array. The example I posted about the array was in response to Samapico's question about how to get a 0x2 array, which was a reference to Ben's comment having to do with other iteration behaviors with loops.

[asbo]

Is there any possible (special) use such an array? If not, there is no reason to design it and it is a bug. It certainly hurts the brain when you try to picture it

Not necessarily. Consider an example scenario where you have a 2D array where columns are UUTs and rows are DAQmx channels to read. This array is wired into a For loop to handle reading each channel for all UUTs in a single task. For some reason (plot device, in this case), you do filtering on the rows and could end up with an array of dimensions 0xN. This is perhaps not a "special use" but it certainly has functional significance in this csae.

Just to clarify: my question about whether the operation is a bug or feature had to do with the "uniterated" loops not passing references through, and not about the array. The example I posted about the array was in response to Samapico's question about how to get a 0x2 array, which was a reference to Ben's comment having to do with other iteration behaviors with loops.

The explanation of default tunnel value makes sense, but I understand the scenario you're in and don't have a knee jerk epiphany to handle it gracefully.

[Rolf Kalbermatter]

Like this:

Are we considering this behavior a bug, or by design? Greg seems to indicate it's by design, but Aristos is implying it's a bug.

It's a bug in the sense of a user error. It's not really a bug in LabVIEW itself as it does perfectly right what it is supposed to do.

[Grampa_of_Oliva_n_Eden]

Well references and error wires could default to shift register terminals when wired into the loop? Much like arrays default to auto-indexing. This would also be useful for counteracting the auto-indexing of references and errors when exiting the loop.

Love the idea but... the noob.

Now they fumble around to wire a ref to the loop and get it wired through the tunnel to something. The VI is runnable.

A noob that does itafte rhte change will have a broken VI because the SR on the output side are un-wired.

I can handle it but it would complicate the noobs.

My 2 cents,

Ben

[Ravi Beniwal]

A noob that does it after the change will have a broken VI because the SR on the output side are un-wired.

That makes sense, but what happens when a noob wires something out of a case structure? He gets a broken arrow, which pretty soon makes it obvious that the output tunnel either has to be connected from every case or be set to use default for unwired cases.

But I guess there could be an easy solution for it. While a shift register could be automatically added when a ref or error is wired, may be it can also be automatically wired through the loop to the other end of the shift register.

Another option could be to add this feature, but turn it off by default so noobs don't run into it.

[Jordan Kuehn]

That makes sense, but what happens when a noob wires something out of a case structure? He gets a broken arrow, which pretty soon makes it obvious that the output tunnel either has to be connected from every case or be set to use default for unwired cases.

But I guess there could be an easy solution for it. While a shift register could be automatically added when a ref or error is wired, may be it can also be automatically wired through the loop to the other end of the shift register.

Another option could be to add this feature, but turn it off by default so noobs don't run into it.

I would also again emphasize the point I was making that when they wire error wires out and they autoindex a broken wire appears when running it into another vi. Of course you could argue that n00bs don't use error wires...

[asbo]

A noob that does itafte rhte change will have a broken VI because the SR on the output side are un-wired.

In this case, why wouldn't it be accepable to have the default value passed out? It's a tricky situation all the way around, I guess.

Another option could be to add this feature, but turn it off by default so noobs don't run into it.

I disagree - something so fundamental as tunnel behavior, particularly in a niche case, shouldn't be a setting. I don't have a solution to the problem, but I don't think functional behavior should be squirreled away in configuration.

[Ravi Beniwal]

I disagree - something so fundamental as tunnel behavior, particularly in a niche case, shouldn't be a setting. I don't have a solution to the problem, but I don't think functional behavior should be squirreled away in configuration.

But how is this different from the setting that currently lets us "Auto-insert Feedback Node in cycles", which when turned off results in a broken arrow? I believe it is turned off by default.

[asbo]

That's

But how is this different from the setting that currently lets us "Auto-insert Feedback Node in cycles", which when turned off results in a broken arrow? I believe it is turned off by default.

It's different because the setting doesn't syntactically change the language, it simply adds nodes where it thinks you mean to have them.

[Ravi Beniwal]

So could there be a setting called "Auto-wire Shift Registers in Loops" which could add wires where it thinks you mean to (or need to) have them?

Not that it really matters either way; many times what LabVIEW thinks we are trying to do is not actually what we are trying to do and we end up changing it.

We are already creating shift registers and wiring through them for errors and references. Now we are just talking about how much automation makes sense in this case.

[Aristos Queue]

Are we considering this behavior a bug, or by design? Greg seems to indicate it's by design, but Aristos is implying it's a bug.

Ooo... bad choice of phrasing on my part. When I said "it's an annoying bug", I meant "It's a behavior that creates an annoying bug in user code that is often hard for them to track down."

[Rolf Kalbermatter]

But how is this different from the setting that currently lets us "Auto-insert Feedback Node in cycles", which when turned off results in a broken arrow? I believe it is turned off by default.

I'm not sure this is turned off by default, but I don't like autoinserted feedback nodes at all. Yes they are equivalent to shift registers, (since about 8.5 even in performance) but I prefer the more familiar shift register added explicitedly by myself than an automagic feedback node that is in my case in 99% not what I want.

[Phillip Brooks]

Is there a test in VI Analyzer to look for references passing through 'for' loops without a shift register?

When I said "it's an annoying bug", I meant "It's a behavior that creates an annoying bug in user code that is often hard for them to track down."

Just use marketing speak and call it "a feature"

Edited October 10, 2011 by Phillip Brooks