Jump to content

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


_Y_

Recommended Posts

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

Link to comment

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.]

  • Like 1
Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.