We have reflashed our cRIO, and we can ping it through command prompt. In addition , driver station says communications are green, but when we try to push down code, it says waiting for real-time target to respond. Any help?
Check to make sure your project is directing the code to the correct ip address. Are communications up?
So here’s more information.
- All software is updated.
- Our test drivetrain vi works on its own. It can push down and run.
- Communications are green on driver station.
- When we try to push down Robot Main.vi, it gets stuck looking for the cRIO.
I would try closing out LabVIEW and the Driver Station completely and restart it. If that doesn’t work then you may want to check to see if the ‘START Comm’ has been placed. I hope this helps. Do you have any messages in the debugging console in the Driver Station?
I don’t know what you mean by “push down”. Can you be a little more explicit about what you’re trying to do, and how you’re trying to do it?
We have been having this exact problem for years. We try to “temporarily deploy” by running (pushing down) Robot Main, and get various ways in how the deploying dialog is waiting for the cRIO to respond. We’ve had trouble identifying a pattern: it occurs across laptops, and now that over different LabVIEW firmwares from different years. The Driver Station reports communications, and the startup robot code (showing green LEDs). I only recall this occurring over wireless.
Its important to note that this doesn’t occur with both of our cRIO-FRC II’s (both on wireless). The only one running startup code has the problems. I believe reflashing the cRIO was a short-term fix last year; I will try that again as I’m not sure what to try next. Any ideas?
The current SmartDashboard VI has a problem being shutdown when it is deployed. This was listed as a known issue and the workaround is to make sure the dashboard is shutdown before redeploying. An update the fixes the issue should be available next week.
Greg McKaskle
My team had the exact problem and we were able to fix it. Make a connection between the cRio and ur Computer through ethernet then go into your network connections and click in the connection that is between the cRio and the Computer. Right click on Properties and then double click on TCP/IPv4 and assign it a IP of 10.xx.yy.5(xx and yy is team number). Then give it a subnet of 255.0.0.0 and click OK. Then trying pinging our cRio to 10.xx.yy.2,you should get a reply back
P.S. when deploying a code in Labview make sure to “Build” then “Run As Startup”
I see… How would you go about shutting down the SmartDashboard? Simply close the FRC Dashboard on the driver station? However, I don’t think this would explain last year’s problems. I am also not sure that the startup code incorporates Network Tables and the SmartDashboard (its our 2012 robot, reflashed with v47, then the code redeployed).
Our IP address was set properly, I assure you, as well as our radio. Plus, we had communications through the Driver Station. Thanks for the suggestion though.
Typically, I reboot the cRIO from the DriverStation Diagnostics tab. Before it can re-establish communications, I completely exit the DriverStation. Double check your computer’s IP address, wait a minute or two, then try to deploy again. It has always worked for us.
-JP
Team 3039
The bug is only in this year’s version of SmartDashboard. I was mentioning it because the symptom fit.
The most common cause I saw last year for not being able to deploy was that the robot would be disabled and the disabled code was using lots of CPU because it was constantly throwing errors. We changed the framework slightly this year to help avoid that.
I’d encourage you to start from this year’s template and merge in some of last year’s code and see if the deploy issue goes away. Otherwise, let’s debug it – which isn’t the same as guessing at the issue.
And it should not be necessary to reboot in order to be able to deploy.
Greg McKaskle