04-26-2011 03:58 PM
I have a distributed system. There are Linux machines, Windows machines, and 9104 cRIOs. I want to know if it is possible to reboot the cRIOs from the Linux server. Each target is running an application in LabVIEW 8.5.
The obvious solution would be to write the actual reboot code in the cRIO code and have the Linux server send a message. I don't want to do that for several reasons.
A second solution would be to write the reboot code to run on the windows target to remotely reboot the cRIO. I don't especially want to do this either. (It's kludgy and round about. The Linux server initiates the message to the windows machine, which then send the message to the cRIO.)
Is there a way to reboot a cRIO remotely from a Linux machine?
Solved! Go to Solution.
04-27-2011 07:38 AM
Hi 2verb. Unfortunately I don't have a cRIO setup right now to test, or a Linux machine, but
we use the attached to remotely reboot FieldPoint controllers. Might work for cRIO. Change
the IP to that of the target, run on the Linux machine. Please let me know if it works. LV 8.5.1.
Matt
04-27-2011 10:39 AM
Hey 2verb,
I think the easiest way to perform this would be to write the reboot code on the rio and send a message from the linux machine via tcp, udp, or some other protocol. Would you mind explaining why you don't want to do this?
From the windows machine, you can use the system configuration api to reboot the target. This item is located under measurement i/o>>system configuration>>real-time software configuration>>reboot.vi However, this API is not available on Linux. I will look into whether or not linux has a different method for sending that command.
Thanks,
04-27-2011 11:28 AM
Hi D Smith,
I have a couple of reasons for not wanting to change the target code.
The application uses the same code base for each of the targets we support. In our case Linux, Windows, and cRIO. We have taken pains to not use features in the code that are not available on all three targets. We think the advantages of having one code base outweigh the advantages of using platform specific features.
We have, and can again if necesarry, implement target specific code as plugins.
The other reason is that we are fairly late in our development cycle and this feature may have to wait until the next release if it requries any code changes.