With the new router/radio, every time we power cycle the bot, we can’t get a green light for robot communications in the DS. We have to restart the computer to get the green light, and then everything works great from that point on.
Some things I’ve read in the forums here suggest that it might be an mDNS issue (?), but I’m not sure how to fix it. Has anyone else had this problem? Any ideas for how to work around this so we don’t have to keep restarting the computer all the time?
Things I haven’t tried: installing/re-installing iTunes so we have the current version of Bonjour, or ipconfig /flushdns. Any other suggestions?
(This could be really annoying/debilitating at the competition, so I’d love to get it figured out.)
We turned off the fire wall. When that didn’t work we plunged the RoboRio into the ethernet port of the Radio that is closest to the power plug, and then pressed the reset button on the RoboRio, but sadly none of those worked. Got any other ideas we could try
Are you letting your laptop go to sleep while you wait on the robot?
Did you let the software disable the Windows fast boot?
Cause if you left fast boot enabled a reboot may be required to get Windows to cooperate again.
At least according to the driver’s station installer that asks to disable this feature.
(5th time I’ve burned the hours to install all this and the installer is quite the pest about it.)
One of our drivers has had this issue constantly, and we can’t figure it out. It seems to be that they are unable to resolve the mDNS address for the bot
Anytime the comms light is red, but i think it should be green, I first switch to the second tab of the DS to look at the ping results. If the robot light is green, then the DS knows the IP of the robot – it can ping the robot based on what you put into the team tab of the third tab.
If the robot ping light is green, that means ping works, but the UDP protocol doesn’t. This is either due to firewall or other port blocking mechanisms or the roboRIO protocol program is no longer running. I will sometimes hit the reset button on the roboRIO to get the program running, though if you were shelled in, you could do other things to check on it and get it going.
If the ping light is not on, click to the third tab to see that the team number is entered correctly. You can click on the arrow next to the field to see if the robot shows up, but it probably would have been selected if it were. You can hold shift and click the arrow to see an unfiltered list. Due to the radio change, you may want to look at the link light on the roboRIO. The small green and yellow LEDs right next to the ethernet port. If not on, unplug and replug the cable, make sure it is seated on both ends. Also swap the port used on the OpenMesh, though the port next to the power should be preferred, it is quick to try both.
It is possible to debug further to see if it is truly an mDNS issue, but personally I haven’t seen that many occurrences this year compared to last.
If you have other observations or symptoms, please post them.
Greg McKaskle
I am experiencing this same kind of issue (and may others are, as well. They just sound diff because of they way the see it. But I think it is this same thing).
I have confirmed that whenever my laptop disconnects from the network the mDNS stops resolving. The network will disconnect any time the robot is powered off/on, for example. When the laptop reconnects to the network I can ping everybody’s IP address, but I cannot get any utility to resolve the name (ping, DS, Internet Explorer, Eclipse)
So far the only way I have fixed this is to reboot the laptop.
I haven’t seen it this year, but one of the bugs that we weren’t able to make much progress on was when the multicast group was not up to date. So the mDNS calls return normally, but return cached results. I was watching the TCP traffic and could tell that the discovery was not going over the wire.
I believe that if you fiddle with the laptop networking enough, it will connect without requiring a reboot. Specifically, when Windows decides it needs to update the multicast group, the mDNS call will suddenly find the device that was connected the whole time. I was never able to find a way to flush or rebuild that info.
If anyone has amazing Windows networking ninja skills and knows how to force this, please chime in.
Other than a full PC reboot, disabling and re-enabling the network adapter consistently resolves the problem whenever I see it. Presumably that forces the multicast group update.
I’ve not been able to resolve the problem just using “ipconfig /flushdns”
Hope this helps!
EDIT: sorry, neglected to also mention that when I’ve seen the problem, other networking apps all work fine…I’m able to ping roborio-XXXX-frc from the command line, able to ssh into it with PuTTY, etc
With a single exception, that’s my experience as well.
The one case where the disable/reenable didn’t work for me was with a particular USB-to-Ethernet adapter. It seemed not to take ANY changes to the device’s properties until it was unplugged and reconnected to a different USB port, which ALWAYS triggered a reinstall of the driver. I think the team eventually gave up on that piece of hardware and used a loaner Classmate to run their Driver Station for the rest of the event.
Thanks everyone for your replies! I haven’t checked this thread for a few days, and it looks like we now we have a BUNCH of things we can try this afternoon at practice.
We will re-post with an update of what works and what doesn’t.
SOLVED: Disabling and enabling the network adapter works consistently on both of our Windows 8.1 HP laptops. Special thanks, rrossbach and Alan Anderson!
Things that didn’t work:
ipconfig /flushdns
restarting “NI mDNS Responder Service” and all dependent services
restarting DS
every possible sequence of the above
THANK YOU ALL for your replies. I’m just super-pumped that I don’t have to restart the computer every time we restart the bot now.
