Error "Not enough memory to complete this operation" for waveform chart

[eximo]

Paging Altenbach and smercurio

Upon attempting to write to a waveform chart the pop up Error  " Not enough memory to complete this operation" appears.  This is normally a msg for rookies who havn't mastered the concepts of copied data, inplace structures, or memory management.

However, i don't believe this is a standard memory error, please read the simplfied explanation below.

Data (dbl, extended) is collected in a loop, (that has a waveform chart in it) at the end of the program the data leaves the loop and forks to 3 ways.  While the data is being collected (about 128kB per second maximum)  the windows task manager reports about 43mB in use.  

1st output is an array indicator

2nd output is a waveform chart

3rd output has some of the array cropped then is output to a waveform chart.

The moment the program reaches the waveform charts, it increases the memory usage to anywhere from 1.3 to 1.7 GB

When the waveform chart outputs are reached the error occurs.

Reasoning why this seems like a bug:

• Worked with LabVIEW 2009, stopped working on only this computer with upgrade to 2011
• Code works in development environment without any type of massive memory changes  (memory doesn't ever increase beyond 160mB
• even though nothing is ever displayed in the waveform charts, they still pop an error up if you try to clear them
• happens even if only 2 seconds of data are collected (which is for experimental purposes is 500kB of memory)
• If one of the two waveform charts is deleted, the amount of memory used is more than cut in half
• memory usage is not linear.  500kB of memory results in a 40000 fold increase in memory usage.....7MB results in only 25MB more than the first or a   2857 fold increase.
• If the waveform charts wires are cut (but not the forks, so the data is still copied once (see picture))  the problem does not occur  (but i can't see the data 😞   )

I built a simple vi that also demonstrates the memory hogging affect.

watch the memory of the vi in the task manager.  it doesn't matter whether this vi uses 10 loops, or 10000, it still grabs 500MB of memory the moment the waveform chart executes.  

Why would these two waveform charts cause this type of problem??  Are they corrupt? Is it a bug?  

I'm also curious what Altenbach or Smercuiro_fc thinks about this?  

Altenbachs tears cure cancer.....too bad, Altenbach has never cried...

[altenbach]

• You did not include the subVI. What does it do? Please attach it.
• I don't understand why you need a chart at all, because you only graph after the program is complete.
• Why do you need a history size of 1M? Since you have 16 plots, the chart will reserve 16M EXT points, which will be about 160MB for a single copy in memory. 
• Why do you think you need EXT datatype?

[dprylows]

this looks like the same issue that I'm seeing.

https://forums.ni.com/t5/LabVIEW/chart-history-issue-in-Labview-2011/m-p/1706974/highlight/true#M603...

I've found that setting the chart histroy back to 1024 points will allow it to work, but is not a very helpful solution

dp 

[eximo]

Here is the vi, if there is a more efficient less messy way to accomplish the task of taking a 2d array and making a 1d waveform please tell me, other than the chart this vi is the second most time consumptive and memory consumptive task.

The reason for showing the data is to examine the eeg data after the program is complete.  In the vi this is modeled from, machinations are required to display the data simultaneously while the simulated eeg data is collected (this is all for a quality control test system for eeg)  Being able to view the data afterwards is necessary.  

The history size is set, so as to be able to view the entire test.  This is a component that I'm less sure about.  How does the chart history length affect what is displayed?  If i am using 7 channels at 125 hz then at 64bit i should be consuming about 25MB an hour.  1M points I thought would give me about 2.2 hours, but in referencing this other forum post, i appears there may be a bug, or a difference in the history lenght depending on number of channels.

https://forums.ni.com/t5/LabVIEW/Chart-history-explanation/m-p/377503/highlight/false#M189497

I posted a question related to the chart history explanation that I would like you to look at, (image included) where there is data loss when setting the history lenght to one.

I changed from EXT to DBL, there is no reason to have the EXT I only need 9 points of precision so I changed that.  It doesn't affect anything.

In short,  the only thing that affects the problem (and I have solved it in trying to solve your question) is the chart history length.  By decreasing the chart history length the amount of memory consumed by the chart dropped.

So the new question is what does chart history length do?  Is it working as expected?

https://forums.ni.com/t5/LabVIEW/Chart-history-explanation/m-p/377503/highlight/false#M189497  Follow up on this forum for answers and questions

[Drew_H · Accepted solution]

Hi everybody,

I wanted to let you all know that this is a known issue and R&D is currently working on getting this fixed.  It seems like the change to memory usage with chart history length was introduced when we fixed a less-significant issue dealing with transposing arrays.  This led to allocating much more memory for chart history than in the past.  For your reference, the CAR number of this chart history memory issue is 312332.  When it's resolved, it will show up in the bug fixes report or the readme for the respective patch / service pack in which it's implemented.

As noted by members of our community, currently the only workaround is to reduce the chart history length or to continue using LabVIEW 2010 for VIs that contain charts with a significantly larger chart history.  We understand that this is not a very practical solution for some of you, and we're doing our best to get this resolved quickly, but at this time unfortunately I can't provide you with a specific timeframe.

[turboboost17]

I just spent the day chasing the "Not enough memory to complete this operation"  error.

My problem was caused by allowing too many asynchronous writes with the "max asynchronous writes"  for the "TDMS Configure Asynchronous Writes Function".

I had initially increased it from the default and it helped with throughput on smaller files which worked great, but once I was trying to save larger datasets the Asynchronous Writes got log jammed and choked Win7.

There's no way to tell where the error comes from, so hopefully this helps someone else. 

[Sam_Sharp]

Just as an FYI for anyone that find this thread - the CAR mentioned (312332) was fixed in LabVIEW 2011 SP1 (https://www.ni.com/en/support/documentation/bugs/12/archived--labview-2011-sp1-bug-fixes.html)