Driver Station connects using old laptop but not new one

[iSpotix]

I set up a new development laptop with all of the 2016 software, plugins, etc and also updated our old laptop last weekend. The old one connects like usual to the robot, but the new one does not.

On the new one I can connect to the wifi and view the camera through GRIP and through the internet browser.
The Driver Station is version 16.0.1
I can connect to the D-Link through 10.xx.yy.1 on both laptops
The firewall is completely turned off since it returns "mDNS is slow to respond. Check firewall settings" (paraphrased)
Direct connection from roboRio to the laptop does not show up in the Driver Station software.

I'm not sure what else could be hindering the communication.

[frcguy]

What OS are you using? We were having problems connecting with the 2015 Driver Station on Windows 10 but it worked fine on Windows 8, and perhaps this bug is still present in 2016 version. We got it to work on Windows 10 by opening Driver Station when Windows said "Connecting" during the initial process of connecting to the network.

[Greg McKaskle]

I have some questions to help isolate the issue.

Click to the diagnostics tab and see whether the LEDs indicate that the roboRIO and other components are present. These are ping results, by the way.

Click to the setup tab and verify your team number is correct. Click on the arrow next to the team number and see if a roboRIO is listed there. If not, hold shift and click the arrow and see if a roboRIO shows up with a garbled name.

If the device name for the roboRIO is incorrect, either modify using the http page, or use the imaging tool to set the name.

If none of this works out, plug in a USB cable between DS laptop and roboRIO, also disconnect the ethernet cable from the roboRIO. Use the previous steps to see if you can identify the issue.

Please report back with what was wrong or with the symptoms.

Greg McKaskle

[iSpotix]

The working one runs Windows 8. The new one runs Windows 10.

The only ping that lights up is the Radio? I'm not there anymore but I think it was just called Radio.

When I tried clicking the arrow the Driver Station froze and I could only exit by ending the process in task manager.

The team number is correct.

