Not able to do a soft reboot on a remote cRIO

[Pcorcs]

Patrick,

When you indicate that the cRIO does not acknowledge reboot, does the Reboot forward a specific error code? Additionally, is the cRIO no longer present in MAX? When a reboot is invoked from MAX, the the controller disconnect and reinitialize? I presume based on your ping, that these cRIOs are statically assigned IPs, or might they be automatically assigned?

If the MAX command and the Reboot VI are unresponsive, there may be a problem with the software on the cRIO side, and may inevitably result in working directly with the controller. Does cRIOs location happen to be in the direction of home? (joking)

In all seriousness, is it possible to reinstall software on the cRIO in question? This would force a reboot into install mode, or invoke a new error message indicating something about the current system state; ergo, a process is not releasing control of the cRIO, or the operating system cannot be reached. If the Reboot functions are not working in software errors should be generated beyond you custom application. Can a new simplified VI be deployed to the controller from a LabVIEW project? 

I look forward to your responses, hopefully we can work together to gain better clarity to reach a successful resolution.

Thanks, 

[plessnick]

Hello Patrick,

Yes, the IP addresses are statically assigned.

The cRIOs are not acknowledging the reboot probably because our application wasn't started correclty. The application is set to run on start-up.

I had the issue twice (with different cRIOs) direclty from MAX.  I right-clicked the target to do a reboot and I was able to see to reboot "mesage" in MAX but the cRIOs never came back in MAX and I didn't remember seing the line "Initializing..." after the reboot.  I had to go on site and press the reset button to put the system on again.

Yes, it may be possible to reinstall the software on the cRIO and it may be a good time as we are planning our first update to the cRIO application in two years (other than updating to LabVIEW 2009).  The update is minor and I'm not expecting issues related to it that may change the behavior of the system (we are only replacing the LabVIEW Merge Errors VI with a one that is reporting all the errors rather than the first one).

Thanks,

Patrick

Thanks,

[Signal_G]

Patrick

Were you ever able to find a fix for this?  I am experiencing the identical problem with one of my cRIO's.

Thanks

Dave Burris

[Jonathan_S1]

RZTC Dave,

Are you experiencing the exact same symptoms?  If not, what is different?

Which cRIO? RIO driver version? LV RT version?

Thanks,

Jon S

[plessnick]

I never found a solution to this issue.  I have to call someone to manually reboot the cRIO when it happens (not very often).

Patrick

[Signal_G]

We have two identical cRIO's and only one was giving us this problem.  We believe we have found a solution.  Maybe it will give others something to try.  We were having no problems with our program that we could determine.  The reboot was the only issue.  My engineer on site decided that he thought the some of the cable ends weren't seated well in the jack so he replaced the cable with a new, high-quality ethernet cable.  He didn't expect it to fix the reboot problem but it did.  I don't know why but it makes sense that when there's no logical software issue it could be something as simple as a weak cable connection. 

If the problem recurs I'll post on here again.  I just wanted to throw that out there for others.  A new cable is cheap.  It's worth a shot.

[ebnelson]

The Real Time Application Deployment ulitity takes a stored snapshot of one system and loads it.  This may be the ENTIRE system and solve a hosed operating system issue.  I think it does.