After the VI runs for a period of time, Labview displays an error report window and Windows memory shortage warning

[rayhsieh]

The main functions of the VI module  is file reading, data sorting & saving file.

However, this module can run smoothly when running a small number of files, but... When the number of files is large. (approximately 219, of which 7 are over 100MB and 45 are over 1MB)

After running for about 1 minute, the following warnings appear:

• The memory occupied by the Labview program in the task manager has increased to nearly 3000MB.
• The windows system reports the following error window

• Labview pops out the warning window as shown below

• Labview prompts that there is a problem with the data line in the figure below

Then I searched the Internet for some methods as follows, but they still didn’t work after trying

• Add the Request Deallocation vi to each sub-vi created by myself, shown as following picture

• Right click on each sub-vi created by yourself>call setup…>Loading option>select Reload for each call

Sincerely seek expert assistance, thanks~

[santo_13]

"Not Enough Memory" means your code implementation is either bad at memory handling and used up literally all memory available on the 32-bit system (inferring from the 3GB limit) or is complex that you cannot fit within 32-bit system and would need larger RAM and move to 64-bit.

Depending on the complexity of the code, fellow forum members might be able to provide inputs to help you sort out, or if it is large enough, would suggest hiring someone who is quite experienced with LabVIEW to fix the issue or build from scratch.

Please share the whole source code for fellow members to review and make sure it is saved in LV2016 so that you will get a large audience.

[Dobrinov]

In general errors of this sort mean that excessive copying of bigger arrays finds place in memory (using Build Array and the like are the classical culprits).

One important thing to understand when dealing with bigger arrays is that you will get this message way before you actually run out of memory as a total, absolute value (i.e. an array that is 750MB big won't fit anymore even though you can see clearly see that you have 2GB memory still free) because the problem is that arrays need to fit in memory is a single, uninterrupted sequence of bytes. Or in other words, in that example, you need 750MB of continuous free memory, as a single "piece". The more arrays get copied around in memory the more you fragment the memory space until LabVIEW can no longer find a continuous memory space big enough to fit your array after the last time LabVIEW needed to make a copy of it.

One good starting point to start tracing problems in regards to memory usage in your LabVIEW code is:

Tools» Profile» Show Buffer Allocations....

In addition to this I'd heartily advise on reading up on the in-place structure and the available functions:

https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/in_place_element/

[rayhsieh]

Very grateful that you may point out the cause of the problem.

The following diagram is the block diagram of my sub-vi.

I use a lot of build array vi to build a big data array for writing file.

However, I'm not very sure how to change my code with  "in place element structures" because the No.4 array is not a fixed rows array...

Could you give me more clear indication? thanks~

[Dobrinov]

The classical solution to your problem, and the classical way of avoiding that many copies of arrays being made, and also where the in-place structure comes into play, is to initialize an array big enough to contain all the data you will need at the end of your process at the very beginning of your program. This way you create a single array block, that gets copied into memory exactly once, and de-facto "reserve" that memory space for all further operations.

And after you do that instead of combining different array chunks to build it (and causing a new copy of the whole thing in memory every time you do so) you replace the corresponding array chunks in the already created big array instead (i.e. doing those operations "in-place"). This means playing with a lot of array offset indexes, incrementing them, paying attention not to write data past the initial array size in any dimension, but also in case your data will fluctuate in size in time, not to use "old" data from the big array that remained there from old iterations, etc.

Basically go backwards, start with the array the way it should look at the end, initialize it this way from the very beginning, but with default values, then figure out where to replace what portion of it at each step, and make sure you end up with the correct data in it at the end of each iteration. Of course that is much easier said than done, but that is the way.

[altenbach]

---

@rayhsieh wrote:

Then I searched the Internet for some methods as follows, but they still didn’t work after trying

• Add the Request Deallocation vi to each sub-vi created by myself, shown as following picture

• Right click on each sub-vi created by yourself>call setup…>Loading option>select Reload for each call

---

Both are very bad advice. If a subVI is called repetitively with similar data sizes, it is most efficient if it can hold on to the already allocated memory instead of wiping the slate clean, just to need to reallocate the same memory again a nanosecond later. Let LabVIEW manage the memory, it knows better!

Make sure to keep the front panel of that subVI closed (eliminating data copies for the front panel display) and disable debugging. Maybe you could even inline it. Why can't you write the various rows directly to the file inside the subVI instead of creating that huge array just to dump it to a file later in the caller?

As with all typical LabVIEW problems, our advice is limited if we can only look at some truncated pictures. Consider attaching some simplified version of your VIs.

---

@rayhsieh wrote:

However, this module can run smoothly when running a small number of files, but... When the number of files is large. (approximately 219, of which 7 are over 100MB and 45 are over 1MB)

---

Is each file processed individually in succession or does the output depend on all input files?

[rayhsieh]

Thanks for your feedback.😊 

I guess that you means global 2D array with enough size should be created at the beginning and this array will be shared by multiple sub-vi.

However, I'm not very sure how to create a global 2D array.🤔

Whether is the method shown in the following discussion?

Global Variables - LabVIEW 2018 Help - National Instruments (ni.com)

Example on how to set an array as a Global Variable (LV2?). - NI Community

On the other hand, could you show a brief sample code correspond to what you had mentioned in the last post to let me know how to implement, please? 🙏

[altenbach]

---

@rayhsieh wrote:

I guess that you means global 2D array with enough size should be created at the beginning and this array will be shared by multiple sub-vi. 

---

I would start with my advice instead.

(... and please share some code (Vis, not pictures!), e.g. the subVI containing a small dataset in the control as default data)

[rayhsieh]

Hi Altenbach,  Dobrinov & santo_13,

I have uploaded all my source code( all the sub-vis, main vi and sample data log file).

Refer to them, please.

Sincerely thanks for your help.

Ray Hsieh

[GerdW]

Hi Ray,

cleanup the whole code.

• Replace all those "Call by reference" by usual subVIs.
• Remove all those "Request Deallocation" calls.
• Give all your icons a closed border.
• Create a LabVIEW project.
• Include all subVIs in your project, there are missing items!

Like this: