I’ve gone through the recent required updates for the FRC Squawk.
However, I now have an unusual problem. When I upload code, the message “Waiting for cRIO to reboot (XXXs)” appears. It never goes away (and the time keeps increasing). As a result, I can no longer view any System.out.println()'s.
It’s interesting, because another programming team member has also updated the FRC Squawk stuff, but he is only getting to “Waiting for cRIO to reboot (10s)” - which is what I used get - and then is able to view the print statements.
Any ideas on why this is happening, and how I could fix this?
One test that you should try is to run the “echo” target on the build.xml of your project in NetBeans. Then reboot the cRIO. If you get output after a while that is the console out of the cRIO then you know you are getting good communication from the cRIO. If not, then you may have the mask issue pointed out.
I’ve got one for you. The other day, after installing every imaginable update, we were getting “Waiting for cRio to reboot” scrolling indefinitely on the console. After some experimentation, I realized that code was loading on the robot and the reboot was occurring, but we just weren’t getting the appropriate console output. So, I checked the IP settings for the network card on my PC and discovered that we were using DHCP. So, I changed it by manually setting the IP to 10.22.72.6 (team 2272) and the console update correctly and I no longer received indefinite waiting to reboot. FYI.
We’re having this same problem when we try to load code onto our cRIO. We have the laptop hooked into the wireless bridge, although we’ve also tried a direct cable into the cRIO. We use java with netbeans, and we’re trying to load a new project onto the cRIO; unfortunately, whenever we select Run Main Project, the output scrolls indefinitely on “Waiting for cRIO to reboot (<x> s)”. After 15 or 16 seconds, the Classmate driver’s station regains comms with the robot, but continues to read “No Robot Code”. When we reset the robot, it still has no code. Does anybody have any other tips on how to solve this problem?
It sounds like you have a laptop and a classmate. The classmate seems to be running correctly (at least the driver station is getting some comms from the robot), but the laptop is only getting part of the job done.
If you got to “Waiting for cRIO to reboot”, then the ftp phase should have completed, so the laptop also has some communication to the cRIO.
The most likely issue is that the netmask of the laptop is not set to 255.0.0.0. The DHCP on the wireless router really wants to change you netmask to 255.255.255.0, but don’t let it!
Another thing to try, as Eric pointed out, is to watch the cRIO output from the command line. So on your laptop, open up a command/terminal window. Do a “cd” to your project’s directory, and type “ant echo”. Then manually reboot the cRIO. You should now start seeing the cRIO’s boot messages etc.
If none of this works, please post the output of your “Run Project” command.
We have Java running on two computers. One with Win7 sees the cRIO boot. The other running WinXP waits forever. Subnet mask is set to 255.0.0.0. We have tried with the Classmate turned off, with the Classmate on and logged off, and with the Classmate on with driver station running.
On the XP laptop we have turned firewalls off. IP is set to 10.2.11.6. Also tried 10.2.11.11. We use a Linksys router between the classmate, laptops, and the robot. The XP laptop may ping the router and the cRIO, however it fails to ping the Classmate. I don’t have the Netbeans and Java versions handy. We loaded from the web, then added the pluggins from the update site.
I’ld really like to get the XP Laptop running as that is the laptop that belongs to the team. Any other ideas to try? Note the XP Laptop is a school laptop so the account type may be an issue? Plus permissions are set by the school district?
We have a similar problem, two laptops with Java installed, one Windows 7, the other Windows XP. Code uploading from XP hangs with message “Waiting for cRIO to reboot”. Run the same code on Windows 7 with expected result.
Is there a problem with Windows XP? Is there a work around? Thanks.