PXI RT configuration

[orko]

Referring to this LAVA discussion I was having issues with the configuration database files that are stored on an RT target in the ni-rt/system directory. Specifically:

CONFIG.MXS

CONFIG.MXC

MXS.MXR

The LAST folder.

I did a bit of Googling and found the below thread mentioning the same

files, and was wondering if anyone had more insight of *what* these

files are used for on an RT target and *why* they would cause a system

to fail startup until they were deleted (this is what fixed my

problem). It seems that during startup the files are recreated if not

there, but I have no idea what they are used for... Can someone shed

some light on this so I can at least sound a little intelligible to my

superiors when they ask?

This post in Google also suggests that NI can use the files to

troubleshoot a RT bootup issue...

Thanks in advance!

Joe "orko" Sines

[LAVA 1.0 Content]

Referring to this LAVA discussion I was having issues with the configuration database files that are stored on an RT target in the ni-rt/system directory. Specifically:

CONFIG.MXS

CONFIG.MXC

MXS.MXR

The LAST folder.

I did a bit of Googling and found the below thread mentioning the same files, and was wondering if anyone had more insight of *what* these files are used for on an RT target and *why* they would cause a system

to fail startup until they were deleted (this is what fixed my problem).

These are configuration files used by the NI-DAQmx driver. They are used by the driver software to identify and communicate with the hardware in your system. A corrupted configuration can cause the behaviour you describe.

[orko]

These are configuration files used by the NI-DAQmx driver. They are used by the driver software to identify and communicate with the hardware in your system. A corrupted configuration can cause the behaviour you describe.

Thank you. That clears it up a little bit.

Now, according to this KB Article the corruption can occur when "the controller was powered off while the database was being written." If this is true, then how would I stop this from happening in the future?

I have a network of 1 host and two PXI controllers tied with an active hub. According to the PXI settings in MAX, the two PXI controllers are set to "Halt all operations when TCP/IP is lost." This would require that the active hub be turned off before the PXI power is disconnected because just turning off the host doesn't kill the connection. This is one workaround, but I'm trying to figure out what the "proper" way of halting the PXI's is. Is halting the targets something that I would have to do programatically from within my application, or is there a more surefire way of never letting this happen again?

Excuse my ignorance here, but I'm learning

[i2dx]

This is one workaround, but I'm trying to figure out what the "proper" way of halting the PXI's is. Is halting the targets something that I would have to do programatically from within my application, or is there a more surefire way of never letting this happen again?

IMHO the proper way of halting a PXI is to programm that in your application. You'll need some kind of "stop" command, e.g. if you are sending commands via TCP/IP to the pxi, it would be a good idea to implement that there. Halting the PXI via the BIOS is a realy brutal method, which gives you no control over the states of your measurement hardware, it's more like an emergency brake ...

[orko]

You'll need some kind of "stop" command

Is there such a thing in LVRT that can be called from within the app?

[LAVA 1.0 Content]

Is there such a thing in LVRT that can be called from within the app?

There are functions in LV to stop individual VIs/application and a function in the LV RT utilities to restart a RT controller (shutdown/retsart), but short of pulling the power plug or controlling a robot to flip the power switch on the front of the PXI chassis you can not shutdown a RT controller to an OFF state programatically.

[GregG]

There are functions in LV to stop individual VIs/application and a function in the LV RT utilities to restart a RT controller (shutdown/retsart), but short of pulling the power plug or controlling a robot to flip the power switch on the front of the PXI chassis you can not shutdown a RT controller to an OFF state programatically.

Strangely, there is only one clean way to fully shut down an RT box: do a software reboot, either from MAX or the LV project, or with the Reboot Controller VI that ships with RT. If you wait until the target gets to the BIOS screen and then turn it off before it boots RT, that is the cleanest way to shutdown, because RT will have given everything running on the target (such as drivers, etc) a chance to cleanly shutdown and cleanup whatever it is doing. The disk cache will be flushed, and things will be as clean as they can get.