Not enough memory to complete this operation

[Jeon17]

Hello community,

I'm a graduate student and inherited this huge system from my senior. When I inherited this system, it was installed in Windows XP and LabView 2011. But, I had a continuous error message: "Not enough memory to complete this operation" if I run LabVIEW for a long time (Since I have to maintain a hot temperature of my system, I have to leave LabView running). I thought it was related to the computer specs and I changed the computer: Windows 7 (64 bit), Labview 2012 with RAM 32GB. However, I still have the same error message, LabView responds very slow or 'not responding'. I found the memory usage of LabView was sharply increased at some point from 100,000~K to 1,000,000~3,000,000K (figure below), more than 10 times bigger. But I couldn't catch that point. When I close LabView, re-open and re-run the program, then the starting memory usage goes back to 100,000~K and repeats the same situation. I feel like it's a programming issue, but, I'm new to LabView and have no idea where I start from... I attached the VIs. I use '...Main Program....vi' to run the system. The system controls temperature and flow rate via NI PCI-6221 and NI USB-6001 with a bunch of globals. You can see the Analog I/O and Digital I/O subVIs at the bottom of the block diagram in '...Main Program....vi'

I understand it's quite a huge program to see, but if you give me any advice or comments, I would really appreciate it. I'm struggling with this issue for several months...

Thank you in advance!

[Gregory]

It can be very hard to find memory errors. The fact that it happens sharply is nice, and should make it easier to pinpoint. If there are any areas where large files are read or written, I would start there. A 32-bit application, like LabVIEW, is limited to around 2GB of RAM. You can try running on 64-bit LabVIEW and see how large the memory usage gets.

[Terry_ALE]

Took a quick glance at the code and nothing jumps out at me.  I would run the memory profiler (https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/profiling_vis/) while running your VI.  This may help you find where the memory leak is.

Porting to LabVIEW 64-bit, may get this to work a little longer before it runs out of memory as 64-bit allows you to access more than 2 GB of RAM.

[mcduff]

The program really needs to be rewritten. Due to its physical size, it is almost impossible to debug.

There are lots of Rube-Goldberg constructs, local variables, and other "interesting features".

1. Local variables create data copies. Global variables create data copies. If you have big arrays these can add up fast.
2. The are quite a few delete from array functions, they also introduce data copies. Use Array Subset instead if possible.
3. There are multiple places where you either have an array only to turn it into a cluster that you then unbundle. Just index the array. See below. You also do the converse, put an element into a cluster only to turn into an array, just do it directly. See below.

[Terry_ALE]

---

@mcduff wrote:

The program really needs to be rewritten. Due to its physical size, it is almost impossible to debug.

There are lots of Rube-Goldberg constructs, local variables, and other "interesting features".

1. Local variables create data copies. Global variables create data copies. If you have big arrays these can add up fast.
2. The are quite a few delete from array functions, they also introduce data copies. Use Array Subset instead if possible.
3. There are multiple places where you either have an array only to turn it into a cluster that you then unbundle. Just index the array. See below. You also do the converse, put an element into a cluster only to turn into an array, just do it directly. See below.

---

More generally I agree with this.  In the long run, this may take less time than debugging low quality code.  Plus you would have design documentation that can be used when you hand this off to someone else.

[Jeon17]

Okay, I actually wanted to avoid rewriting the code (because it's huge..), but if it's a better and faster way to solve this problem, I will do it. I will start with suggestions from mcduff. Can I get any other advice about which part I can leave and have to change? Or should I rewrite it from the scratch..?

Thank you for your reply.

[Terry_ALE]

---

@Jeon17 wrote:

Okay, I actually wanted to avoid rewriting the code (because it's huge..), but if it's a better and faster way to solve this problem, I will do it. I will start with suggestions from mcduff. Can I get any other advice about which part I can leave and have to change? Or should I rewrite it from the scratch..?

Thank you for your reply.

---

If you stay with the current code you need to find the memory leaks.  See also https://www.ni.com/en-us/support/documentation/supplemental/16/investigating-memory-growth-issues-in...

[mcduff]

Personally, I like the JKI State Machine. You could have multiple loops linked through User Events, that is what I do.

In addition, as far as code cleanup goes, get rid of single iteration for loops, not sure why they are there.

If you don't want to rewrite code, then you need to play "whack the dots". Go to Tools>Profile>Show Buffer Allocations. (Only choose arrays for now, and try to eliminate the dots)

Here is something to get you started for the PID File Read v8 that should make it easier to debug, improve in the future. (VI attached) (Can be improved more most likely if there was some sample data.)

[Jeon17]

@mcduff: Awesome! I really appreciate it. Also, When I used the 'Show Buffer Allocation' option, I could see a bunch of dots like below:

To eliminate these dots, do I have to replace this structure with another structure without globals? Sorry for the basic question, I'm really new to LabView.

@Terry_ALE: And I did Performance and Memory and I got these results when the memory usage sharply increased:

I'm not sure where is the memory leaks. They look quite small compared to the memory usage on the task manager (it was 1,275,000K). Am I missing something?

[Terry_ALE]

Could be something outside of LabVIEW itself, file system, DAQ, some DLL.  How long does it take for the memory issue to materialize?