Also posted this on the NI FIRST Community, thought I would give CD a shot too before submitting a ticket to NI.
Ok so here is our problem. We are trying to get our 2010 Robot to play with our nice programming team kids. It was driving fine through the off-season and would pretty much always work when booted up. At our team meeting yesterday we hit a snag trying to download new code onto the cRIO (we hadn’t needed to program it since Nationals). After connecting a (unproperly) updated laptop to the router and trying to deploy code onto the cRIO, we got the cRIO Timeout Error. After a couple reboots we still had this issue although we could ping the cRIO from the laptop. So the next step was imaging the cRIO. We had some issues with our laptop (obviously it wasn’t updated correctly, even though the firmware listed in the imaging tool is v20, the current version) and the wireless would turn on and connect to the school’s internet whenever the LAN connection dropped. So last night I updated the laptop to the most current version of everything (Labview update and DS update) and turned off all the wireless stuff. Came in today and started the firmware update again. Had some issues with it still (yay for Vista) but pushed through and was able to update the firmware successfully. On reboot the Dashboard Laptop shows Communications, No Robot Code and no Voltage (all expected I believe). We can ping the cRIO. There are no crossover’s, and we still get the timeout issue. We can ping wired and wirelessly. I can’t Connect to the cRIO Target through the Project Explorer, can’t Run at Startup and can’t deploy Code, all with the FRC cRIO default Code. I didn’t try the User App switch but don’t think it will matter. Thoughts?
Have you tried downloading the default project from your Classmate instead of the suspect laptop?
Just to isolate the issue to the cRIO or to the other laptop.
Firewall is disabled?
Laptop IP is: 10.22.19.6 or something?
The timeout when you try to Run as Startup sits there forever?
Mark - thanks for the response. I didn’t try using the Classmate because the laptop we are using is the one we used all year and didn’t make any firewall changes or anything like that. I’ll try it anyways just the same, but if it works or not we still have the same problem.
The laptop ip is 10.12.8.6
I have been waiting about a minute normally, I haven’t been waiting for it to actually timeout normally because when we would see this message before it would take at most about 10 seconds to clear.
Are you trying to talk to the Metool Brigade (team 1208) robot, or the Megahurts (team 2219) one?
When you ping the cRIO, what IP address are you telling it to ping? The middle octets of the IP address represent the team number, and they need to match on every network device.
What team number is set on the Driver Station?
What IP address is configured for the LabVIEW deployment target?
One of the reasons I like to use the Classmate as a test case just to isolate the problem is that it’s a common setup for all of us. We know the Classmate connected directly to the cRIO (& running the DS app.) should have the least trouble working together.
It makes it a lot easier for us to suggest where to look next or say “it’s a problem with the PC settings”, or “the cRIO image looks bad”, or “the network is flakey.”
For both the laptop and the Classmate, running the DS application at the same time you’re timing out on the download will let you use the set of ping statuses to tell exactly what the PC can or can’t see when it fails to download.
If the IP’s are a little mixed that should become obvious.
We are using all 1208 equipment. The Driver Station ip address per the rules is 10.12.8.5 The cRIO target per the rules is 10.12.8.2 Which I can ping all the way through. Apparently the LV on our driver station was expired, so I’m renewing it tonight. I did find something interesting though, after you image the cRIO and reboot it (again, assuming all the network configuration is correct, and this follows with a wired/wireless/DS-crossover-cRIO connection) the robot communications light on the DS comes on but the Robot Code doesn’t. I assumed it wouldn’t since there isn’t any code deployed on the cRIO (since it times out) but per the Control System Rules Section 2.6.1 (4) and 2.7.1 (2.f) the Robot Code light should turn on. If anyone can actually confirm this I would appreciate it but I don’t think it should.
Tried at our meeting though with our laptop direct connected (ip address 10.12.8.7) to port 1 of the cRIO via a crossover, again was able to image it but couldn’t connect to it using labview. This error exists in the Control Systems Rules Section 2.8.1 (2nd #2). Will try at next meeting with the actual DS.
Again, just so everyone is on the same page, everything is configured per the Control Systems Section 2. All wired/wireless communications are pingable, all led’s turn on the robot correctly and all on the driver station turn on correctly (with the exception of the above).
Check to make sure that only the wired network communication is enabled. If any other network devices (wireless, FireWire, VPN, etc.) are active, LabVIEW might possibly be getting confused about which direction to send the packets.
I can confirm that after a re-image the Robot Code light will indeed be red, until new code is successfully downloaded.
That image in the Control System Manual is incorrect.
I assume your new LabVIEW default project has the correct IP entered as well (10.12.8.2)?
I’ll see if I can repeat the issue you’re seeing by mucking around a bit.
P.S.
I think we only see the Timeout message if there’s been at least an initial successful handshake between the PC and cRIO.
Otherwise, the usual message is “Target not found.”
I was able to produce the same symptoms using a brand new default project if I mucked up the projects’ IP address, so I imagine that there are probably several network related ways to do it, such as mixed IP addresses or confused NIC’s as Alan suggested.
It can easily be done if code is already running, but that isn’t this case.
Thanks for checking that status light for me Mark. There is only 1 NIC on any laptop we are using, and have always been using a wired connection between the laptop and the router and were switching between the wired and wireless on the robot. The firewall was turned off on all laptops and no vpn software is running.
I agree with this statement Mark, as I can reboot the cRIO from MAX. So from what you’re saying, once you can re-image the cRIO correctly, the only way you can get it to have a timeout issue is by having the wrong ip address set in the default project? That narrows it down a little, obviously we are setting up our project correctly but we are focusing in on the problem. We are going through the RMA process today to get our cRIO repaired.
All - First, I want to say thank you for all you help. This issue has been resolved. I don’t know if it was a dumb mistake or an earlier misconfiguration, but the cRIO target IP address has to be 10.12.8.2 in order to work, not 10.12.08.2 The zero might have been done in the imaging process but either way it’s completly fine now. I am quite surprised by this, I thought the leading zero would be truncated and would be irrevelant but apparently not. I had been adding/removing the zero interchangeably in this post but never removing it through the NI Project Window.
I know of one pathological case involving leading zeros, but I don’t know if that’s part of the problem here. Some library routines treat a number having a leading zero as an octal value, meaning that “08” is an illegal number. I wouldn’t expect such an error to go undetected and unreported, though.
I agree, and this might have been addressed before, but what if we were playing a match against team 128? Our wireless network is trying to target 10.12.8.2 and their wireless network would be trying to target 10.12.8.2 This problem only occurs with teams that have a 4 digit long team number with a 0 in the 3rd digit, so it is a fairly rare issue. Now the question I have that is out of the limits of my knowledge is, since our SSID on our wireless is 1208 and there’s would be 128, does that mean that this isn’t a problem? Or could there be an issue?
Team 128’s IP is 10.1.28.5
Team 1208’s IP is 10.12.8.5
Your SSID’s also are different and wouldn’t conflict. The SSID is a text field. Zero’s count wherever you put them.
But those are at-home settings not competition settings anyway.
You might run with different routers and SSIDs at a local demo, but not on a playing field.
Thanks Mark, I must have been having a brain cramp. The problem would exist with 5 digit long team numbers though, depending on the implementation. I really hope that we have to worry about this someday! (10,000 FRC teams would be awesome…)
With 5-digit long team numbers, you would put the first three digits in the first part, because the maximum number is 255, not 999.
Thus team 19345 would be 10.193.45.2 because 10.19.345.2 is invalid.
