LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to programatically abort all running VIs in development environment on Windows

Is it possible to programmatically abort all running VIs in a project?

 

Background: I am developing a DQMH application on Windows. Sometimes one or more of the DQMH modules fail to close. This happens for a variety of reasons, all of them bugs in my app that are being fixed one at a time.

When this happens, I intentionally close the project to ensure a "clean slate" before running the application again. This brings up the Abort Running VIs window, an example of which is seen below. The Abort Running VIs window successfully finds and closes all the DQMH Main VIs that are running.

Closing a project aborts all running VIs in the project (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This works but has the downside of having to load the project again.

 

In effect my question is: Is it possible to programmatically achieve the same as what the Abort Running VIs window achieves? In other words, is it possible to 1) programmatically get the list of all top-level running VIs and 2) abort those VIs?

 

Please note that running the "Emergency Abort" VI presented in the LabVIEW for Everyone book does abort some of the running VIs, but does not detect/does not abort other VIs. It may be that VI instances launched by the Asynchronous Call By Reference node, which is the case with the DQMH Main VIs mentioned above, are not detected by the Emergency Abort VI, but I am not sure of this yet (haven't tested enough).

Thanks!

0 Kudos
Message 1 of 4
(421 Views)

I wrote this a few years ago.  You should be able to modify it for your purposes.
Abort VI - LabVIEW IDE - LAVA

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 2 of 4
(381 Views)

Darren shared this, too.

Darren's Occasional Nugget 08/11/2008 - NI Community

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 3 of 4
(379 Views)

Hi Jim,

 

Thanks for pointing me to the Abort VI.vi that you kindly created and to the Abort.vi that Darren shared.

 

Both VIs, as well as the Emergency Abort.vi I have been using for a few years (inspired by a VI I read about in the LabVIEW for Everyone book), are able to abort VIs when those VIs are launched via the Run VI method, but are unable to detect or abort VIs that were launched via the Start Asynchronous Call node.

 

In other words, all three Abort VIs that I am aware of work well when the VIs that need to be aborted were launched via the Run VI method.
Run VI method.png

 

 

 

 

 

 

None of the Abort VIs that I am aware of are able to detect or abort VIs that were launched via the Start Asynchronous Call node.

Start Asynchronous Call node.png

 

 

 

 

 

 

 

The latest version of the DQMH framework (version 7.0) uses the Start Asynchronous Call node to launch the Main VI of each DQMH module.


However, the built-in Abort Running VIs window - the window that pops up when attempting to close the project when VIs are still running - correctly detects all running VIs, regardless of whether they were launched via the Run VI method or the Start Asynchronous Call node.

That's why my question is: Is there a way for us (LabVIEW programmers) to programmatically replicate the behaviour of the built-in Abort Running VIs window? So far I have been unable to replicate its behaviour.

I have created the following public GitHub repository to show the issue: How To Abort VIs Launched By Start Asynchronous Call Node (GitHub repository). The repository contains the following project. The virtual folders at the top of the project server as instructions towards replicating the behaviour I am seeing.


LabVIEW Project Notes.png


 

 

 

 

 

 

 

 

 

 

 

 

 

 

Thanks

0 Kudos
Message 4 of 4
(336 Views)