LabVIEW Real-Time Idea Exchange

[#1]

In some critical installations, it is absolutely unacceptable for the cRIO to be able to "go to sleep" (as it can do now) and be unreachable via its Ethernet connection, especially when it runs out of real-time in the software.  Currently when a cRIO becomes unresponsive, it requires manual intervention to kill power, push buttons, and/or set DIP switches, etc. to bring it back to life.  Our company is dealing with cRIOs that are located in places that are very difficult, expensive and time consuming to reach.

I strongly recommend that NI add, Ethernet accessible, hardware based reset/restart functions to the cRIO.  These functions should be completely separate from current cRIO software and hardware and should allow remote control of the cRIO power supply, and setting of the dip switches and reset buttons mounted on the cRIO front panel.  NI-MAX should be enhanced to allow a user to remotely control cRIO reboots via these functions.

[#2]

Hello Lewis,

Thank you for posting! FYI - a similar idea to this has been posted here (http://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Failsafe-Remote-Control-Of-cRIO/idi-p/142508...).

I agree that maintaining communication with a networked LabVIEW Real-Time target is important. I do have one question that I would appreciate your thoughts on: why are you unable to use the watchdog timer functionality in your application? Theoretically, if the network communication portion of your application has a problem executing, then by implementing a watchdog "whack" in that loop you would be able to have the controller auto-reboot on failure. Then, upon the next reboot you could send a notification of the problem and perhaps start in a safe state where the target is accessible for updating the onboard application.

Best Regards,

Casey Weltzin

LabVIEW Product Manager

National Instruments

[#3]

I think we are looking at the possibilty of setting "DIP switch" states via software from MAX for some future products. But realize that's not enough, you still need the watchdog. Because if it becomes unreachable over Ethernet, then it's too late to modify the state or reboot it via Ethernet.

[#4]

We are struggling with a related issue. We are using Linux, not Windows, so we can't use the Real-Time Software Configuration palette to do remote reboot operations. I got ahold of some Python script for doing a remote reboot under Linux, but there are some issues with that as well. I wish NI would make available the documentation on the communication protocol for a remote reboot. Instead I have to struggle with this Python script, which nobody in my company (including me) understands, and which is not supported by NI.