LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Chart Properties Node - Error: Not Enough Memory to Complete Operation

If you use the chart properties node (ie. actplot) in a 64-bit version of LabVIEW, then there is a possibility that you will encounter the terrible "error: not enough memory to perform operation" message window or, in worst case scenario, you're ram will be overloaded and, in turn, crash Windows. If you get the message window and acknowledge it, then the program will run as expected. This error seems to occur seemingly at random.

 

I used 64-bit LabVIEW 2013 to reproduce this issue. As a workaround, I would suggest using 32-bit LabVIEW.

 

PS - I'm making this post specifically because I was having this issue, but was unable to find any solution online. Hopefully this helps someone who happens to be in the same boat.

0 Kudos
Message 1 of 9
(3,565 Views)

How are you using said property node?  I'm 99.999% certain that switching to a 32bit version of Labview is not going to make an error like that just go away.  It's most likely a programming error (i.e.an un-initialized shift register) that is growing without bounds.  Have you shared code on the forum to see if anyone can help with the problem? 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 2 of 9
(3,556 Views)

You're right. If I put the chart into its own separate VI, then this issue does not happen. However, within the VI that I use to take the measurements needed to populate the chart, this issue is still prominent only within the 64-bit version of LabVIEW. I cannot post the VI due to confidentiality. I will say, though, that is quite large, relies on polling lines, and uses daq real-time measurements as well as vision acquisition. I have definitely traced the issue to the chart's property nodes, as if I surround the node in question with a disable box, then the error is never encountered.

0 Kudos
Message 3 of 9
(3,542 Views)

What value is your Chart History Length set?  Can you share a simplified version of your code that explains what you are doing?

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 4 of 9
(3,498 Views)

@NClark wrote:

... I have definitely traced the issue to the chart's property nodes, as if I surround the node in question with a disable box, then the error is never encountered.


What property ?

 

Curious,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 9
(3,486 Views)

Chart Property Node.PNGAttached is an image of the property node in question. As I said, this works in 32-bit, but not in 64-bit. If I surround this operation in a disable box, then the error is never encountered. I should also add that the chart's history length has been left at the default 1024 points.

0 Kudos
Message 6 of 9
(3,476 Views)

Which of the properties that you show are you disabling?  The one that sets the active plot and plot name, or the one that sets the legend number of rows?

0 Kudos
Message 7 of 9
(3,469 Views)

I'm under the impression that I have to disable all of them. I haven't specifically tested all 2^3 combinations of them, but I know for a fact that if I disable this specific block of code, then the error is never thrown and Windows will never crash due to an overflow in RAM. I've actually monitored the system memory whilst running this program, and for the most part, it will take up only a set amount of RAM. At no time does the memory start to ramp up as would be expected from a memory leak. It seems that the CPU is the most used resource by this VI. However, every once in a while, the processing required to run the VI will drop to virtually zero, and the ram will be immediately overfilled, thus causing Windows to crash.

 

Programmatically speaking, the code functions exactly as expected when run as a 32-bit application, so the issue cannot reside in a careless programming error. I suspect it to be a bug from LabVIEW's end, albeit a very specific and difficult to pin-down bug.

0 Kudos
Message 8 of 9
(3,465 Views)

@NClark wrote:

 

....a very specific and difficult to pin-down bug.


Especially if no one can see the code.  Smiley Wink

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 9 of 9
(3,459 Views)