LabVIEW 6.1 If For Loop count terminal is zero then value going through the loop is not passed on to the output of the loop

[GabrielaK]

Hello, one of our customers just encountered an execution error in a vi running under LabVIEW 6.1, which doesn't exist under LabVIEW 5.1 or 6.01. I have a simple vi that has two encapsulated For Loops. Two string arrays go in, one goes out of the outer loop. Inside the outer loop the first array is indexed. The string which results from this indexing is compared with all other strings from the second string array in the inner loop. If it matches one of the strings of the second array, it is not outputted, otherwise this string goes through the inner For Loop to the output of the inner loop and from there to the output of the outer loop. The count
terminal of the outer/inner loop is connected to the Array Size of the first/second string array. If the second array is empty, that means that the element in test from the first arry cannot match anything from the second array, so the element in test is send to the output of the inner loop and from there to the output of the outer loop. This works fine in LabVIEW 5.1 and 6.01, but NOT in LabVIEW 6.1. In LabVIEW 6.1 the inner loop is never executed if the count value is zero (which is correct), but the data line running through the loop is not executed either, which is different to what LabVIEW 5.1 and 6.01 do. There, the input string is sent to the output of the inner loop correctly even if the loop counter is zero. The solution is easy - I just have to connect the output of the outer loop to the data line BEFORE it enters the inner loop. But: I don't know if this is a LabVIEW 6.1 bug or if it is supposed to be a feature, but it brings some incompatibility in programming between the
different LabVIEW versions.
Best regards,
Gabsi

[wiebe@CARYA]

Hi,

When a for-loop runs zero times, all outputs are 'undefined' (and should
be).

Besides, how would LV know what the output of a not executed routine should
be?

It might be handled differently in LV5 and LV6, which is unfortunate. In
both cases, the result is undefined.

It's not a bug. It's just something that should be avoided in any LV
version.

> The solution is easy - I just have to connect the
> output of the outer loop to the data line BEFORE it enters the inner
> loop. But: I don't know if this is a LabVIEW 6.1 bug or if it is

In some cases this does the trick. But if the data is changed in the inner
loop, this will effect the results if the N is not zero.

Technically, I think the output in this construction is also 'undefined'.
But LV handles this as expected / desired.

Another solution is to use a shift register. If N is zero, the input is
directly passed through to the output.

Regards,

Wiebe.



"Gabs" wrote in message
news:5065000000080000003B600000-1031838699000@exchange.ni.com...
> LabVIEW 6.1 If For Loop count terminal is zero then value going
> through the loop is not passed on to the output of the loop
>
> Hello, one of our customers just encountered an execution error in a
> vi running under LabVIEW 6.1, which doesn't exist under LabVIEW 5.1 or
> 6.01. I have a simple vi that has two encapsulated For Loops. Two
> string arrays go in, one goes out of the outer loop. Inside the outer
> loop the first array is indexed. The string which results from this
> indexing is compared with all other strings from the second string
> array in the inner loop. If it matches one of the strings of the
> second array, it is not outputted, otherwise this string goes through
> the inner For Loop to the output of the inner loop and from there to
> the output of the outer loop. The count terminal of the outer/inner
> loop is connected to the Array Size of the first/second string array.
> If the second array is empty, that means that the element in test from
> the first arry cannot match anything from the second array, so the
> element in test is send to the output of the inner loop and from there
> to the output of the outer loop. This works fine in LabVIEW 5.1 and
> 6.01, but NOT in LabVIEW 6.1. In LabVIEW 6.1 the inner loop is never
> executed if the count value is zero (which is correct), but the data
> line running through the loop is not executed either, which is
> different to what LabVIEW 5.1 and 6.01 do. There, the input string is
> sent to the output of the inner loop correctly even if the loop
> counter is zero. The solution is easy - I just have to connect the
> output of the outer loop to the data line BEFORE it enters the inner
> loop. But: I don't know if this is a LabVIEW 6.1 bug or if it is
> supposed to be a feature, but it brings some incompatibility in
> programming between the different LabVIEW versions.
> Best regards,
> Gabsi

[Greg_McKaskle2]

....
> loop. But: I don't know if this is a LabVIEW 6.1 bug or if it is
> supposed to be a feature, but it brings some incompatibility in
> programming between the different LabVIEW versions.

As the other response pointed out, this value is not well defined if the
loop never ran. It turned out that due to inplaceness, LV would do what
you wanted in very simple cases, but if the value went through a +1
node, what is the output supposed to be? So, in LV6.1, the bug was
fixed, and the output of a loop tunnel where the loop executes zero
times will always be a predictable default value rather than sometimes
being the value of some other terminal on the left due to inplaceness.

In the beta program for LV6.1, it turned out that very few programs
relied
upon this, so we went forward with it. If you suspect that there
are additional places in your project that may need to be changed,
technical support can provide you with a tool that will list out VIs
that have a for loop with a wire going across it. In otherwords, it can
tell you which VIs do not have the problem and give you a list of VIs
which need human inspection. If we could determine for certain, then LV
would fix the diagrams on the upgrade.

Greg McKaskle

[GabrielaK]

Hello Greg,
thanks for your response, it explains what I thought. You are right about what could happen if a value would be changed inside the loop, but the loop never runs. In my case, I did only wire the value through, it wasn't changed. That always worked well, until LV 6.1, and as you explained, it was a bug before which is fixed now.
Your offer that the technical support could provide a tool that finds all possibly problematic VIs is great, I already feared I had to find each vi where similiar problems could arise manually in a big project. How can I get this tool? Can you send it to me via e-mail or can you tell me the name of the tool and the e-mail address where I can ask for it?
Thanks a lot in advance.
Best regards,
Gabs

[Greg_McKaskle2]

....

> How can I get this tool? Can you send it to me via e-mail or can you
> tell me the name of the tool and the e-mail address where I can ask
> for it?


You might check for it by keywords 6.1 and For Loop on develop zone.
I'm not sure if it is there yet, but it could be. If not, contact
technical support. I believe that www.ni.com/ask.

Greg McKaskle