How to stop an event structure in a while loop

[X.]

> Does this attempt solve that problem?

No, it does not . Your processing case is still going to hold up your loop. Use the goddam consumer/producer architecture suggested by Ben64! It takes some neuron stretching the first few times you try to use this concept, but eventually, you will use it all over the place. You can use queues instead of registered events if you prefer, but the idea is the same: have a UI loop that ONLY monitors user actions and whenever there is a user request, pass it to a parallel loop that will process the request. It is not going to speed up the processing, but it will leave your UI responsive.

[LarsUlrich]

As I said in the last post, downconvert the example ben64 made to labview 8.5 or give me pictures!

No matter how many times I re-read the ni tips for producer/consumer structures I do not understand how I am supposed to wire in my selector case structure (the one that is in the event structure) to send its data to the main code in the consumer loop. 

So please please please, downconvert ben64's example to 8.5 or give me a picture instead of just telling me "use the producer/consumer pattern."  It doesn't have too be crazy detailed, or even a full .vi like ben64s, just take a screenshot of the first attachment I made, a screenshot of the producer/consumer events template, and just point out where they go.

[RavensFan]

LV 8.5

[Mark_Yedinak]

Here is an example. This example has multiple parallel tasks but the basics of a producer/consumer application are here.

[X.]

Here is another example created the way described by Ben64 (that is, using the Producer/Consumer template). I have just added a refinement to the queue structure, which allows you to pass data to your consumer loop.

[X.]

Oops. I should have tested my VI first... Anyhow, here is a slight mod which shows how to use the variant item of the queue to pass data from the producer to the consumer (if needed).

[LarsUlrich]

Thats for all the help, I am getting a better handle on the producer/consumer design, but I am a bit confused about something.

There are 2 distinct advantages that you guys made it seem like the producer/consumer design would have to the event/case structure I posted earlier, but I don't seem to get either of them with this new design.

I posted my new block diagram below in case I am doing something wrong, but from previous comments in this thread I was under the impression that with this new architecture 1) multiple clicks of the "que event" button WON'T que up multiple test runs while a particular test is running (i.e. if the user gets impatient and clicks the que event button 5 times while waiting for it to start, I don't want it to que up 5 runs) and 2) that the stop button would break and abort the code in the consumer loop if pressed (I still have to wait for the code in the consumer loop to run to completion if I click the stop button).

Maybe this structure was not intended to do these things and I just misread the previous posts, or maybe I just programmed it wrong, but it seemed like those were the two benifits of this design and for some reason I don't seem to be getting either of them.

[LarsUlrich]

Immediately after putting up that last post I noticed a terminal labled "max que size" on the obtain que .vi that is auto-set to unlimited, so with regards to #1 I can probably just wire a constant value of 1 to that terminal and solve that problem.

A stop button that breaks the code would still be nice though...

[Mark_Yedinak]

I would not limit your queue to a single element but rather put some state iformation in the producer (loop with the event structure) to restrict posting to the queue. This allows you to pass other commands such as Stop or Abort to the consumer. If you need to be more response to a Stop/Abort event than you need to break up your processing into more of a state machine that you can inject the Stop/Abort into the stream. There will be some things that you will need to wait for but using more of a state achine approach you can abort midstream during a test.

[X.]

That or you could generate a notification from the Event Case where you detect a stop action (and of course have your processing VI monitor this notifier).

Personally, when things may take a long time and I expect the user to change his mind, I pop up a progress bar from within the "Computing VI" with a "Cancel" and "Abort" button.

"Cancel", well cancels the whole thing, While "Abort" returns the results achieved so far (if that aplies).