Jump to content

Kill lonely clones vi without close Project windows


Recommended Posts

Hello
I would like to know if there is a way to kill vi clones that are running in the background without needing to close the project to which they belong. I am currently working on the development of an application based on DQMH and I happen to lose my hand and its VI clones keep references open but not accessible. Preventing me from editing the source vi of these clones. The only solution in this case is to close the project so that it permanently stops these clones.

Link to comment

Ok Thanks Ensegre.

But I have forgotten one detail, The DQMH 5 uses "Start asynchronous call.vi", which load and forget clones. In normal usages, it's DQMH that includes a mechanism to associate the clone to one numerical identifier (ID) and not the clone ref. When you when stopping the clone, you send specific command with ID. But in some cases of problems, the ID can be kill without stopping the clone. In this case, the clone stays in memory, and there is no simple possibility to stop it. I show it in memory with this kind of tool, but when I ask it to kill clone Vi, that generates one error message. The reason, I think, is that the clones are in "Load, run  and forget" mechanism and it's not possible to kill them directly.

And like until one clone ref run, I can't pass source clone vi in edit mode.

The only way stay to close the project, but it's a bit not practical.

  

Edited by Bobillier
Link to comment

You might want to inspect JKI SMO's way to handle this. The SMO Process has a "passive watchdog" that monitors a single-element queue and gracefully exits if the asynch process completes normally... but it will stop the whole asynch thread if the queue reference goes idle. 

Note that you should use such a mechanism only if you always want your asynch process to get killed in case of a caller going out of memory. (This should be an ultimate way to exit, not a normal way...)
SMO process still tries to abort before it ultimately kills the thread.

(This is a screenshot from SMO:Process.vi)

image.png.aec7cc968112a0562c151402f4e30c9c.png

Link to comment
1 hour ago, Francois Normandin said:

The SMO Process has a "passive watchdog" that monitors a single-element queue and gracefully exits if the asynch process completes normally... but it will stop the whole asynch thread if the queue reference goes idle. 

Messenger Library uses the same watchdog mechanism, although I just trigger normal shutdown via an "Autoshutdown" message ; I don't call STOP.  I would have thought 500 ms is too short a time to wait before such a harsh method.  

Link to comment

I assumed Messenger did this too, although I don't use it. 🙂

In SMO, it's a settable parameter by the user based on their needs. The SMO process itself actually should abort in a few milliseconds, so it is heavily dependent on the process overrides.

image.png.4da4e923e5a397bee23df7436ca494bc.png

 

(edit for clarity) The STOP call is a last resort in case the "autoshutdown" message does not work. Even if enqueued at the front, when the actor loop is locked because a "do" is performing a blocking action, stop will kill the thread. Also, Stop will effectively handle a parallel loop that is running concurrently to the actor message handling loop and does not implement correctly the shutdown messages. I daresay it should never happen in production code. The onProcessKill override is provided to have a way to log this event when it occurs. If the developer killed the caller in development mode, that's fine and can be ignored. If it happens in production code, it should be a concern.

 

Edited by Francois Normandin
Link to comment

Thanks for this idea. Unfortunately this type of mechanism does not exist natively in the DQMH framework. A future evolution perhaps? I will suggest it on the DQMH forum.
Either way, it would be nice if the LabVIEW IDE offered it natively without needing to code it in programs.
It's like for the vi which have Modal windows and which we forget to close before launching their proprietary program and which blocks the front panel and prevents us from all actions. Also a small keyboard shortcut in the IDE would be useful.

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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.