"Quit LabVIEW" primitive doesn't work in Actor Framework with LV2011 or LV2012

[David_Staab]

[David_Staab]

This document was generated from the following discussion: AF exe doesn't leave memory when exiting

I did it so we could attach code. I also think the content should be a first-class member in the group for those trying to build and deploy applications in LV2011-2012.

19 Mar 13 Update:

I worked with the NI AEs to find a workaround in Windows: Use the "killtask" command at the command line. Since the "Application Instance Close" event won't fire when doing this, you have to generate a User Event and wait a short time before executing the command. I've attached an example that does this.

=================================

Ben_Phillips wrote:

Is there any followup to why the Quit LabVIEW function sometimes fails to blast an actor framework exe out of memory? 

AristosQueue wrote:

Yes.

A) The bug is that the Quit LV function does not work when called from a VI launched through Asynchronous Call By Reference. That means if it is called from any Actor Core.vi or its subVIs.

B) This bug should be fixed in the current beta of LV 2013. To test it, visit http://ni.com/beta to sign up for the beta program and (if approved) download the software.

David_Staab wrote:
Well that's good to know for my LV2011 AF application. I had planned to create a launcher VI that closes itself after launching the top-level UI actor so the app doesn't show two tiles in the Windows Taskbar. Is there a way to accomplish this and still be able to make the EXE exit when the app stops running?

Not sure, but I think that it will work just fine if you start a VI running using the Run VI method and have it invoke the Quit LabVIEW node. Not the Call By Reference node, but just wire a Static VI Reference to the Run VI method with FALSE wired to the terminal for whether to wait for it to finish. That subVI will then be running as a top-level VI on its own... and the only thing on its diagram would be the Quit LabVIEW node. I think that will work. Haven't tried it, but based on the description in the CAR, I think it will work.

After tomorrow, I'll be on vacation for two weeks. Ping user niACS if you need more AF help in that interval or post on the regular NI forums and get an AE to start a support ticket.

In LV2011 SP1, it looks like this only works with debugging enabld in the application. I've attached a project I used to test it.

[tst]

In LV2011 SP1, it looks like this only works with debugging enabld in the application.

The Run VI method seems to need the FP of the subVI for some reason (although I have no idea what that reason is). You just need to have the subVI not strip its FP (most easily done by putting a control on the FP and creating a property node linked to it).

[rolfk]

The reason that the Run method needs a front panel is supposedly that said VI executes specifically as its own top level hierarchy. The way LabVIEW handles top level VIs is that it manages them through an instance that is tightly tied to the front panel (or at least something in the front panel). SubVIs are referenced by their parents but top level VIs don't have a parent and still need to be somehow managed and referenced. The way LabVIEW does this, most likely for anecdotal reasons, is through its frontpanel. Whenever you blast the frontpanel of a top level VI out of memory its entire hierarchy immediately aborts all operation.

Another thing I would like to add to this topic is that there is another reason for the Quit primitive to do nothing. Since around LabVIEW 8.2 when the Quit VI is inside a VI that has an event structure that registers for the Application Exit event, the Quit simply does nothing. There seems to be some race condition somewhere. I found that adding property nodes to open the front panel (even in hidden state) and closing it after some delay (<10 ms seems to small on my computer, 50ms seems to work on all computers I have tried so far) just before calling the Quit LabVIEW function works around that problem.