Jump to content

Uniterated For Loops do not pass References


Recommended Posts

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

  • Like 1
Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Like this: post-3256-0-00473500-1317305353.png

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.

Link to post
Share on other sites

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 :)

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

Like this: post-3256-0-00473500-1317305353.png

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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...

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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."
Link to post
Share on other sites

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.

Link to post
Share on other sites

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" :P

Edited by Phillip Brooks
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.