LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why do I get a "Fatal Run Time Error: Out of Memory" after an hour while using RT on a PXI 8186?

When I run this code with high speed DAQ+proccessing+control for over an hour in RT on an 8186, I get the above error. There were some arrays being built really quickly, etc. So I replaced these array initializations followed with "replace arrays subset" blocks. Still ,No luck.
I'd really appreciate it if anyone could help me. the code can be posted here as well if reqd.
I'm Running LV RT 7.1, and the target is a PXI-8186.

Also, is there any way of allocating extra virtual memory in RT?
0 Kudos
Message 1 of 8
(4,085 Views)
There is no way of allocating extra virtual memory on an RT Target. RT Targets do not support any virtual memory because virtual memory is hard drive space and the hard drive access is substantially slower and less deterministic in timing than RAM memory access. By adding virtual memory, the operating system would lose its real-time nature.

Based upon your description of events, you probably have some of your arrays that continue to grow until you run out of memory. Depending upon your data needs, you may want to consider a circular buffer so that when you add information to the end of an array (using the replace array subset to a pre-allocated array as you indicated that you are doing), the next set of data you add over-writes the data at the beginning of the array. Depending upon data storage needs, you may want to use queues or some other means of transmitting the data from the acquisition loop to a loop that is responsible for logging or processing the data.

Regards,
Aaron
LabVIEW Champion, CLA, CPI
Message 2 of 8
(4,083 Views)
Let me second everything that Aaron mentioned.

Please post some code that demostrates your trouble and we will take a look.

Gnerally I have to say that RT applications are rather demanding in the area of memory.

I find myself avoiding data types that can vary in size, like strings. These can demand increases in buffer allocations such that the buffer previously allocated are insufficient, are tossed on the heap and another larger block is allocated. Too much of this happening can kill you in RT. Building strings is bad.

Building arrays is just not allowed.

LV2 globals (when properly coded) are useful in keeping memory useage static or diminishing. This dovetails with Aarons circular buffer.

Review all code that is executed repeatedly using

Tools >>> Advanced >>> Show Buffer Allocations

In a nutshell, one or more of thes is killing you.

Post your code so we can make specific suggestions.

Trying to help,

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 3 of 8
(4,073 Views)
VishnuV,

If you can't find any problems with how your arrays are being handled, then there is one other area I can think of that might cause your memory use to increase. If you are using DAQmx for your DAQ, then are you creating tasks inside of loops? If you are, then you need to ensure that you clear the task inside the loop as well (note that it is much more efficient to create/destroy outside of loops and read/write only within the loop). Just one more thing to check....

Hope this helps,
Dan
Message 4 of 8
(4,065 Views)
Thanks for the help guys. Is it possible that I attach the VI to your personal ID, and then you reply on the forum? My guess is that that a sub VI that dabbles innefficiently with a couple of arrays is the problem source.
0 Kudos
Message 5 of 8
(4,038 Views)
I prefer to keep these discussions public so we can all learn from each other. Besides that I can not be counted on to reply (:<)).

A couple of lines below the "submit Post" button, there is a attachment box that you can use to post your code.

Zip it up or save all to a llb, then let us what version of LV you are using. Give us haqint where you suspect the problem may be.

"jpg" or other non-BMP formats are also useful you just want to ask about a part of the code.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 8
(4,035 Views)
Hey Ben!
I totally appreciate your point, but the code is for an OEM and there are confidentiality issues with regards to the code. The learning points could definitely be discussed in public though. I hope its ok, because in this instance I'm constrained by these factors...
Thanks,
Vish.
0 Kudos
Message 7 of 8
(4,031 Views)
OK I understand that. I am in a similar situation.

I am contractually restricted to discussing only public domain ideas.

It seems you have three options;

1) Dumb down the code so it demo's the issue and post that.

2) Contact NI support and work with them.

3) Hire a consultant that will enter into a non-disclosure agreement and let them advise. I have been able to help in these situation with less than a days worth of effort (provided I am just advising and not re-writing).

I suggest option #1 or #2.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 8
(4,028 Views)