Why the local variable keep its value (T/F) in the second iteration in for loop?

[rammo]

Hi.........................

I am doing a program with Labview 7.1.1. In brief, I used  while loops inside for loop, and there are local variables in some while loops to do specefic operation if they are TRUE or FALSE, but when the second iteration of for loop begin the local variables keep their value (TRUE) that finished with it in the first iteration, while they keep thier value in milliseconds then return to the default (FALSE) but it's enough time to do the operation that I programmed for them when become TRUE (that I don't want at begin).

So, how to avoid this problem, can I make delay to this local variables (milliseconds) in next iteration of for loop to begin as default (FALSE) ? or any suggest to avoid this problem.

[CoastalMaineBird]

It's hard to see exactly what you're referring to, but local variables do not have any sense of iterations or loops.

Local variables are just read/write access points to front-panel controls/indicators, nothing more.

If you are expecting them to reset themselves on their own, you are misusing them.

If the user flips a front panel switch (or changes a numeric control), any local variables you have (as well as the terminal) will reflect the new value. If the user leaves them in that state, and if you don't write something different to the local variable, then they will retain that state forever.

[rammo]

Here in this attachment you can see the problem what I mean.

When the volt at output reach to the specified volt in input, second while loop it must stop and the LED (first loop off) will be ON, also because the local variable of  the LED (first loop off) be ON the third loop will stop and the LED (second loop off) will be ON, and the first while loop will stop if the volt decrease up to or less (1V for example), this first iteration of foor loop great.

But in the next iteration the LED (second loop off) keep ON although the terminal (first loop off) is OFF.

whyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy?

How to avoid this problem?

[CoastalMaineBird]

Looks to me like you have a classic race problem.

When you start the outer (FOR) loop, what is the value of LOOP 1 OFF?
Answer: you don't know. It's PROBABLY going to be wrong, because the first loop waits until AFTER the TOLERANCE function to WRITE it, but the top loop can READ it right away.

If all you're doing in the middle loop is a comparison, why have a separate loop at all?

Why not just compare the value after you read it?

[altenbach]

You generate a classic race condition.

There is no way to tell if "output" in loop two is read before or after it is written in loop one. Most likely it is read before, reading a stale value from the previous iteration. Similar problem existsfor the boolean locals!

Since all loops run at the same speed, put all code in one loop and wire the "output" directly to the comparison that is currently in loop 2. No local variables needed.

Message Edited by altenbach on 11-21-2005 09:38 AM