[New Feature] List Running VIs to be Aborted on Quit/Close

[weirdUncle]

I have been looking into this and I am not clear on what is happening.  There has been no change at all (as far as I can tell) to the logic in LabWIEW around the Abort VI Method regarding what execution states from which VIs can and cannot be aborted.  The abort of a VI happens without error on a "top level" vi.  When it is aborted, it will stop any subVIs it has caused to be running.  When all the "top level" vis are aborted, everything should be aborted.  If you try to abort a subVI which is not at the top level, you get the error.  That is true for both reentrant and non-reentrant VIs.  If you are looking at a reentrant VI's panel, and it is idle, you can push GO and it will be a top level VI and it will abort without the error.

What do we mean by "top level" vi?  A vi you pushed GO on, or did the run method on are the common case.  Other situations are VIs called from an interface into LabVIEW from the outside.  Also there are VIs running due to an Async Call By Ref Fork and Forget node.  There is no practical way to get a direct reference to the ACBR fork and forget VIs, so they possibly pose a related problem, but it is not a new problem in 2021.

So... If you are trying to open references to reentrant clones by name and aborting them, that probably won't work.  I cannot see what your VI is actually doing.  Where did all the "thread###.vi's" come from?  Is this something which has worked in the past and now does not work?  What happened in 2020?  I need some help trying to identify what is actually wrong and would appreciate and information leading the way.  Help will be appreciated.

[Christina_R]

---

@DanyAllard wrote:

The VI Abort invoke node don't seems to work anymore on clone VI's

Hi Dany,

To summarize what Steve said in his recent post, we're not sure we understand what situation used to work. You can't abort subVIs (including clone VIs).

Can you tell us more about how the clone VIs in your picture were created? Or perhaps provide an example that shows what used to work and now doesn't?

Thanks!

[DanyAllard]

I made an example code to illustrate what is not working. See attachement

Edit: the VI is saved in 2020

[Christina_R]

---

@DanyAllard wrote:

I made an example code to illustrate what is not working.

---

The dev team and I discussed your example. While we agree that LabVIEW is missing a way to abort these VIs, the Abort VI method only works for top-level VIs, and VIs executed by Start Asynchronous Call (even with "call and forget") aren't currently categorized as such. (Start Asynchronous Call is more similar to Call By Reference than to executing with the Run VI method).

Also, it looks like this behavior isn't new to LabVIEW 2021.

We'll consider adding a way to abort execution of these types of VIs in the future. If you'd like, you and I could arrange a time to discuss your use case, which would help me understand how urgently this functionality is needed.

[drjdpowell]

Idea: you might try opening a reference-by-name to the "Proxy Caller" that shows up in Call Chain on an ACBR VI.  Theoretically, that is the "top-level VI".

[DanyAllard]

I have tested my VI with LabVIEW 2013. I have the same behavior. So I seems to work like that for a will.

But I think that should be changed to be able to abort Asynchronous call. Since that create thread running in background, it could be very useful to be able to use the abort invoke node to kill those background thread.

A workaround that I use currently is to find those Clone VI's that are running in background, open the Front Panel and manually click the Stop button on each one.

So in this case I don't have to close my project to kill those running VI and be able to unlock Libraries/Classes and continue working on my project without restarting the Project. 

Sometime some project can take a couple of minutes to load. So It should be very nice to have this feature.

Thank you

Dany

[DanyAllard]

I found where my confusion came from... I made this change to my VI and the Thread VI State change from Running to Run Top Level 

My old code use mostly Run VI as way to start my Thread VI. At this time I was able to to abort all my Thread with one click.

[DanyAllard]

---

@Christina_R wrote:

---

@DanyAllard wrote:

I made an example code to illustrate what is not working.

---

We'll consider adding a way to abort execution of these types of VIs in the future. If you'd like, you and I could arrange a time to discuss your use case, which would help me understand how urgently this functionality is needed.

---

That's great... I hope in a near future because it's currently a pain when you use Asyc Call and your app crash and you need to restart your project just to unlock your Libs/Classes to continue working. 

Thank you Christina

[DanyAllard]

---

@drjdpowell wrote:

Idea: you might try opening a reference-by-name to the "Proxy Caller" that shows up in Call Chain on an ACBR VI.  Theoretically, that is the "top-level VI".

---

I tried and the Open VI Reference Return an Error 1035 Operation is invalid for this type of VI

Maybe we need a special flag for this one

[sth]

Even if that clone was launch

---

@Christina_R wrote:

---

@DanyAllard wrote:

The VI Abort invoke node don't seems to work anymore on clone VI's

To summarize what Steve said in his recent post, we're not sure we understand what situation used to work. You can't abort subVIs (including clone VIs).

---

Even if that clone was launched asynchronously?  Especially as a "launch and forget"?  I do this all the time and have all those clones running around and cleanup is a mess.