....A while loop was placed for repeating and
> controlling the STOP. When i run this VI, the handler can move as i
> want, but there were 2-3 seconds time delay when i tried to stop this
> VI. Could anybody help me?
What is usually happening in cases like this is that a while loop is
running one more iteration after it sees the abort button pressed. If
one or two iteration of the loop can account for the time delay, maybe
this explanation will help
When a while loop diagram begins, it typically sees quite a few things
in parallel. At the top of the loop are your computations, at the
bottom is your Stop button read. Let's say the while loop is just
beginning iteration 10. The diagram begins execution, and lets say it
inspects the button terminal, passing it to the continuation terminal
with a FALSE, meaning to run another iteration. At this point you have
already committed to running iteration 11. Then the top of the loop,
the computation starts. If it takes about a second to run, during that
second you press the Stop button. The screen shows the button pressed.
At the end of the diagram, the loop starts the diagam again and starts
iteration 11. First it reads the Stop button, and this pops the button
out on the front panel. It sends the value to the continuation
terminal, and the loop will not execute again, 11 will be the last one.
So then the top part of the diagram executes, taking about one second.
From your point of view in this example, you asked that the loop stop
after nine finished. LV didn't see the change until 11 began.
The solution is to sequence the button read with the diagram. Either
read the button at the end of the loop, or read it at the very
beginning, but make the code inside be conditional. Many people do this
by using a state machine and making the check state and execute state
alternate. For something this simple, you can also use a sequence, and
if you know what this means, use a single frame sequence with a data
dependency.
Greg McKaskle
