Deploying code over radio issue

Technical NI LabVIEW
1

Hi, I am from team 1156

After updating our RoboRIO to the 2020 firmware and re-configuring our radio an issue started happening, we can’t deploy code wirelessly. We use LabVIEW, the error is “Connection failed. The network address might be invalid or the target is not responding”.

We are connecting to the robot with a laptop, when we connect to the driver station, the connection LED shows green and no error is reported. We are able to deploy the code over the USB or Ethernet.

chief1
chief1694×662 79.9 KB

chief2
chief21285×294 52.8 KB

chief3
chief31286×295 66.2 KB

1 Like
2

Was this via Ethernet into the roboRIO directly, or Ethernet into the radio? Is this a radio from last year, or a new one?

3

Reflash the radio and make sure the checkbox for firewall is not checked. If it is, the radio is performing like when attached to the FMS where you cannot deploy due to the port being blocked.

1 Like
4

If you right-click on “Target” in your LV project there should be a field with an IP address in it (apologies I’m not in front of my computer at the moment). If it says 172.22.11.2 then I would expect it to download over tether but not over WiFi. Try changing it to 10.xx.yy.2 and try again over WiFi.

5

It was directly in the roboRIO. The radio is from our last year’s robot.

6

We already reflashed and the firewall box wasn’t checked. How can make it work normally?

7

Thanks, it worked! But I have a question, can I rely on this?

8

If you are testing and deploying code at home, just have that checkbox not marked so that it doesn’t hinder you. You can have the bandwidth limit checked or not based on what you want to see on the DS during testing. To fully test what the field conditions will be, you need to have both checked as those are both enforced by the radio on the real field with FMS. That will make sure that you aren’t trying to use blocked ports or going over the 4mbit bandwidth limit.

9

Awesome! Yes, you should be able to rely on this procedure. Always set that to 172.22.11.2 when tethered (like if you are at a competition) and then use your team number when deploying over the radio at your shop.

10

Ok, thanks!

11

Thanks for the tip!

12

I’d argue to never change it, personally.

The value in changing to 172.22.11.2 exists only in the instance where you’re connected via USB cable and the DNS on your PC isn’t working. In all other instances, leaving it to the team named address will work (USB, Ethernet, Wireless).

By default, this address is set when you create a project by using the team number you include in the wizard. There are very few instances where it makes sense to edit it.

Unless you’re having issues connecting, never change that.

13

Thanks for the advice!

14

Disclaimer: I’m working off memory from last year. If there are changes for 2020, I haven’t read them yet. Please correct me if I get something wrong.

  • The 172.22.11.2 address is only for USB tether NOT for Ethernet tether.
  • 10.TE.AM.2 (where TEAM is your team number) is the IP address of the roboRIO* as assigned by the radio (unless you manually set the IP) and I don’t think it will work over USB tether. I have seen a situation where the roboRIO had an IP address ending in something else than .2 but that shouldn’t happen (if you see it, feel from to @mention me here on CD, I want to investigate this further).
  • roboRIO-TEAM-frc.local is the DNS/mDNS name of the roboRIO and should work no matter if you are using USB tether, Ethernet tether, or WiFi. Again I have seen situations where this doesn’t seem to work (if you see it, again feel free to @mention me).

* The roboRIO’s 10.TE.AM.2 address only gets assigned if a DHCP server is present. If a DHCP server is not present, devices work with Link Local rules assigning themselves a random IP address in the range of 169.254.x.y. This is the case when you connect a laptop directly to the roboRIO with an Ethernet cable and can cause more issues that you just don’t have to deal with simply by using the robot radio.

The robot radio acts as the DHCP server when it is configured for AP mode (home shop use). After you get your radio configured at competition the radio is in Bridge mode but is still the DHCP server for all wired connections, FMS (Field Management System) is supposed to be the DHCP server that assigns the Driver Station an IP address.

Acronyms

  • A DHCP server is what assigns IP addresses (e.g. 10.11.56.2).
  • A DNS server is a computer (in the case of FRC the robot radio) that keeps track of the device names (e.g. roboRIO-1156-frc.local or google.com) and maps them to actual IP addresses (e.g. 10.11.56.2)
  • mDNS is a protocol where each device announces itself on the network to all the other devices and every device keeps track of all the device names and maps them to all the IP addresses.

Here’s official documentation on the FRC networking.

1 Like
15

Yep, the 172.22.11.2 address is only for USB tethering, I should have specified that. Somehow we never have the weight for a network swtich :wink: . I recommended them switching to 10.TE.AM.2 instead of trying roboRIO-TEAM-frc.local given the challenges they were already facing. We tend to have enough trouble with getting the DNS servers to work with NI that we generally bypass them by using 10.TE.AM.2 as a matter of course.

16

If anyone wants to deploy to 10.TE.AM.2 that is fine but don’t expect it to work via USB, direct Ethernet connection to the roboRIO, or wirelessly on the practice field at competition.

The configuration for a wireless practice field is different than everything else. In that case, the field radio is the only DHCP server and assigns addresses in the 10.0.0.z range even for the roboRIO. The roboRIO-TEAM-frc.local address will still work but not the 10.TE.AM.2 address. This also explains why if you have some devices set with a static IP address and others obtaining an IP address automatically (i.e. DHCP) problems can arise on the wireless practice field.

Thinking about it now, I’m not sure there is a DNS server on a wireless practice field, so mDNS will have to be used.

17

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.