NI Variable Engine:Error:

[teritask]

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.

[Mr.F]

Hi,

I believe you MAX database might have become corrupted. Could you follow THESE steps in order to remove this corruption? Let me know how it goes.

[teritask]

Thanks, I will give it a try and let you know the results. I have to take the controller to another facility to actually try this so it may be a few days, but I will let you know.

Thanks again.

[teritask]

I don't know if this procedure will help me or not since the problem lies in the PXI real-time system and the PC I'm using has been connected to several different PXI systems. I'll take a look and see if it helps.

Thanks.

[teritask]

Thanks for the lead...with a little research I found another knowlegebase document. All I ended up doing was basically reformatting the PXI through MAX and redowloading everything. I couldn't import any of my tasks so I just reentered everything.

Thanks again.

Document:  Using NI-DAQmx 8.6.0f12 with PXI or Desktop Real-Time Systems

[TurboPhil]

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.

[teritask]

Thanks for the info. We are building several more of these machines and I'm going to try and incorporate something to avoid the corruption. It is kind of sad that an embedded system isn't hardy enough to handle shutdowns. Unfortunately I know this is going to occur again on my existing stands and I cannot just download something new since they are scattered about the country and Mexico! At least I can hopefully prevent the problem on new stands.

Thanks again!

[Caseyw]

Hi teritask,

I am sorry to hear about the issue that you have had with your PXI real-time system (which sounds related to file corruption of some kind). I did want to mention that National Instruments began supporting the Reliance file system (from Datalight) for use with certain real-time controllers as of LabVIEW 8.5.1. This does reduce the chance of corruption during power-off (vs using FAT32), as the Reliance file system uses a transactional architecture to preserve old and new values for a piece of data until it is confirmed that the new value is written correctly. Therefore, I would recommend using this file system if you move to a newer controller (and at least LabVIEW 8.5.1 in the future).

Regards,

Casey Weltzin

Product Manager, LabVIEW Real-Time

National Instruments 

[TurboPhil]

Hi Caseyw,

Thanks for the suggestion. I would definitely like to implement a more reliable file structure on all the PXI controllers I can. Unfortunately, we are still running some PXI-8196 controllers which, from what I can tell, are not compatible with the Reliance file system. We did, however, just purchase a few brand-spankin' new PXI-8110 controllers, and I want to make sure that they are all configured with Reliance rather than FAT32. I would like to think that they would have shipped with that setup--and I would like to avoid going through the process of formatting a USB boot disk, formatting, etc. for each one--is there any way to tell what file system is currently in use on a RTOS PXI Target? I didn't see anything obvious in MAX, nor could I find any indication hunting through the BIOS settings on the controller itself.

Thanks.

[TurboPhil]

[EDIT]: Immediately after posting, I tried the "Format Disk" command in MAX and saw that there was the option to select either FAT32 or Reliance for the PXI-8110. So that problem is solved.

We also have some PXI-8106 systems that I understand are Reliance-compatible, but I did not see that option when issuing the "Format" command from MAX--is it safe to assume, then, that those systems do not have the latest BIOS installed, and I will have to go through the process of updating the BIOS and then reformatting in Reliance mode?