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!
Top Authors
Showing results for 
Search instead for 
Did you mean: 

Failsafe Remote Control Of cRIO

Status: New

I'd like to see NI develop a bullet proof way of communicating with a cRIO over TCP/IP to command that it reboot with no startup program, etc. I'm sure it can be done.  The question is whether the cost to do this is warranted.  I've had the cRIO lock up because of a corrupted deployment and it would not respond over the network until someone physically attended to it by setting the "no app" switch.  This cRIO was mounted on a bridge over the Delaware river and was a real hassle to get to, and throw, that switch. 


Suggestion: Dedicate a portion of the processor code to servicing the Ethernet ports that can't be consumed by the startup program.  The user needs to always be able to reboot the cRIO and download new code.


I agree about the command to reboot, but you may want to look at why there is corrupt deployment.  While your waiting, maybe write a separate new App to remotely flip the switch!  All the best and good luck.


There was corrupt deployment, most likely because of a network error.  Once the cRIO program consumes the CPU there is no time left over for the CPU to handle the network interface and the cRIO becomes unavailable to recognize any command.  In particular a command to flip any switch.

Knight of NI

If you just killed power to the cRIO and reapplied power, would that allow it to reboot okay for you?  Perhaps you could have a watchdog circuit that maintains power whenever the cRIO writes to it.  But when it fails to write, because of some lockup, the watchdog timesout, removes power, then reapplies it.

NI Employee (retired)

I would like to inquire more about a watchdog solution; have you tried using the built-in watchdog timer? It seems that your application could be created in such a way that if a watchdog restart occurred it could notify you and then run a minimal set of code (enabling you to access the target via network in the mean time).


Best Regards,


Casey Weltzin

Product Manager, LabVIEW Real-Time

National Instruments

Active Participant

I would also like to know more about how your system got into a corrupted deployment state to see if there is anything we can do in the future to help avoid these situations. 


Active Participant

how about a check-sum approach? -I thought this was pretty much already part of the TCP/IP ?? If it happened "during deployment most likely because of a network error" that sounds pretty bad. Maybe some additional hand-shaking on the RT OS side? Maybe as part of the deployment one of (the last or first) messages could be an MD5 hash code for the files being deployed or something? then if the RT OS detects that the received hash code does not match the final hash code after deployment/copy over network, it would un-set the startup application so it would not run on reboot?

If the software/deployment is bad, then it will not matter how much you re-set or cycle power or how many software or hardware watchdogs you pay to stand guard.. 

CLD LabVIEW 7.1 to 2016