Quit LabVIEW node does not work if invoked by Start Asynchronous Call

[_Y_]

I encountered a strange behaviour of Quit LabVIEW node. If the node is placed in a VI that is started by Start Asynchronous Call, LabVIEW environment is not closed. Only the asynchronous process is stopped (but the VI is not unloaded).

The same happens if EXE file is built and started.

Such a behaviour looks strange for me.

Could someone explain what is wrong in my perception of Quit LabVIEW node?

A small project is attached.

LabVIEW 2011

QuitLabVIEWnodeQ.zip

[asbo]

Repros for me on LV2011 SP1.

I think this is a legitimate bug, I would go ahead and submit your test case to NI: http://ni.com/ask

[_Y_]

asbo, thanks for reply. I should wait for few days. May be some one already has an info about it. It is in LV2011, nothing too new:)

[Aristos Queue]

I confirmed this behavior. Yes, that is definitely a bug. I have filed a CAR to get this fixed in a future LV version.

[EDIT: I confirmed it is still a bug in LV 2012.]

[Further edit:

If you call Quit LabVIEW from any VI that was *not* launched through the ACBR, it does quit LV, including shutting down all VIs that were launched through ACBR. If you call Quit LabVIEW within any hierarchy that was launched with ACBR, it only stops that hierarchy. This definitely seems like a bug, but it will be Monday before I could ask anyone who knows that subsystem intimately.]

[Rolf Kalbermatter]

While it seems like a bug, I would like to point out that "Quit LabVIEW" is almost never the right thing to do. If you build an application, this application will normally quit as soon as the last LabVIEW window is closed, either through the button in the right upper corner, or through a property or method node to close that front panel. You also need to make sure that you haven't somewhere hidden front panels but this is simply proper application development. Quit LabVIEW will tear down everything wherever it is and is similar to the abort button in the toolbar. While the abort button has some merits during debugging if you get stuck somewhere (and haven't locked yourself out by a modal dialog) the Quit LabVIEW node is always a runtime operation and designing the application to simply make sure to close all front panels when it should quit is much cleaner and allows the various possible VIs, including deamons running as hidden top level VIs to properly close down and release whatever resources they may have allocated.

In the development environment Quit LabVIEW is a terrible thing! It will shut down LabVIEW which is never what I would want during development.

[asbo]

In a built application, you can have the VI complete normally (everything on the BD executes) and it will drop back to a non-running state (like it would in the IDE), but not close. Maybe there's a window setting wrong, but that's the kind of instance I use Quit LabVIEW in.

I have seen one or two project where once in a while, they hang on shutdown for no apparent reason - BD is done, no asynchronous tasks, and yet it still won't quit. The solution in that case was using taskkill as part of cleanup, but I suspect Quit LabVIEW may have worked as well.

[Rolf Kalbermatter]

In a built application, you can have the VI complete normally (everything on the BD executes) and it will drop back to a non-running state (like it would in the IDE), but not close. Maybe there's a window setting wrong, but that's the kind of instance I use Quit LabVIEW in.

I have seen one or two project where once in a while, they hang on shutdown for no apparent reason - BD is done, no asynchronous tasks, and yet it still won't quit. The solution in that case was using taskkill as part of cleanup, but I suspect Quit LabVIEW may have worked as well.

You need to also close the front panel as last action after the VI is finished and make sure you don't hold on to VI references anywhere too. A VI is kept in memory by either an open VI front panel or an open VI reference (that can be managed by the VI itself, either by opening such a refnum explicitedly or by passing refnum ownership to the VI when you launch it with the Run method.

Once the last VI has left memory a LabVIEW application will terminate itself. If it doesn't you have either still open a VI somewhere, maybe as hidden front panel (hidden does not mean closed) or are most likely stuck in a synchronous call to external code, such as a DLL call. And here Quit LabVIEW can't help either as Quit LabVIEW has not have any more powers than the Abort button, and that one can't terminate stuck external calls either. Here a task kill is the only solution if you can't somehow persuade the external code to relinquish control back to the calling LabVIEW program.