How to find VIs still running in the background?

[Stobber]

I'm working in LV 2013. What tool does everybody use to find VIs that are still running in the background. Yes, this is an AF app.

[jcarmody]

Will this work - http://lavag.org/files/file/117-abort-vi/

[JamesMc86]

I've been using LabVIEW Task Manager - http://lavag.org/topic/18322-cr-labview-task-manager/

 

Not sure how useful it will be to spot them though, good if you need to get at one you know is running but I think they will all remain at runsub state if loaded.

[hooovahh]

Will this work - http://lavag.org/files/file/117-abort-vi/

The Abort VI doesn't work in this case.  Clones don't show up in the All VIs in Memory.  The best technique at the moment is for all VIs in memory that are clones, try to guess the VI name (with the instance).  Which I believe is what the Task Manager does.

[chris754]

Why not put watchdogs in the VIs that will automatically kill the actor when the you main VI is off, at least for testing purposes. This is what I typically do in these types of situations, as then I do not have to worry about finding any rogue processes.

[hooovahh]

There are cases where a graceful shutdown just doesn't happen.  During development weird things may happen, that's why it is development.  You should never use the abort VI right?  CTRL + <Period>  But it happens from time to time.  

 

For what ever reason you aborted a VI and didn't run clean up.  So you didn't automatically kill the rogue actors.  Closing and restarting LabVIEW is an option, but a quicker option would be an abort all VIs (including clones).

 

EDIT:  I re-read you post and I don't hate it but then you are constantly polling in each actor right?  Or you have an actor that just monitors the top level VI activity and sends the abort to the other actors if needed.

[chris754]

Correct. I have a watchdog.vi in the top-level VI, with watchpuppy.vi in each actor. The watchdog sends out an event every so often (about 1sec), if the watchpuppy doesn't receive an event in say 1.5 secs, it aborts the vi. I can post an example if you'd like. They are easily removed or disabled later if you decide you do not want them in the final version. Although I usually keep them.

[hooovahh]

I can post an example if you'd like. They are easily removed or disabled later if you decide you do not want them in the final version. Although I usually keep them.

Absolutely.  While I'm sure this type of thing has been done many times over I would find value in seeing this and I think others might too.  If you want to drum up more discussion on your implementation feel free to make a new topic on it.

[chris754]

Will do. I should be able to find sometime to drum up a reduced version of this to show my implementation without the noise of a larger program.

[drjdpowell]

Correct. I have a watchdog.vi in the top-level VI, with watchpuppy.vi in each actor. The watchdog sends out an event every so often (about 1sec), if the watchpuppy doesn't receive an event in say 1.5 secs, it aborts the vi. I can post an example if you'd like. They are easily removed or disabled later if you decide you do not want them in the final version. Although I usually keep them.

If your actors are dynamically called, you can use a Queue or other reference created in the top-level.  When the top-level goes idle it destroys the reference and this can be used to trigger an error in the watchdog.  I stopped bothering to write shutdown code for most subactors a while ago and happily hit the top-level abort button if needed.

[hooovahh]

If your actors are dynamically called, you can use a Queue or other reference created in the top-level.  When the top-level goes idle it destroys the reference and this can be used to trigger an error in the watchdog.  I stopped bothering to write shutdown code for most subactors a while ago and happily hit the top-level abort button if needed.

I never thought of that, but I use User Events not Queues.  So while the reference will still be destroyed, I wouldn't have any idea it was destroyed unless I again polled the reference to see that it was still valid.

 

EDIT:  Maybe I could get away with just the watchdog actor polling the reference, and the other actors being told by the watchdog to shutdown if the reference goes invalid.

[drjdpowell]

I never thought of that, but I use User Events not Queues.  So while the reference will still be destroyed, I wouldn't have any idea it was destroyed unless I again polled the reference to see that it was still valid.

 

EDIT:  Maybe I could get away with just the watchdog actor polling the reference, and the other actors being told by the watchdog to shutdown if the reference goes invalid.

Yes, I encountered the same problem with User Events.   I now use a watchdog Queue separate from communication.  No one ever posts data to this Queue; the watchdog just waits on it to be destroyed.  When it does, it posts a shutdown message on the communication Queue/UserEvent (which is always created/owned by the receiving subactor). The watchdog does have to do polling, not on this watchdog Queue, but rather on the communication reference itself, as the watchdog must also abort itself if the subactor shuts down.

 

An advantage of a watchdog Queue separate from communication is that the subactor can continue to receive messages from subsubactors that it has created, should it need to as part of its shutdown procedure. 

[chris754]

Here is my watchdog example. Just threw this together this morning, so not the greatest coding job, but shows one way I implement this type of thing. Just run the Test-Main.vi. It will launch an "actor" (not a real actor, but something to act as one). If you use the abort, the watchdog will kick in a close the clone, if you use the stop the shutdown will kick in and close the actor. I use a user event within the actor to tell my watchpuppy to stop if the actor has finished its task.

WATCHDOG EXAMPLE.zip

Edited August 15, 2014 by chris754

[lvb]

David,

 

I have been asking this question for years!  See http://lavag.org/topic/16660-how-to-get-actual-vi-execution-state/

Does this provide you with a solution?

[QueueYueue]

This only addresses the AF part of this questions, but my Monitored actor tool helps with problems like this. It basically gives you a UI (in the dev environment only) that lets you see actors currently running. It also gives you some hooks to aid debugging. This lets you send stop messages to actors that you've forgotten about in your code or open a running actors Actor core instance.
 

Checkout the package posted here https://decibel.ni.com/content/thread/18301. once installed you just need to use the "monitored actor Switcher" tool in your tools menu to change your current actors to monitored actors (note: this is just changing the inheritance. Instead of inheriting from actor, you'll now be inheriting from monitored actors(which inherits from actor). It's not changing any of your code)

Edited August 22, 2014 by QueueYueue