while loops and sequences misbehave

[tadk]

This simple vi is supposed to:

When started do state1,state2 (wait).
When save pressed do state3,state1,state2 (wait).
When exit pressed go forward and exit after state3.

It behaves inconsitently from run to run, sometimes
executing multiple times, sometimes exiting prematurely,
sometimes locking up.

Why is it so flakey, and how it is supposed to be written?

thanks

[TCPlomp]

Hello tadk,

i'm not sure what you are seeing but most likely they are race conditions (ie. reading a value and then setting one). I can't repeat your statements because I don't know in which sequence you've pressed the buttons.

The solution is a state machine, and a better one is an event handler (see attachement where i created a 'save' event) There are even better solutions but they are more complex.

Ton

BTW give your controls different names!

Apparently my proxy is blocking the attachment

[Dynamik]

Hi tadk,

Looks like you've received some well-qualified help from an LV8 guru - who replied to your post before I did!

... well, if you just want to implement the simple logic you described, here's a simple idea!

Cheers.

Message Edited by Dynamik on 06-09-2006 01:52 AM

[altenbach]

Yes, your VI suffers from:

1. Too many while loops.
2. Too many local variables.

You are completely tearing up all dataflow and the various parts of the code step on each others shoe laces. 😉

Use a single while loop and implement e.g. a queued state machine architecture. (5 States: State 1-3, pause, and stop).

• Preload state 1, state 2 and "pause" state into the queue.
• When save is pressed, load state 3, 1, 2, and "pause" in the queue.
• When stop is pressed, load state 3 and "stop" into the queue.
• Do one state per loop iteration, eliminating the sequence structure

Also remember that if you have several LEDs where at any time exactly zero or one is TRUE, you can use a radio indicator. Attached is a very simple implementation to give you some ideas.

As mentioned above, a queued state machine would be more flexible. Have a look at e.g. the shipping example labeled "queued message handler". There is even a design template.

[tadk]

I did start with a simpler vi. I added the local variables, delays and indicator writes to understand the flow of execution and to try to fix a simple issue - the exit button did not cause an exit.

altenbach, don't get me wrong, I thank you for the example. My problem is with labview. Your example does behave as I described but at a cost of far more complexity. Does it really take over a dozen programmatic elements to do this simple task? Not to mention that most of the control flow is hidden from me until I investigate the hidden parts. I used a flat sequence because it shows everything at once and I thought it forced an execution flow - is this incorrect?

If there are race conditions, can you help me understand where? Are the button presses lasting too long? Are the local variables not updated quickly enough?

After seeing more posts I see that the NI 'while' loop does not behave as advertized. If I understand right it should be called 'while+' or 'whilemaybe'.
This is a pretty disappointing language. I have already written or modified 50 VIs and I am still finding rude surprises in the most basic features.

 I'll stop my ranting and humbly wait for more seasoned advice.

thanks

[altenbach]

---

@tadk wrote:
I did start with a simpler vi. I added the local variables, ... to understand the flow of execution and to try to fix a simple issue - the exit button did not cause an exit.

---

There is little "flow" in local variables 😄

---

@tadk wrote:
If there are race conditions, can you help me understand where? Are the button presses lasting too long? Are the local variables not updated quickly enough?

---

Very simple: There is NO data dependency between the local variable read of stop5 in the big loop and the execution of the sequence structure in the big loop. This means that stop5 puts data into the termination condition before stop5 ever changes.

Quick Fix: Place the Stop5 local variabel read in the last frame to ensure it is read after the inner while loop completes. See image. 🙂

... Actually, you should just wire from the inner stop5 local variable to the stop condition of the outer loop. A wire always ensures proper dataflow and eliminates race conditions entirely. Why do you think you need to read the same value with two identical local variables?

... Even simpler. Place the stop4 button terminal at the location of the inner stop5 local and delete the extra while loop at the bottom entirely. Then wire from the stop4 terminal to the termination condition of the outer loop. Look ma, no locals (except for the LED indicators)!

Have you tried execution highlighting yet? It will help you solve such problems easily!

Message Edited by altenbach on 06-09-2006 09:00 AM

[tadk]

Many thanks. The quickfix shows exactly the point I was missing. Without dataflow to tie the two structures together, the only part of the sequence that was conditioned on the value of stop5 was the second frame.  100 lashes with the dataflow stick.

... Even simpler. Place the stop4 button terminal at the location of the inner stop5 local and delete the extra while loop at the bottom entirely. Then wire from the stop4 terminal to the >termination condition of the outer loop. Look ma, no locals (except for the LED indicators)!

Not exactly since the inner loop will not exit, but I get the point.

I need the local variable for exiting because my application will have several independant loops; one main and a few subordinates. When the main loop exits it needs to signal all the other loops to exit. Right now the local variable trick seems like the easiest way.

[altenbach]

---

@tadk wrote:
Not exactly since the inner loop will not exit, but I get the point.

---

Of course it will exit. 😄 Try!

[tadk]

I mis-read your instructions. Thanks again!