RT crash

[TerraNova]

Hi!

I want to workarownd a kind of a strange RT system crash, wich, as I found, was already discussed earlier on ni.com...

here:
http://digital.ni.com/public.nsf/allkb/1E06DC0A338A52E886256FF2006C10E1
...and here:
http://forums.ni.com/ni/board/message?board.id=4170&message.id=14116&requireLogin=False

The solution is pointed, either:
/////////////////////////////////////////////////////////
The error message indicates that the configuration database may have become corrupt.
This could have happened from two possible scenarios:


One scenario is that the controller was working properly and suddenly gives this error.
It is possible that the controller was powered off while the database was being written.
In this case:
Reboot the controller in "Safe Mode."
FTP to the target, open the folder /NI-RT/SYSTEM and delete the following:
CONFIG.MXS
CONFIG.MXC
MXS.MXR
The LAST folder.
Reboot the target and that should do it. If it doesn't let you delete the file, you can rename it and then delete it.


The second scenario is that the error message appears after installing new software on the controller. In this case:
Either re-format the controller (recommended) and reinstall all software, driver by driver if the error persists.
OR uninstall all software on the target and reinstall it, one by one for each of the drivers.
/////////////////////////////////////////////////////////

I've faced this crash twice on PXI-8186 (LV vers are 8.2.1) with a period about one month.

First time found nothing better than formating RT. When it happened again, I decided to write this post down.

The first scenario has worked problem out, still the question is on.

What precautions should be taken against this file crash?
When does it safe to poweroff and when not.
... And doesn't it possible for NI to make RT to back up such important and vulnerable files ;)?

Regards.
...And thanx in advance!

[Brian_K.]

Hi Sharonoff,

So I have the basic answer to your question.  The MAX database files on RT controllers are written to in various situations, but these are the two main times:
1)  When creating DAQmx tasks or virtual channels through MAX.
2)  When deploying and undeploying shared variables.

Currently we are looking into how to prevent this problem.  Since the two situations do not typically occur in a finished program (normally tasks and deploying occur in development) you should not expect to see the problem in a finished product.  If you have finished your application, and are concerned about corruption, I would suggest creating an image of your controller using the System Replication VIs.  The example program is typically good enough to do what you need.  This can save you countless hours, and is a great way to ensure that someone later down the road doesn't need to relearn you program to get the system back up and running.

[TerraNova]

Thank you very much, Brian!