Stopping an event handling loop from another loop

[jfalesi]

Hi, I'm working on a VI that will be run in one of two modes. In one mode, the user will stop the VI manually via a "stop" button which is handled by an event structure. In the other mode, the VI is started via Start Asynchronous Call and stopped on-command from the calling VI (using a queue). To stop the loops, I tried wiring the Stop tag to an "or" inside the event loop, but the event loop just sits there and waits for an event even though one of the "or" inputs is already "True". So I resorted to defining a user event. Is there a better way to handle shutdown? 

[RavensFan]

Attach an actual VI rather than a screenshot so we can see what you are doing.

I don't even see the OR you are talking about.

You could use a timeout on your event structure so that the loop runs occasionally looking for your stop.  Or use a Stop button with a Value Change event.

[jfalesi]

Sorry, I used the "Create VI Snippet from selection" function. Is that not how snippets work?

I deleted the "or" because it didn't work... it looked like the attached image. The VI has a stop button and a value change event (for when it is run manually), but I want the VI to be able to be stopped by the VI that called it asynchronously ("automatic" mode). I passed the target VI a queue for this purpose, so I would like the queued message handling loop to be able to stop the UI event loop. I will try using a timeout on the event structure.

[RavensFan]

Pick a method.

Right now you aren't even using the User events.  If you right clicked on the event structure and picked Show Dynamic Events, then you can wire in your event registration and create a stop event for it.

Or get rid of it and allow the channel wire to do its job along with the timeout you do have there now.

Or use your queue commands.

Figure out what you want your master loop to be.  Right now it looks like the QMH loop because that is where the channel wire originates.  But, often the UI Event Loop would guide what a program does.  Your VI shows a Dequeue in the QMH loop, but I don't see where you ever enqueue a command to execute the Stop case.  Or any case for that matter.

It's like you through 3 different concepts together but in an incomplete manner and were just hoping they would all magically work together.  Is this VI a subVI within a larger program?

[Bob_Schor · Accepted solution]

Thanks for attaching the VI.  It shows me that you are using LabVIEW 2018.  In LabVIEW 2017, the Event Messenger Channel was introduced that allows you to pass a User Event to an Event Loop using (you guessed it,) an Event Messenger Channel.  This is much better than the LabVIEW 2016 method of using a Tag Channel and a 100 msec Timeout Event that periodically read the Tag (it got wired to the Stop Indicator).

Bob Schor

[jfalesi]

---

@RavensFan wrote:

Pick a method.

Right now you aren't even using the User events.  If you right clicked on the event structure and picked Show Dynamic Events, then you can wire in your event registration and create a stop event for it.

Or get rid of it and allow the channel wire to do its job along with the timeout you do have there now.

Or use your queue commands.

Figure out what you want your master loop to be.  Right now it looks like the QMH loop because that is where the channel wire originates.  But, often the UI Event Loop would guide what a program does.  Your VI shows a Dequeue in the QMH loop, but I don't see where you ever enqueue a command to execute the Stop case.  Or any case for that matter.

It's like you through 3 different concepts together but in an incomplete manner and were just hoping they would all magically work together.  Is this VI a subVI within a larger program?

---

Yes, it's a sub-VI within a larger program. It is meant to be run in either "manual mode" in which stopping is handled by the UI event loop (and the calling VI waits synchronously for the VI to stop) or in "automatic mode" in which it is called asynchronously by and controlled from the calling VI (hence the "GPD Message" queue - the calling VI does the enqueueing). The purpose of my post was to determine if there was a cleaner way to stop the UI event loop from the QMH in the case in which the VI is called asynchronously and receives the "stop" command from the calling VI (cleaner than defining a user event, which seems tedious). The best solution appears to be the Event Message channel (thanks, Bob Schor). When I chose the file to upload last time, the dynamic event terminals were there, but by the time I clicked "Post", I had removed them and re-saved the files. Evidently, the UI doesn't upload attached files until "Post" is clicked.