This is probably something obvious, but we’re having issues with Driverstation and some new laptops running Windows 11. Specifically, though we can see the RoboRIO over the network from the laptops, the Driverstation doesn’t connect. For example, the COM light on the RoboRIO is green while the corresponding light (and battery indicators, etc.) on the Driverstation stay red. We are seeing this identical behavior over:
Direct USB connection between the laptop and the RoboRIO
Direct Ethernet connection between the laptop and the RoboRIO
Connection via the radio
In each case we can ping the RoboRIO and even load its web server. It’s just the Driverstation that doesn’t work. We’ve killed off all the firewalls we could find.
Everything works fine with our Windows 10 systems, so we know the system overall is functional.
What are we missing? Thanks for any and all insights.
Try temporarily disabling the Windows firewall. It was the only thing that would let the driver station connect to the robot for me. Never had to do it on Windows 10. Whenever connecting the the robot always disable all other forms of network connections on the laptop also and another thing that may have caused issues with me personally in the past is that memory integrity needed to be disabled for some reason in Windows Defender.
You don’t happen to have another laptop on the robot network with a DS connected, right? For the COMM light to be green, some sort of DS connection must be connected.
We’ve tried to be careful about that. It looks to us like the RoboRIO thinks the DS is connected, but somehow the DS can’t see the RoboRIO. And again, everything works fine when we fire up one of the Windows 10 laptops.
For firewalls, just to double check, you’ve disabled the firewall for all 3 profiles, right? The way windows detects which profile to use is a little weird, and sometimes you even have to disable it for all 3 profiles to make it work.
To ensure this, make sure you select “Windows Defender Firewall with Advanced Security”, and ensure all 3 profiles show as off.
Yeesh, NI software. And people claim the FTC control is bad…
Anyways, after a few hours of hacking through tons of NI nonsense (why is it trying to install local low-level hardware drivers for an over-the-network driver station system?), I think I got things working (maybe)
Fair enough, though the dependencies should be treated as “recommended” rather than a hard-dependency. Still installed by default, but skippable if needed.
A problem with using a non-windows drivers station at a event is any problems with it will be your own to solve.
Having said that… Our programers have this weird affection with Apple computers. I am pretty sure they can get the driver station to work through an emulator. I really don’t pay attention on that level as long as the programming works. We still use window computers for the Driver Station. I will wait until the Win11 bugs to be worked out before upgrading. Doesn’t help the OP though.
Makes sense, as Windows is by far the worst OS for software development, so much so that MS created WSL to try to curb people moving to macOS/Linux systems. Apple is a Unix system so it’s much closer to Linux than Windows is.
During testing this offseason, i used my Windows 11 laptop for DS and to push code, I had the exact same issue, how I solved it is that, i ran DS as admin, and I disabled EVERYTHING in Windows defender, and all security software and it worked flawlessly, i have a bash script I will put a link to that will disable everything in windows defender with one button, note: it will also disable your wireless adapters, so you will have to turn the wireless adapters back on
