Memory leak... Help!

[Ralph@NES]

I've been getting thrashed by this application for a couple of weeks now.  Tried different computers, reformats, changing the reentrancy of subvi's, all to no avail.

I had been running this on an XP dell with 1gb RAM and it ran out of memory rather quickly (10 hours or so).  I reconfigured the system with a fresh install and 4gb RAM and it's been running 24h now, but when initially started there was around 29mb memory usage, and now it's up to 1.3gb.  Obviously something not being done right here.  I've got no experience with tracing things like that, so any help is appreciated.

The only difference in this application from other applications I've run successfully for literally months on end is the acquisition of load cell data which I'm attempting to normalize via averaging in basicaveragesub.vi.

I've zipped the entire project and attached.  It's pretty small and simple.  I'm sure it's probably something basic that I'm missing since I'm a self taught hack.  Thanks in advance.

[Ralph@NES]

Please try to disregard the myriad Error indicators - Those were a last ditch attempt at capturing any internal error that might have been causing earlier issues.  They'll all be gone in the final iteration.

As a result of troubleshooting, some of the wiring got a bit uglier.

[xander.cesari]

Any particular reason you're using DAQ Assistants? I was under the impression that the Assistants have poor performance compared to using a string of DAQmx Task based VIs. I can't run this VI but it looks like it would be a prime candidate for a Producer-Consumer architecture and using a queue should at least give you more options for memory management.

Also LabVIEW has some built in performance monitoring tools that could help track down your issue:

http://www.ni.com/white-paper/3576/en/

[Ralph@NES]

No particular reason for the use of DAQ assistants, other than simplicity.  Very little development money and time is given to these projects.  That in itself shouldn't be an issue, I've had code with 20+ DA's in it that didn't memory leak this quickly and to the level of severity which this code is.

I'll look at the white paper, thanks.

Any other input welcome.

[crossrulz]

That Dynamic Data Type is not exactly known for being a good for handling memory.  I would eliminate every hint of a DDT, especially the DAQ Assistants.  From what I see, your code should be just find after that.

[Ralph@NES]

I'm running that profile capture utility now, hopefully a couple of hours of data will suffice.

[Ralph@NES]

Crossrulz, thanks for that input. Not sure if I'm in a position to do that with the time frame, but I'll see what I can do.

I just went out and stopped the program.  The memory continued to hold at almost 1.4gb even after I stopped it.  I went in and made a minor diagram edit and didn't even save, then looked at the output text file and came back and the memory was back to 28k.  What triggers the release of the memory?

[xander.cesari]

Ralph,

You can try manually deallocating SubVI memory after you run them (I see you have a DA in a SubVI, maybe that's hogging memory). Maybe if you work your way through a handful of SubVIs you'll find the one that's leaking.

http://zone.ni.com/reference/en-XX/help/371361H-01/glang/request_dealloc/

[Ralph@NES]

Hello,

I removed any of the DA's from Subvi and made them part of the main loop.

Today, the total memory usage from Labview was around 800mb rather than the 1.3gb.  It was still rather high.

I tried a few things with task manager popped up - one thing that surprised me was that minimizing the Labview panel dropped the memory usage instantly from 800mb to 13mb!  Minimized, it quickly rebounded to 28mb and settled there for the moment.

It seems like this is tied to the display, or that is a factor.  Any ideas here?

[Ralph@NES]

Xander, I didn't get to that part yet.  I'll look into that, thank you.