`The Windows 10 laptop does connect when I plug in the ethernet cable to the roboRio. The ENet ping does not light up however. Just Robot and something else.

[Greg McKaskle]

Be sure that your don't have a firewall blocking the DS communication. Also, be sure to try a USB cable to see if that works better than the enet or wifi.

The click on the arrow immediately calls the mDNS function to discover roboRIOs. It would seem that the mDNS function never returns, which is not expected.

Another possibility is that the mDNS responder service is not running on the Win10 laptop. The easiest solution is to reboot the laptop. To specifically see it, you would open task manager, click on the "All Process" button in the lower left, and see if the service called nimDNSResponder is running.

Greg McKaskle

[Mark McLeod]

Does the troublesome laptop have anything like Norton Internet Security running?
That can freeze the DS.

[darrellt]

We're having problems connecting a Windows 10 laptop to our roboRIO over wifi (OM5P-AN), via the driver station.

We have configured the OM5P-AN according to the WPI instructions. We are using a new Win 10 laptop that has been configured using the latest FRC 2016 software. We have imaged the RoboRIO with the 2016 image.

Here is the data that we have collected.

When connected to the roboRIO via USB (directly) and/or ethernet cable (through the OM5P-AN):
We can access the roboRIO dashboard via its webserver (we had to use Firefox -- IE and Chrome don't support Silverlight) using the URL roboRIO-2635-FRC.local
The dashboard tells us that the IP address for the roboRIO is 10.26.35.18
We can successfully ping 10.26.35.18
We can successfully ping roboRIO-2635-FRC.local
We can successfully connect to the roboRIO via the DS

However, when connected to the roboRIO via wifi (through the OM5P-AN):
We cannot access the roboRIO dashboard using the URL roboRIO-2635-FRC.local, but we can access it via the IP 10.26.35.18.
Interestingly enough, we can also access the dashboard via the URL roboRIO-2635-FRC.lan
We can successfully ping the roboRIO at 10.26.35.18 and roboRIO-2635-FRC.lan
We cannot get a ping at roboRIO-2635-FRC.local
We cannot successfully connect to the roboRIO via the DS

We have tried turning off windows defender and retrying connection via wifi without success.
We have checked and verified that the service nimDNSResponder is running.
The laptop does not have Inventor installed.

We have used the same computer as in the above test and used it to connect and control a robot that is using last year's DAP-1522 wifi router. This all worked just fine -- we had no problems connecting with the drive station through wifi.

This all appears to point to a problem with mDNS on the OM5P-AN when connected via wifi.

Is this strictly a Windows 10 problem? Any ideas for further troubleshooting? Help!

[SuperBK]

Hey Gregg, could you elaborate on what the different is between the indicators on the diagnostics tab for Robot and the indicators in the middle under the battery voltage that say "Communications" and "Robot Code"? I understand that the diagnostic indicators are pings. Does "Communications" means its talking on the TCP and UDP ports to the process on the roboRio that then talks to the robot code?

Earlier today I had the diagnostic indicators on and could ping, but I couldn't get communications or robot code until I turned off my windows firewall. This is on an old Windows7 laptop. I'm not worried about it, just curious.
Brian

[Greg McKaskle]

One thing to try is to use the other port to connect the radio to the roboRIO. There are distinct config differences on the ports -- I don't know much beyond that. And .local versus .lan is, I think, a symptom that the switch ports are separated.

The DS diagnostics tab shows lower level info. The link is not truly like the ethernet link LED, but is as close as I could get in SW and helps indicate that the cable presence. The other LEDs are pings, or rather ICMP API calls that cause a ping and give good result data.

The Communications LED in the central area is higher level and indicates whether the protocol is running. This is the light you really care about, and you go to diagnostics when this is off, to see if ping works or if it is a port issue or a problem with what is running on the RIO. The Robot Code light is signaled by a small part of the protocol and tries to convey whether user code is barking out commands.

By the way, the Comms LED is really a pair of side-by-side ones, one for UDP and one for TCP. UDP is the one required to run the robot, and TCP is more informational, and we sometimes see it fail, so we gave it a subLED for that reason to help get to the bottom of it.

Greg McKaskle

[epylko]

Try statically setting the IP address of your RoboRIO to 10.26.35.2

You might have to flush your computer's DNS cache after you make that change. In a command prompt, do ipconfig /flushdns

[MamaSpoldi]

I think we may have a break through on this problem. We were experiencing the same problem, ie. we could communicate with the new driverstation running on a Windows 7 computer (that we used last year) but were unable to run it successfully on our new Windows 10 laptop. During the process of connecting and disconnecting the setup several times in an effort to try to decipher the issue (following many of the instructions in this thread) we suddenly noticed that it WAS WORKING!!!

In an attempt to figure out what we had changed a new student noted that earlier we had moved the ethernet cable to the port next to the in the radio power cord. When we changed the position of that cable it failed again "radio - BAD"... and moving it back to the first port (next to the power cord) and it reported "radio - GOOD" again.

I had read on another thread here that it was preferred to plug the roboRIO into the plug next to the power cord but I don't recall having it explained why. I hope this will help others trying to figure out this same issue.

[darrellt]

The thread on the NI website has related information:
https://decibel.ni.com/content/message/128619#128619

[MamaSpoldi]

Another update: When we updated to the new Radio Configuration Utility and reprogrammed our radios we were back to step 1... everything is fine on our Windows7 machine, but no connecting on our Windows8 and Windows10 laptops. UGH!

Then we found that there are additional layers of turning off the Firewall in Windows 8 and 10. After setting the Private network settings and Public network Settings as shown in the first picture attached, you need to go the "Advanced Settings" from the Windows Firewall tab (shown in 2nd attached picture) to see and turn off the "Domain Profile" setting for the Firewall. Once all 3 firewall settings were turned off the communications worked on the Windows8 laptop. The Windows 10 laptop required an additional reboot before it worked.

Hope this helps!