SURE FIRE WAY of KILLING (STOPPING) a LabVIEW-based EXE APPLICATION

[Anthony_L · Accepted solution]

OK, the LabVIEW application was too detailed (large) to post. 

This one had multiple running parallel loops, plus: user events, queues, notifiers, semaphores, etc. 

Eventually, I did all of the following to make the app FINALLY EXIT:

Here are the six (6) code snippets that I had to use.  In my case, all of them were applicable to the LabVIEW application in question.

[RTSLVU]

Did you figure out what exactly was causing your program ti not exit cleanly?

Because IMHO all of those things except for #6 should always be done. (Ignoring stopping parallel loops with a local or global is questionable in a large application)  

Personally I am a fan of the Channeled Message Handler. Every parallel loop has an "Exit" state except for my GUI that uses a User Event. My main control loop can send an "Exit" command to all of them to stop each loop, then waits for an ACK from each one that the Exit state has run and quits.

[Anthony_L]

Surely: it was the QUEUE and NOTIFIERS. Some had 20 sec wait times.

 
On exiting, processes stopped running so queues were just waiting. 

The GLOBAL exit is a no re. It just emphasizes the need for ONE GLOBAL EXIT variable. 

Because sometimes there is a tendency to use local EXIT variables for some loops in subVIs. 

[NIquist]

---

@RTSLVU wrote:

Did you figure out what exactly was causing your program ti not exit cleanly?

Because IMHO all of those things except for #6 should always be done. (Ignoring stopping parallel loops with a local or global is questionable in a large application)  

Personally I am a fan of the Channeled Message Handler. Every parallel loop has an "Exit" state except for my GUI that uses a User Event. My main control loop can send an "Exit" command to all of them to stop each loop, then waits for an ACK from each one that the Exit state has run and quits.

---

+1 for always keeping track of and closing all references.

My usual technique to stop parallel loops is to use a main queue or notifier and monitor its status in slave loops.  Then when I close that reference in the EXIT state of the main loop, the Get Status VIs throw errors and end all the slave loops.

[Yamaeda]

---

@Anthony_L wrote:

I think that there should be a way of THROWING some sort of GRENADE to make the F**ing LV app STOP RUNNING!!!

---

SystemExec Taskkill [yourprogram]

[billko]

---

@Anthony_L wrote:

Surely: it was the QUEUE and NOTIFIERS. Some had 20 sec wait times.

 
On exiting, processes stopped running so queues were just waiting. 

The GLOBAL exit is a no re. It just emphasizes the need for ONE GLOBAL EXIT variable. 

Because sometimes there is a tendency to use local EXIT variables for some loops in subVIs. 

---

So you don't send a message to the queues telling them to exit gracefully?

[Anthony_L]

Hey:

It was not ignored. 

That concept can NEVER be ignored. I just added other things ontop of that. And made sure that a UNIVERSAL EXIT GLOBAL was in place and is seen by all subVI loops.

Not just local variable STOP booleans.

[billko]

So is this an academic discussion or are you really having issues with LabVIEW not exiting?  If it's the latter, I think it's a better use of your time to figure out why your code isn't exiting instead of trying to figure out a way to kill it.  It is highly likely that it's something you're doing and not something LabVIEW is doing.  Once you figure it out, you won't need to nuke your app.

[Anthony_L]

Already solved by self. 

Took me couple of days to figure out the solution.

Please see response marked as a solution.

I was working in a group of developers back in the days of LabVIEW 2009 and we experienced similar challenges. Now I know why!

Its a likely challenge in large apps with multiple parallel loops, notifiers, semaphores, user events, and queues. Which was the case for this app.

Anthony