LabVIEW Real-Time Idea Exchange

About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
Showing results for 
Search instead for 
Did you mean: 

cRIO Remote control of reboot or restart

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.

  • HW Connectivity
3 Comments
Active Participant Caseyw
Active Participant

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

 

 

Active Participant Dan_Mondrik
Active Participant

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.

Member Chris_12345
Member

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.