Labview executable does not exit memory when closed

[User002]

---

@pacman326 wrote:
Hello everyone. I have been tasked with upgrading some of our vis from labview 6.0 to 8.5.1 . I was able to create new executables and run the vis just fine in 8.5. However, when I close the vis in question, the window dissapears just fine, but the process remains in memory causing me to have to go to the task manager and manually kill the process. Does anyone know what generally might cause this sort of problem to occur? This did not happen when the program was in version 6.0. Thank you for your help.

---

Are you running the program on a Win XP machine?

If yes, see if it works on a Win 7 machine.

[MrJackHamilton]

Hello All,

I am seeing this problem still in LabVIEW 2013 SP1... the exe won't get out of Windows memory, Main FP is gone, but the icon remains in the Win7 task manager, and you have to kill the exe in the taskmanager. This is a SERIOUS problem when  you run the exe a second time with the 'hung' exe still going. My users did not notice the ghost was sill running and the DAQ calls get pretty screwed when running this odd double-instance of the same exe!!!!.

My code is NOT using VI server to call  VI, but I still had the problem. From reading other posts, I got it to quit by hitting all possible causes. I am using one (only one) event structure, I have 4 other threads running via queues and an ethernet cDAQ-9188 chassis. The ethernet DAQ seems to need more time for the initial connect and maybe disconnect.

Solution:

1. Event Structure: "Panel Close?" - Do NOT Discard the kill task. (do it conditionally, if your in development)

    Put all your quit clean up code IN the event structure "Panel Close?" state

2. Put the LabVIEW Exit in a conditional case:

   http://digital.ni.com/public.nsf/allkb/4B2CAA3159737AFD86256F2B00788A79

3. Make sure the LabVIEW Exit happens AFTER your clean up calls, wire error out clusters to the Conditional disable to assure they run FIRST-  before the LabVIEW Exit.

4. Add a DELAY of 1-2 seconds before the LabVIEW Exit....

Volia!.

I guest the LabVIEW exit fails to execute if clean up tasks are still in process. (it's too polite IMO)...assuring all the cleanup\shutdown of other threads is done...then waiting some more....seems to allow the Exit to run, as expected. Thanks NI for changing stuff! Grrrr...back in the day you NEVER used the LabVIEW Exit funciton, as it used to kill the entire Runtime engine!...But things have changed.

Regards

Jack Hamilton

[crossrulz]

If your system was shutting down properly, you won't need the Exit LabVIEW function.  Sounds to me like you have something waiting for a command or something like that.

[nathand]

---

MrJackHamilton wrote:

I guest the LabVIEW exit fails to execute if clean up tasks are still in process. (it's too polite IMO)...assuring all the cleanup\shutdown of other threads is done...then waiting some more....seems to allow the Exit to run, as expected. Thanks NI for changing stuff! Grrrr...back in the day you NEVER used the LabVIEW Exit funciton, as it used to kill the entire Runtime engine!...But things have changed.

---

I'm with crossrulz on this one - it's your code, not LabVIEW. I haven't seen any changes in how LabVIEW handles this. Adding the Exit function forces your application to quit, instead of you finding out why it's not shutting down properly and correcting the logic.

If no code is running and all front panels are closed, a LabVIEW-built executable will exit.

[MrJackHamilton]

I would believe that to be the case, IF the code also hung on exit in development. But it does not. I am not aborting the VI when running in the Dev. environment.

I really think it's the cDAQ Ethernet, I've seen some very odd behavior where it take several seconds to execute a task, like opening a relay, meanwhile NOT throwing any errors at all. I click the VI relay button, it completes execution, then several seconds later, we heard the relay click.

I was able to alleviate this by, resetting the cDAQ on open, but it still occassionally crops up.

Changes: There have been in the recent past. The typical, way to close a VI was to execute the 'Front Panel:Close' property node...but that's gone.

Regards

Jack Hamilton

[nathand]

---

@MrJackHamilton wrote:

Changes: There have been in the recent past. The typical, way to close a VI was to execute the 'Front Panel:Close' property node...but that's gone.

---

Not sure what's changed here, that method still exists in LabVIEW 2014... (although it's a method, not a property)

[natasftw]

---

@MrJackHamilton wrote:

Thanks NI for changing stuff! Grrrr...back in the day you NEVER used the LabVIEW Exit funciton, as it used to kill the entire Runtime engine!...But things have changed.

---

You posted to a thread that was dated from 2008-2012.  How far was this "back in the day" you reference?

[MrJackHamilton]

natas,

I've been coding in LabVIEW since version  1.1, al la 1987...I think the Exit issue was resolved in LV 6.1.

I don't have a problem with changes, it issue is Front Panel=Close property node worked for several versions, it's okay to add the Invoke node version, but why remove the property node?. this breaks exsiting implementations. I quite often in applications allow the user more than one way to instigate an operation. This makes for a more user friendly experience 😉

Regards

Jack Hamilton

[mikeporter]

Well Jack, having been around for as long as you have you will remember that NI warned us years in advance that the property was going away.

In terms of the basic problem, if LabVIEW doesn't leave memory when everything closes, everything didn't close. The Exit LabVIEW node is a patch, not a fix. The fact that it appears to stop correctly in the development environment is immaterial.

Mike...

PS: who were you working for back then? Did you go to the user's symposium in Austin in '89?

[rolfk]

Actually the Exit LabVIEW function has at least in earlier LabVIEW versions a good change of causing a problem if you have anywhere in your code an event node that registers for the Application Instance Close? filter event. Somehow those two don't play nicely together and will in fact prevent the application from quiting if they are both present.

I had this problem with a background deamon developed in LabVIEW 6.0. Then later (7.x) added the Application->Close? event to detect when the user selected to close LabVIEW as otherwise the deamon would prevent the LabVIEW process from stopping properly. The LabVIEW Exit function didn't seem to cause trouble and even seemed helpful to make LabVIEW terminate quickly back then. When testing in newer LabVIEW versions (~8.5 or so) this combination actually prevented LabVIEW from quiting properly. No cDAQ or whatever involved here.

In respect to cDAQ you can definitely speed up your cDAQ calls if at startup of your applications you do an explicit DAQmx Reserve Network Device.vi call for the device. And it also helps to add a DAQmx Unreserve Network Device.vi just before cleaning up your system (and whenever you reconfigure your app to use a different device) so the device is unlocked and can be used from other processes.