Abort Asynchronous Called VIs when the parent stops

[JimZ1]

Currently when a vi is called asynchronously, it will live - even when the calling VI stops.  This may cause problems in some cases - for example, code that uses the "first call" function.  During development, it is not unusual to have a VI stop inadvertantly without proper cleanup.  With Asynchronous VIs running in the background, you must shutdown and restart your project to clear out these Asynch VIs.  It would be nice to have an option on the OpenVI function that caused the Asynch VIs to abort in the event that the calling VI shuts down inadvertantly.

[AristosQueue (NI)]

While debugging, you may want to pop open the front panels of your asynchronously launched VIs so that you can hit the Abort button on them. That avoids closing the project and relaunching it.

[JimZ1]

That is an excellent idea.  The downside is that if you have the front panels open on the desktop, they are distracting and if you open them minimized, then they are hard to find in the long list of vis I usually have open.  Again, a workable solution, but it would be preferable if LabVIEW just took care of it for you.

[AristosQueue (NI)]

Folks in LV R&D discussed the abort issue when designing the ACBR. Just to be clear about the behavior:

• If you launch your VI using the "start and wait", when the top-level VI aborts, the launched VI will also abort. In this case, it behaves like a subVI.
• If you launch your VI using the "fire and forget", when the top-level VI aborts, the launched VI will keep running. In this case, it behaves like an independent VI.

So this idea is specifically about the "fire and forget" mode.

R&D's position has been that the whole point of "fire and forget" was to make the VI independent of the caller and the caller can completely exit without shutting down the launched VI. This is the same kind of problem that already exists with the Run VI method that LV has had for years. There are various threads on ni.com and LAVA discussing this, and the folks responsible for this feature may change the behavior in the future as a result of that feedback. We'll see what kind of discussion happens on this idea...

[JimZ1]

This is good information.  Based on a quick trial - the notion that you do a call and collect, but never collect will provide the same capability as I am asking for.  Great.  I may be missing something but could not find that behavior described in the help for the options on open VI reference or the asynch call functions.  I did eventually find it in the example code.  I suggest that this somehow work its way into the documentation.

[AristosQueue (NI)]

> but never collect

Doing that generally is a bad idea. LabVIEW will hold memory allocated for the results of that run until you actually do the collection or the VI that did Start goes idle. More and more memory will be allocated. It might be fine to do this during a debug session, but make sure you change back to Fire And Forget before you actually release your application.

>  I suggest that this somehow work its way into the documentation.

I'll flag a tech writer to investigate and update.

[Darren]

Any idea that has received less than 6 kudos within 6 years after posting will be automatically declined.