I'm having problems with a built LV executable remaining in memory (in the process list in Windows task mgr) after exiting. If I re-run the executable I get two copies of the process in task mgr; running it a third time gives me three copies, etc until I manually end the processes. I'm using the "Quit (Exit) Labview" VI, and the LV front panel is closing, just the remnants are left in memory.
Interestingly, running the built .exe under Windows XP Pro does NOT show this behavior, but running it under Vista Home Premium (on the system where it needs to run) does.
I have distilled the code down to what I believe are the basics required to demonstrate this behavior (which I'd love to attach to this post, but can't figure out how to do so). Basically, I'm creating a DAQmx task which is read in a timed loop. I create a DAQmx timing source to act as the timer input to the timed loop. When my user interface event structure detects the "stop" button being pressed, the event handler stops the timed loop, I clear the DAQmx task, and call the "Quit Labview" VI (outside the event structure). Taking a divide-and-conquer approach, I've determined that if I comment out (with diagram disable structure) the"DAQmx Create Timing Source" VI, the program will exit and the process will be removed from memory correctly (of course, it doesn't take any data, either). Also, when I have the Create Timing Source vi enabled, I get a filename collision warning about loadlvalarms.vi during build; if I comment out the Create Timing Source vi, no such build warning occurs. I'm guessing these are related.
If someone can clue me in on how to attach a vi to a post, I'll be glad to post the sample code that demonstrates the problem.
Aha... I don't know why I didn't see that the first time. So, here's the problem demo vi I put together. Again, so far I'm only seeing this behavior under Vista, but I don't have a huge variety of OS configurations to test with. Executable is built with LV 8.6.
Try using a shift register for the purple DAQmx wire in the lower timed loop.
My guess is that when you kill the timed loop from above, it doesn't finish the loop, and the purple DAQmx wire doesn't contain a valid reference for the DAQmx Clear Task to use.
Preferably, you should use a notifier or local variable to stop the lower timed loop. If you do that, both loops should stop gracefully and the DAQmx clear task will run with a valid reference.
No joy changing the tunnel to a shift register. And I had previously tried using a boolean LV wired to the stop of the timed loop without success.
Stop task doesn't make any difference (I had already tried that too). I'm beginning to suspect this is a Labview bug, rather than a programming error on my part, especially since I can only reproduce this under Windows Vista and not XP. I started digging through LV release notes and found this:
I'm wondering if this known memory leak somehow isn't cleaned up by the "Quit Labview" vi under Vista. I can tell you that if I disable the "Quit Labview" vi in the block diagram, and manually close the front panel hitting the "X" in the upper-right corner of the window, all traces are removed from the windows process list in task manager.
I also found this thread:
...which refers to a warning that I'm still seeing in LV 8.6 when building this application. I tried the suggestions in this thread, which do eliminate the build warning, but do NOT fix the left-in-memory problem I'm seeing. I wonder if these are all related.
I can say with fair certainty that the problem is related to the "DAQmx Create Timing Source" vi. If I disable that and set up the timed loop to run with a 1khz internal clock source (and set the loop period to 1000ms for the same update rate), I do not see this memory leak problem. Barring any better solution, I may have to do that. Sounds like NI has some work to do with timed loops under App Builder...
I was able to reproduce this (on an XP machine interestingly?). I was able to get the .exe to be unloaded from memory by removing the DAQmx Create Timing Source.vi and using the built-in timing source. I'm not sure why this happens yet.
Please let me know if this is the source of the issue for you as well.
Justin, I agree that the "DAQmx Create Timing Source" vi appears to be the source of the problem. My current work-around is just what you said, get rid of the DAQmx timing source and let the timed loop free-run with its own internal timing source. It eliminates the leftover program instances, but isn't ideal because the timed loop is no longer synchronized with the data acquisition. For my current application, this isn't that big a deal, but for demanding DAQ applications it's a big issue.
Very interesting thread, I'm currently experiencing the same issue, exe remaining in memory. I've arrived at the same point : issue is due to timing source.
My configuration is the following :
- Windows XP pro sp3 (different behavior for brau ?!)
- LV 8.5.1
I've tried unsuccessfully to use the "clear timing source" function (in TimedLoop palette) after TimeLoop Stop.
I've noticed, also, that process memory decrease when I quit my Exe (from 150 Mo to 60 Mo). On my on test VI (smaller than my real app) Memory decrease from 37 to 31 Mo.
I look forward to hearing your solutions to solve this problem