01-14-2014 07:59 AM
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
12-08-2015 09:00 AM
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.
12-05-2017 07:39 AM
I assume you have formatted your cRIOs with the Reliance file system, which is the recommended option to safeguard against file corruption?
12-06-2017 09:13 AM
Where is that recommendation stated?