Con,
I can recommend a couple of things to look for if you run into this issue again. There are a few scenarios that might cause the symptoms you are seeing, and, if there is really something wrong with the system, we�d like to know about it anyway:
Obvious things to look for:
- You could have a startup application that uses up 100% of the CPU.
- Your target might have been configured for a different sub-net while it was running.
- Your target might have crashed repeatedly, falling back into safe mode (although it should still be visible)
Not so obvious things:
- File corruption, for whatever reason, affecting files that get accessed during start-up of the system. This could cause the system to fall back into an un-configured, null-IP state.
- Reboot due to a crash and then fail to obtain an IP through DHCP, if you are using DHCP.
Next time the target falls into such a state I would suggest the following:
1) Reboot it and try to find it in MAX
2) Disable any start-up applications using the hardware switches on the controller.
3) Since this is a target that does not have a video output, use a Serial null-modem cable and a terminal utility (hyperterminal would do) to check the output console. For this you would need to enable Serial Redirect. The User Manual for the controller tells you what switch to use to enable Serial Redirect:
�PXI-8140RT Series User Manual�I use these settings:
Bps: 9600
Data bits: 8
Parity: none
Stop bits: 1
Flow Control: Hardware
4) The serial redirect output should at least give you an indication of what�s going on, whether it�s failing to get an IP, using the wrong IP, hanging, running out of memory or even if it�s just continually rebooting at startup.
5) Force the target to boot into Safe-Mode. The User Manual mentions how to do this. This should make the target show up again, assuming it is within the same subnet or that it has the valid IP that you are looking for.
6) If the controller comes back to life, try opening an FTP session to it (you could use the FTP client in MAX or Internet Explorer if necessary) and get the following files from the system:
- C:\ni-rt.ini
- C:\persist.pal (if it exists)
- C:\ni-rt\system\rtlog.txt (if it exists)
- C:\ni-rt\system\CONFIG3.MXC (if it exists)
- C:\ni-rt\system\config3.mxs (if it exists)
- C:\ni-rt\system\mxsjar.ini (if it exists)
We might be able to tell what happened from these files. Additionally, it would be good to add more information like the version of LabVIEW Real-Time you are using, boards and drivers, whether you are using a start-up application or not, if using DHCP, and any other details regarding the setup.
7) Worst case scenario would require you to take the Compact flash card out of the controller and get the files (before deleting them) by using a Compact Flash reader on a PC.
Booting the controller into safe-mode should be a no-excuse setting in which you should be able to see the controller from MAX, or ping it, assuming the basic networking conditions are met.
While your application is running you could check for available disk space by using the Volume Info VI (File-IO palette). You could check memory usage by running the Real-Time System Manager (RT 7.1) or using the following utility:
�Programmatically Tracking Memory in LabVIEW Real-Time�Let us know,
Alejandro
LabVIEW Real-Time R&D