Not Enough Memory to Complete this Operation - LabVIEW

[osamafarqaleet]

Hi,

This is my first time running in to this issue where after some time (~15 minutes for my VI) a dialog box pops up with the message "Not enough memory to complete this operation" (without any error codes).

The VI is a simple data acquisition VI that monitors and records data. After configuring the channels in two synchronized tasks (one analog and one digital). It reads the data at 50kHz sampling frequency in one loop and puts the data in a queue. The other parallel loop reads the data and has two case structures. First case structure is user controlled that writes data to a .tdms file for it's true case. For it's false case, it decides the group name for next recording. The other case structure automatically updates the graphs (for specific data) once every one second.

I am using cDAQ-9179, NI-9361, NI-9229, (x3) NI-9215, and (x3) NI-9213. The computer is a 64-bit operating system with 32GB physical RAM, and core i7 with 1.9GHz. 

I have written similar VIs before but never had this issue. I was not able to find anything already on the forums to help me with this issue. From my troubleshooting, all I have been able to "troubleshoot" so far is that memory keeps growing in task manager for this process associated with LabVIEW and once it hits ~3GB, the dialog box with not enough memory message appears.

Any help or suggestions will be really appreciated. Thanks!

[Yamaeda]

I'm at a too old LV to look at the code, but 32 bit LV can only address 3GB memory with normal settings. So so far all is normal.

As to why your memory is growing? Either you don't write to disk fast enough to the queue is growing, you somehow build an array or the graph has way too long history. 🙂

I'd start with a disable case around the graph and see if memory still grows.

[osamafarqaleet]

Thanks for the reply Yamaeda.

I have been messing around with different combinations as well. I don't think it's the queue because my queue size stays at virtually 0 during the entire time which would tell me that it's not overflowing. 

I was just looking at the charts and I noticed that the lesser the charts, the longer it takes for the message to display. I will either move to graphs so I don't have a data history in display at all (if I need it, I can just record it in tdms) or reduce history length to a point where it stabilizes.

[GerdW]

Hi Osama,

---

@osamafarqaleet wrote:

I was just looking at the charts and I noticed that the lesser the charts, the longer it takes for the message to display. I will either move to graphs so I don't have a data history in display at all (if I need it, I can just record it in tdms) or reduce history length to a point where it stabilizes.

---

Your charts are set to a history size of 1024: as you use waveforms they will place upto 1024 waveforms into their history buffer!

Your waveforms (AI) are set to 5000 samples per channel: so your charts will hold a buffer of 1024*5000*8 bytes=40MiB each. Shuffling those 40MiB for each new iteration (at 10Hz) can be quite heavy…

Edit: Forgot to include the number of channels into the RAM requirements calculation. Your charts will use much more memory than just 40MiB…

[LucianM]

It cannot be the queue because the size of the queue is set to 10 elements. Is the memory usage increasing if Save Data control is set to false? How about when the second case structure is disabled (put it inside a diagram disable structure or wire the selector to a false constant)?