Why does Stop Button not stop Timed Loop.

[LisaMeng]

Hi everyone,

I had some pretty complicated code thrown at me. I had to change the program from taking a single measurement (and lots of other stuff) when an ACQUIRE button was clicked to taking timed measurements. I was able to add the timing... but I would like the timer loop to stop once the STOP button is clicked.

I attached a very simplified version of my code.

So if you start it and hit the ACQUIRE button the program generates random numbers (to simulate the measurement) and saves them together with an Device ID. The program will stop once the Total Duration is up e.g. in the default settings after 20sec.

But it does not stop when the STOP button is pushed. MY QUESTION: why not?

FYI:

In my actual code there are 10 events instead of just 1.

It does not have to stop right away, inbetween iterations (since I already tried to include the Stop Timed Structure VI and it wasn't working either).

I also used the Highlight Execution but it did not help me.

Thank you so much for any help or suggestions!

Lisa

[altenbach]

Your event locks the front panel until the event completes, but it is trapped in the timed loop and cannot complete. (look at the event configuration near the bottom left)

I recommend to never put interactive code inside event structures.

[johnsold · Accepted solution]

Lisa,

First, Thank you for explaining clearly where your problem was and for submitting a simplified program.

The problem with your program is very simple. The loop inside the event structure starts when the Acquire: Mouse Down event occurs, whihc appears to be what you intended. The default condition for event cases is to "Lock front panel (defer processing of user actions) until this event case completes." This is controlled by a check box at the bottom of the evetn setup dialog. What this means is that the stop button is not recognized until AFTER the event case completes.  BUT the event case cannot complete until the while loop stops.

The Solution: Move the loop outside the event case.  Generally, event cases should not contain any code which might take more than a few milliseconds to execute and definitely should not depend on other user actions to complete.

Look at the Producer/Consumer (Events) Design Patterns for guidance.  Also learn to use queues to pass your data between loops rather than local variables.

Lynn

[LisaMeng]

You guys were so quick in your replies!

Ok here is what I did:

In test7 (attached) I changed the configuration of the event structures ( right click on the event case (in my case: "Acquire": Mouse Down) --> Edit Events Handled by this Case... --> uncheck the "Lock front panel (defer processing of user actions) until this event case completes" )

If you now start the program and hit ACQUIRE and then the STOP after a while, the program will stop with the next iteration.

This works for me when it is set to "sec" but is a little annoying when set to "min" since I might have to wait close to one minute until the program stops.

So in test8 (also attched) I added the Stop Timed Structure VI and now the program stops right away when the STOP button is clicked. It does one more iteration when it stops but that is not a problem in my case.

So this is what I wanted.

Not sure if this is less "elegant" than moving the Timed Loop outside of my Event Structure but it works and will be much simpler to do for my more complicated, original code.

Thanks so much!

[altenbach]

---

LisaMeng wrote:

So in test8 (also attched) I added the Stop Timed Structure VI and now the program stops right away when the STOP button is clicked. It does one more iteration when it stops but that is not a problem in my case.

---

Now you are overloading the event case even more by adding two interactive loops inside the frame. Tha'ts horrible! You still have an event structure outside a loop that will potentially accumulate an infinite number of events without ever having a chance to execute them. Also, what's the purpose of the lower loop? It seems to run once and the give up.

---

LisaMeng wrote:

Not sure if this is less "elegant" than moving the Timed Loop outside of my Event Structure but it works and will be much simpler to do for my more complicated, original code.

---

I think you have some misconceptions about "simple" and "complicated". From what we have seen so far, most of the complications are due to poor code architecture, and fixing them by adding even more code is just plain silly.

I guarantee you that if you would rearchitect your code from the ground up with a proper design pattern (e.g. state machine), you would be much better off. There would not be any questions about "more complicated" or "less complicated" because everything would be "not complicated". 

[johnsold]

Lisa,

Here is a modification (well, more like a rewrite) of your VI.  This does not have any loops or other time consuming code inside the event structure. It does not use any local variables. It will stop within milliseconds of pressing the stop button. (One exception: If the Acquire and Save case is active, the stop time will depend on how long it takes the file write to complete.) It calculates the timing parameters and the device ID immediately after the Acquire button is pressed.  If you do not want to see the Time Units or Device ID values, the indicators can be removed. It is rare that a hidden indicator is needed. If you are using them to allow the creation of local variables, then you are not using the power of dataflow.

I did not test this and it is not completely documented.

Lynn