50% RT Memory Step Increase

[scott123]

Hi all,

I am using the rtgetmemorysummary.vi located at http://zone.ni.com/devzone/cda/epd/p/id/4952 to monitor the memory usage of a real time application. I use the total and available outputs to calculate the percent usage, and log this to file. I have seen a step change from roughly 11 to 60 percent usage on two different RT systems. After the increase occurs, the system maintains 60% memory consumption. This rare occurrence has happened twice within the course of maybe two months.

National Instruments has verified that this VI is the same as the RT memory monitoring VI in the 8.6 RT package. I am wondering if anyone has seen a sudden step change in memory usage, similar to what I have described. I am not sure if calling this VI is causing the memory to spike or if this is a false report, or if the code is causing a whopping 256Mb allocation.

So, does anybody have any similar experiences and possible solutions?

Crosspost on NI: http://forums.ni.com/ni/board/message?boar...hread.id=410300

[Neville D]

What hardware/LV version?

What is your code doing?

Have you tried with a simple VI?

Have you tried using the execution trace tool kit to see if you can narrow it down?

What happens after the memory spike? Freeze? Crash?

Neville.

[scott123]

I have two PXI systems with PXI 8106 controllers. My code is acquiring data, calculating information based off this data, running PID and open loop control, outputting values to hardware, and transfering data to a host PC via TCP.

I am using LabVIEW 8.5.1 and RT 8.5.1.

I have not tried a simple VI, but this is a good idea. I will allow the getmemoryusage.vi to run all by its self on a test platform to see if i can recreate this situation.

I have not tried the execution trace tool kit.

The system seems to run fine after the increase happens, no freeze or crash. Therefore, this does not seem like a major concern, but if another spike were to occur after it has spiked to 60% then we may not be able to guarentee(sp?) a shutdown to protect the device under test.

[Grampa_of_Oliva_n_Eden]

QUOTE (scott123 @ May 21 2009, 08:20 AM)

I have two PXI systems with PXI 8106 controllers. My code is acquiring data, calculating information based off this data, running PID and open loop control, outputting values to hardware, and transfering data to a host PC via TCP.

I am using LabVIEW 8.5.1 and RT 8.5.1.

I have not tried a simple VI, but this is a good idea. I will allow the getmemoryusage.vi to run all by its self on a test platform to see if i can recreate this situation.

I have not tried the execution trace tool kit.

The system seems to run fine after the increase happens, no freeze or crash. Therefore, this does not seem like a major concern, but if another spike were to occur after it has spiked to 60% then we may not be able to guarentee(sp?) a shutdown to protect the device under test.

I saw something similar once back in LV-RT 6.

In my case I was getting some "out of range errors" so my error cluster which ussually had empty strings (source) now had data blah blah blah, ...

So I ended up changing my code to clear the "source" and just keep the numeric and the boolean.

The other situation was related to strings that where writtein or read form file. WHen the jobs where small the recipe and log files where small. When the job ran to long the buffer that held the string for the small jobs was not large enough so a new larger was allocated and memory took a hit.

In my experience these bumps are often due to stirings or arrays that are built.

Avoid both like the plague while working in RT.

Ben

[BBURT]

Hi,

I have seen a similar issue with version 8.6.1 on the cRIO's and I'm wondering if you might be seeing the same issue.

Is there a icon loaded next to your PC clock called " My DataFinder" ? Is so.. Right click it, then select configure, then select Indexer tab.

Try changing the scheduler to "Never".. see if this helps. Please let me know..

Thanks Bill

[Neville D]

You might try unloading all software components on the RT device that you don't need (for example VISA/DAQmx/Modbus IO Server/System State Publisher/WebServices Runtime/System State Publisher etc. ).

N.