Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Free RTOS heap memory: 0 bytes

Hello I have a PXI8110 with 2GB RAM 1.79 GB free when running my app. I have a circular buffer that crashes my RT app after a variable length of time. The buffer has ~40 dbl waveforms of 10000 points.

The LabVIEW error log contains:

7/15/11 8:16:03.331 PM
c:\builds\penguin\labview\branches\Orion\dev\source\server\RTEmbEditor.cpp(105) : DWarn: Internal error 2 occurred. The top-level VI "
RT_Main.vi" was stopped at unknownx. "" on the block diagram of "
CircBuffer.vi".
The crash log contains:

Memory statistics:
Total system memory:           2100654080 bytes
Free memory:                   1933209408 bytes
Largest free block:            1910964224 bytes
Free RTOS heap memory:         0 bytes
Largest free RTOS heap block:  1910964224 bytes

Obviously heap memory of 0 bytes jumps out as suspect. Suggestions?

 

Richard

0 Kudos
Message 1 of 6
(2,748 Views)
Highlighted

Its possible that you are writing to it faster than you are reading from it and the buffer is filling up until it crashes.

Do you have any unregistered For or While Loops that don't have any wait timers in them? 

Does this only happen with a certain VI or project or does this happen with any code on the PXI?

 

You may want to try something like this https://decibel.ni.com/content/docs/DOC-2303 just to see of it runs correctly Smiley Happy 

 

You can also run one of the examples built into LABVIEW help (Find examples>Toolkit and Module> REAL-TIME) 

 

Do you have and variables running in DSM that are working after crash? Is the Chassis still visible in MAX after crash?

Sam S
Applications Engineer
National Instruments
0 Kudos
Message 2 of 6
(2,732 Views)

I also have a problem with sporatic crashes and finding the heap at 0 bytes.  I'm also collecting waveforms.

Also, why does my memory stats appear as negative numbers?  I'm using 2013 sp1.

Attached is the error log.  So, where's a good resource to learn how to read this thing?


Memory statistics:
Total system memory:           -564678656 bytes
Free memory:                   -952836208 bytes
Largest free block:            -1010716672 bytes
Free RTOS heap memory:         0 bytes
Largest free RTOS heap block:  -1010716672 bytes

*** END SYSTEM EXCEPTION LOG ***

 

 

0 Kudos
Message 3 of 6
(1,512 Views)

Hello,

 

I have a few questions adn suggestions to try and clarify the issue you are experiencing:

 

Try deploying a very small VI to your target. Does this give you the same issue you are experiencing?

 

What kind of problems do you run into after deploying to your target? Do you experience any errors or does the code function as expected?  How frequent are the crashes?

 

Are you using the PXIe 8135 as evident from your Log file?

 

Aaron L.
Applications Engineer
National Instruments
0 Kudos
Message 4 of 6
(1,458 Views)
Small VIs run fine, but we are having a problem keeping one of the network connections alive. We have two tcp connections with one going to a "setup" routine on a pc and the other going to a server where we send the wavforms collected. The first connection seems pretty solid, but with the second sometimes makes connection, but errors with a 66 on the first tcp send. After making a connection that doesn't error the program seems to work fine. Crashing is random with usually hours between incidents... or it may crash a few times in a short period of time. same problem when deployed. Yes, it is an 8135 controller. I attached another log created with create report.
0 Kudos
Message 5 of 6
(1,445 Views)

I know this thread is old but I stumble upon it while searching for my issue. It might help someone to not go down in the rabbit hole.

 

I'm also investigating a crash on my RT system and thought the 

Free RTOS Heap Memory: 0 Bytes

seemed the issue... But then saw this post:

https://forums.ni.com/t5/LabVIEW/0x80000003-Real-Time-exception/m-p/2376468/highlight/true#M738958

 

and this KB: http://digital.ni.com/public.nsf/allkb/9A646C11CBF8A32186257E3B005F1F7B 

 

Which says that it is a legacy output and should not be considered.

 

 

Vincent Carpentier, Ing./Eng.
CLA
Neosoft Technologies
www.neosoft.ca
Message 6 of 6
(856 Views)