Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does the memory usage of my cRIO rise up until crash?

Solved!
Go to solution
Olla and servus Hello,

I have another porblem with my test setup!
A cRIO 9014 with a 9118 chassis and modules.

The problem manifests itself in ways that the cRIO crashes after some time. Meanwhile, I'm already gone so far that it's the memory usage of the controller! This is the beginning of the RT Proggramms at ~ 40% but rising steadily. Until there are about 98%, and the connection is lost to the target system.

Do you have an idea what the reason may be.

thank you for your answers!

MaJahn
0 Kudos
Message 1 of 16
(6,745 Views)

Hello MaJahn

 

you can use the real-time execution trace toolkit to look into the execution from your cRIO

Monitoring CPU and Memory Usage on Real-Time Embedded Targets

Or this can help.

Why is My Real-Time CPU at 100% When Reading from a DMA FIFO (FPGA)?

 

If the Time Critival Loop on your cRIO runs with 100% of the system power

the other threads like TCP/IP communication will not executed and you lost the connection.

 

What exactly have you programmed?

Which LabVIEW Version do you use?

If you need more informations please let me know.

best regards
Alexander
Message 2 of 16
(6,726 Views)

Hi MaJahn-

 

    Definitely check on what Duffy suggested above and let us know.  I'd also like to help and will need to get some information from you.

 

    Is the application written all in LabVIEW or are there other pieces?  It would really help if you could post the code here (or a small example that demonstrates the problem, if possible).

 

    Does the code use remote procedures?  Stuff like opening an FPGA reference on the cRIO from another network device/computer? or using interactive mode (viewing the cRIO front panel running from the development computer)?  Again, if we could see the code we could simply look at the architecture and help test.

 

    Some additional things that you could check for would be multiple calls of FPGA Open that are not being closed. I've seen this quite a few times.

 

Just let us know.

 

Regards,

 

John Harvey

NI-RIO Product Support Enigneer

 

  

0 Kudos
Message 3 of 16
(6,706 Views)

One other note...

 

You can use the real-time watchdog to reboot your controller if it runs out of memory.

 

Message Edited by jkurtw on 05-07-2010 02:56 PM
0 Kudos
Message 4 of 16
(6,696 Views)
Hello and sorry,

Was now a week on vacation! ^ ^

Thanks for the quick answers!

Let's start at the top.

I have a FPGA programmed data acquisition system. This is in the Later operational data recording crios one, then play them on a DMA FIFO to the RT part of the program. In part, the RT data for one to be sent to an FTP disk, and when needed to clients. These can then view the data.

I Use LabVIEW2009 with SP1.
All parts of the program created in LV.
All references, whether or FPGA RT FIFOs are closed.

The problem really is the controller of the memory is used up. In system manager I can see how the memory usage continues to increase until the Conrtoller just hangs and restarts.
0 Kudos
Message 5 of 16
(6,644 Views)

Double Post

Message Edited by MaJahn on 05-17-2010 07:16 AM
0 Kudos
Message 6 of 16
(6,643 Views)

Hello MaJahn,

 

we have an Reference Example for Streaming Data from FPGA to cRIO to Windows for doing this.

In this example we aquire 24 channels with 50Khz CPU usage is 92%.

 

You can look into the code and compare it with your´s.

The next step is to check the FIFO´s and how many elements will be wirtten into it.

Can you tell me what moduls are used and the sampling rate?

Can you post the code?

best regards
Alexander
0 Kudos
Message 7 of 16
(6,631 Views)

Hi,

Posting of the code is somewhat complicated because it is quite a bit confusing! But I can try it! As an image or the code as code 🙂

Well, this is a cRIO 9014 with a 9118 backplane

Modules are 9401, 9215, 9234 and 9237

I have two FIFOs, both TH, the one is 32 767 elements and the other 8191 elements in size.

Furthermore, I must again say that it is the internal memory (128MB) is the rising, not load the CPU!

THX for your answers

0 Kudos
Message 8 of 16
(6,624 Views)

MaJahn,

 

The easiest way to debug your code would be to use the trace tool to look at which VI is allocating memory.

 

It is pretty easy to use.

 

Do you have it?

  

0 Kudos
Message 9 of 16
(6,589 Views)

Jear got it!

 

but I will test it tomorrow.

 

CU

 

MaJahn

0 Kudos
Message 10 of 16
(6,587 Views)