NI Variable Engine:Error:

Question

I have a systemthat has been running fine for over a year. Upon failure the customer returned the processor to us and I took it to a known working unit to see what was going on with it.
First thing, in MAX you cannot see anything under Devices and Interfaces, only thing that shows up is Software.
I connected a monitor and keyboard to the PXI directly and the following errors are displayed (no way of doing a screen shot so I caught as much as I could):
tStatus2 Contents:
              Error code = -2147220721
              Component Name = nidevldp
              File Name = p:\Measurements\Infrastructure\devld\trunk\1.8source\mxsCon
figWrapper.cpp
             Line # = 103
             Address of StatusDesc = 0x0
             Stack Trace = 0x1F6EB46
                                   0x2167730
                                   0x216BFC3
                                   [and a bunch more]
NI Variable Engine: Error: Unable to load the MXS conf plugin: Failed to get MAX Configuration Interface: 0x80004005
NI Variable Engine: C:\ni-rt\system\ni_tagger_plugin_mxs.dll: Failure to load plugin: Unexpected error: Unable to get the interface from plug-in
Nothing has changed on the system in over a year so I know it is not software. One day it just would not start running the machine.
The processor is a (now obsolete) PXI-8184.
Any clues or do I have to replace it, which will be fun because the newer PXI-8183 is a different size.
Thanks for any input.

Answer 1

This is a fairly common problem, in my experience. We use PXI RT controllers for several test stands, and I have found that the MAX Configuration database is quite easily corrupted if the controller is powered down without closing and cleaning up all the DAQmx tasks. I have no idea why an embedded system would be so easily corrupted, but here are the steps I have taken to deal with the (inevitable) corruptions:
I created a "Shutdown RT System" button accessible via a remote front panel from my Host PC that will trigger an interrupt to stop all DAQ tasks and loops on the RT system. I make sure that any time the system needs to be powered down/rebooted, that the operator first presses this button to put the controller into a safe-to-shutdown state.
I used the RTSystemReplication toolset to create a backup image of the RT controller HDD on my host PC. I created a separate compiled executable that I configured in Windows scheduler to create weekly backups of the RT controller. I have another application that redeploys the backup in the event of a database corruption. Note that the RT controller must first be completely formatted before the backup image can be applied.
It is very frustrating that such a procedure is necessary (and it is necessary--even with uninterruptible power supplies, we still have the occasional power outage that outlasts the backup battery, not to mention oops situations where the system is restarted without stopping all DAQmx tasks). But by taking the steps listed above, I have managed to reduce the downtime associated with these gross system failures to roughly one hour per incident, as opposed to the 4+ hours it used to take to fully reinstall all the software components and recalibrate channels as necessary.
If anyone else has any other ideas as to how to avoid/deal with MAX configuration corruptions on PXI RT controllers, please respond with descriptions.