Jump to content

How to find VIs still running in the background?


Stobber

Recommended Posts

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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. 

Link to comment

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 by chris754
  • Like 1
Link to comment

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 by QueueYueue
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.