Increased Memory Usage over time

[Margrete]

My program is supposed to run continuosly over time, but its memory usage keeps increasing and I think that's why it stops running after a while. I don't have any arrays that grow and I've limited my use of local and global variables. (I've now got one boolean global variable and no local variables.) The Windows task Manager shows that the LabVEIW.exe grows, but when I use Tools->Advanced->Profile VIs and look at the memory usage of the system as I run it, it doesn't show the same behavior. (Here the total memory use can increase and decrease or stay constant...)

I'm attaching my system but it can only be run with an external datalogger.

Hope someone knows what might be wrong!! 🙂

Kindly,
Margrete

[cktears]

I found you used "insert into array" in "getdata.vi". That could be the source of your memory loss. Why don't you leave certain amount of space for the array and use "replace array subset" just like you did mostly in your VIs?

[David Duffey]

Nice VI!

Since your VIs are not increasing in memory, it is not unbounded array problem. (Or if you have one, it is so slow that you don't notice it).

Since the LabVIEW exe is growing, you have unclosed references. Unclosed references could be in the form of ActiveX references, or an array of control references that you pull from a cluster. You'll probably have a good idea of where this might happen.

To track it down, what I like to do is remove pieces of code. Keep removing more and more code until it stops growing. Take a look at that section of code or VI and you'll probably find an unclosed reference.

Hope this info helps!

[Ben]

Hi Margrete,

You have been at this for a while because I recognize your wind-mill FP from an earlier question.

Inside your "get data.VI" you are doing a "webdaq>>>open". This is happening every time your main loop iterates.

LV does not release the resources allocated for these type of operations until after LV exits.

If this is the source of your problem then you should see the memory use drop-off big time when LV is closed up completely.

A slight architectural change is called for I believe.

Do your webdaq>>>open just one time before the main loop starts and do not close is until you are done.

Ben

[Margrete]

Hi Ben 🙂

Thanks! That makes sense 🙂 I've moved the "open" and "close" outside of Get Data an outside the whileloop of the MAIN vi. (So that it'll only be run once every time the system is run.) However, the system kept running for 5hours only, so I guess it wasn't the only problem... (It's been running for 24hours earlier... I never know how long it'll keep going.)
Anyways, thanks for helping 🙂

-Margrete-

[shoneill]

Hi, I don`t know if I`m able to help here but I had a look at the VIs and saw something which (to me) seems wrong.

You use a pre-initialised Array entering your main loop each with 1000 elements. This is OK. You then collect data with a rate of one point per 100 msec for 5 minutes, entering each one to the pre-sized array. The problem is that the 3000 elements measured in 5 minutes don`t really fit in an array with 1000 elements. This means the arrays will be dynamically scaled, despite having used pre-scaled arrays. This should actually be OK after the first run (The arrays stay at 3000 elements) but your VI "delete arrays.vi" creates new arrays with 1000 elements each time, ensuring that the arrays need scaling each time.

Try setting the initial
arrays to 3000 elements. Maybe this will help, I dunno.

Good luck

Shane

[Margrete]

Hi 🙂

I've changed it into "replace" and I actually think it helped 😄 Thanks!!

-Margrete-

[Margrete]

Hi again Ben

I think the stop was a one time thing... It seems to be working just fine now 😄 The program's memory usage varies but it's not always increasing 🙂 Thank you SOOOOOOO much!!!!! 😄 Just wanted you to know that you really helped me!

-Margrete c",)

[Ben]

Cool!

If you keep getting the "stops" you may want to "beef up" your conncetion logic.

SInce it it a network device you may have to re-connect if the network goes goofy.

Ben