LabVIEW Real-Time Idea Exchange

[#1]

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.

[#2]

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.

[#3]

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.

[#4]

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.

[#5]

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

[#6]

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. 

[#7]

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..