while loop only iterates once

[GTPUMA]

Hi,

I'm doing a motion control application where I'm sending position commands to multiple axes. I have 3 while loops, one that reads feedback data from the axes, one that polls for a kill signal from the front panel, and one that polls for a "start motion" signal from the front panel.

The trouble is with my "start motion" loop (shown in the attached jpeg); it runs the first time when the program starts and then doesn't repeat at all. I used the 'Highlight Execution Flow' tool and it confirmed that the start motion loop runs for the first iteration then stops completely while the other two loops continue to execute. I wired an indicator to the index on this while loop and all of a sudden the loop began to iterate and everything worked like it should. I deleted the indicator and it still worked! But when I close the program and open it again (and there is no indicator connected to the index of the 'start motion' loop) the main loop goes back to iterating only one time, unless I add an indicator again, in which case it returns to working normally. It almost seems like the LabVIEW compiler thinks I'm not doing anything in that loop and is optimizing it out.

Any suggestions??

Thanks,

Thomas from GTPUMA

[stevem181]

Hi Thomas,

Have you verified your "continue logic"?

It looks like you need to have: Status, Ready to Receive, and End Program all set to true to continue.

Is that what you intended?

steve

[GTPUMA]

Thanks for pointing that out, for some reason that screen capture truncated the inverting signals. I've attached a better capture that shows this. The correct logic is to continue when error status is false, End Program is false, and Ready to Receive is true.

[RavensFan]

Put probes or indicators on each of those 3 boolean wires and see what there actual state is.

[GTPUMA]

I finally figured this out doing some probing and looking into subVIs. It turns out that when the case in the attached picture occurs, namely that a for loop with a case structure that is always false is being executed, the "Bd ID" being returned is set to zero, instead of the passed in value, which causes failure when the next VI is called. I'm not sure why the loop was hanging instead of immediately throwing an error, but rewiring the input board ID directly to the output board ID fixed the problem.

I'm not sure if Labview is optimizing this loop on the fly and this is somehow causing it or what but it's an interesting bug, and from what I can see it's not because I did anything wrong.

Thanks for your input all,

Thomas from GTPUMA

[altenbach]

If you are autoindexing on an empty array, the for loop will iterate zero times and all output tunnels will give default values for their datatype. If you want to protect an input to exit unchanged as output in this scenario, you need to use a shift register.

[RobCole]

If a for loop runs for zero iterations, any output tunnels return default values. Check how many iterations the for loop runs for. A way to avoid this problem is to use a shift register. When a for loop with a shift register runs for zero iterations, the output on the shift register will equal the input to the shift register.

Rob

[johnsold]

Thomas,

The problem is that the for loop does not execute because the Target Positions array is empty. When a for loop executes zero iterations, all the outputs are set to the default values for the datatype. So Bd ID Out is zero, not because of any problem with the case structure but because of the nature of the for loop.  The proper fix is to use a shift register for any pass through values on a for loop which might execute zero iterations.  The initialized shift register will pass the input value through even if the for loop has zero iterations. A for loop executes the minimum number of iterations determined by the size of autoindexing arrays and the value wired to N.

Another option is to test all autoindexed arrays to see if they are empty and bypass the for loop in those cases.  Usually the shift register is the simpler method.

Lynn

[GTPUMA]

Didn't know that! Thanks all!