Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

ni-rt.ini system file corrupt – brownout

Hello,

We have problems with cRIO Ni9075 Labview 2011 sp1, RIO4.1 January 2012.

(The Rt application reads digital inputs, does some FPGA processing and broadcasts the state to the network with UDP. Digital outputs can be set from the network with UDP messages).

Our application works correctly for months and suddenly the cRIO stops working and does not restart anymore (status LED flashes two times per second).

The ni-rt.ini system file is corrupted and when replaced by a good version, then the cRIO restarts correctly (corrupted ni-rt.ini in attachement).

Until now the problem occurred on two different cRIO out of 12 cRIO, and no configurations to the system were done at the time when the problem occurred.

It is possible that power brownouts occur and National Instruments support gives the following answer:

 

"In a brown out power gets low enough to cause the device to turn on and off randomly, but not so low that the device completely shuts off. For some general information, check this page http://en.wikipedia.org/wiki/Brownout_(electricity)
A cRIO in a brownout situation will repeatedly power on and off very quickly. In this time it will being loading files and losing them to volatile memory each time it powers off. The cRIO moves around a lot of files at start up, but not all of them are brought into memory.
Often enough files get brought into memory then corrupted to leave the cRIO in an unrecoverable state.
The solution here is to reformat the RIO and try to ensure brownouts do not happen again. These can be avoided with Uninterruptible Power Supplies, if available to your customer.
"

 

National Instruments sells this device for rugged applications, and this was a reason for us to chose cRIO, then in some situations our power source can be disturbed.

We would expect that after a brownout the cRIO returns to a stable state and restarts normally without file corruption. We are surprised that cRIO is not protected against brownouts.

Rugged applications should start from flash in read-only mode, read-only eprom or read-only CDROM and write changes only to RAM or to non critical sections. If so, then they restart always after brownouts.

 

Does anyone has similar experiences ? Does newer RIO versions or other cRIO devices behave better ?

Thanks in advance for any related information.

Boris

Download All
Message 1 of 4
(6,839 Views)

I whole heartedly agree with you on this Boris. There should be no way to modify this file unless it is intentional. I just spent a weekend plus trying to figure out what was going on with my sbRIO board. It turns out it was a corrupt ni-rt.ini file. I have my board running again but I have no idea what the root cause of the corruption was. I did not experience a brownout as you did but you would think that these board would have a more robust boot procedure if NI expects them to be used in embedded applications.

John O'C
Staff Test Systems Engineer
Woodward, Inc.
Skokie, Illinois, USA

"Life is not a journey to the grave with the intention of arriving safely
in a pretty and well preserved body, but rather to skid in broadside,
thoroughly used up, totally worn out, and loudly proclaiming...
Wow...What a Ride!"
0 Kudos
Message 2 of 4
(4,752 Views)

I assume you have formatted your cRIOs with the Reliance file system, which is the recommended option to safeguard against file corruption?

CLA, CTA, CLED & LabVIEW Champion
0 Kudos
Message 3 of 4
(3,054 Views)

Where is that recommendation stated?

John O'C
Staff Test Systems Engineer
Woodward, Inc.
Skokie, Illinois, USA

"Life is not a journey to the grave with the intention of arriving safely
in a pretty and well preserved body, but rather to skid in broadside,
thoroughly used up, totally worn out, and loudly proclaiming...
Wow...What a Ride!"
0 Kudos
Message 4 of 4
(3,040 Views)