Kill lonely clones vi without close Project windows

[Bobillier]

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.

[Bobillier]

Like this:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Abort-Asynchronous-Called-VIs-when-the-parent-stops/idi-p/1734792?profile.language=fr

 

[ensegre]

Interactively in the IDE,

Programmatically, I'd be sure it can be done with VI server invocations, the only difficulty might be in getting the exact ref to each individual clone - but I sort of remember that there is a way which I've used in the past.

[ensegre]

check also

 

Edited March 24, 2021 by ensegre

[ensegre]

16 minutes ago, ensegre said:

I sort of remember that there is a way which I've used in the past

Ah yes:

 

[Bobillier]

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 March 24, 2021 by Bobillier

[ensegre]

43 minutes ago, Bobillier said:

I show it in memory with this kind of tool

I don't know about that tool, but doesn't Task Manager help, instead?

[Bobillier]

Ok I will make test with Task Manager, but like it's similar tool, I think than I obtein same result.

[Francois Normandin]

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)

[drjdpowell]

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.  

[Francois Normandin]

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.

 

(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 March 26, 2021 by Francois Normandin

[Bobillier]

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.