Change IP of development computer?

Does anyone know if it is possible to modify the build script to change the expected IP of the development computer? Right now it only works if the IP is set to 10.xx.yy.6, but we have students developing code on multiple PCs at once and would like to be able to download from each of them without constantly reconfiguring the network.

Thanks for any assistance.

I wasn’t aware that the cRIO cared which IP it’s code was coming from? I know that you can send code from both .5 and .6 (as I’ve programmed successfully from the Classmate as well as another development machine), but as far as I know, the FTP client in Netbeans simply connects to your cRIO at .2?


Just so you are aware, you only need to be 10.x.x.6 if you want to be the Dashboard machine.

You can download and/or run using any 10.x.x.* address. The Dashboard.VI even has a forwarding address to redirect that data to another machine.

We setup our wireless router to give out 10.x.x.50 and above IP addresses, so we can still DHCP setup.

Isn’t the Driver Station supposed to be 10.x.x.5? :ahh:

Yes, the Driver Station is supposed to be 10.x.x.5

10.x.x.1 Wireless Bridge on Robot
10.x.x.2 CRIO
10.x.x.3 Reserved
10.x.x.4 Wireless Router
10.x.x.5 Driver Station/Classmate
10.x.x.6 Development System

Last year a PC instead of the Classmate with an address of 10.x.x.6 could be used as a Dashboard display machine.

Sorry if there was any confusion.

I didn’t think it cared either, but if we download from a PC with any IP other than .6, the build script gets stuck on “Setting up for RUN…” and never reboots the cRIO or displays console output.

This could be related to a bug I have in this code. Where if there is output coming out from your program, that the code to sync with the prompt fails. This will be fixed.

You can deploy from any machine btw, as there is no configuration needed to report what machine the code came from. As for the console, the console gets broadcast to the entire network, so again does not care. The Driver Station MAY be an issue, but I dont think it is. Its more the Dashboard that can only be run from one.

Update: the problem appears to be with DHCP. If I give the development PC any static IP on the subnet, downloading works fine. But if I use DHCP (even with a reservation for the same IP), the download stops at “Setting up for RUN…”

This isn’t too much of a problem (the easy workaround is to just give each PC a static IP), but I do wonder how the use of DHCP should affect anything.

It should not.

NOTE, I JUST ran into this on my new development setup and it turns out I had an issue with the firewall. I was able to talk to the cRIO fine, but cRIO was never able to respond back. What I did was that I ran the NetConsole on another machine. I saw that I kept getting “->”, the shell prompt coming out, this means that the SDK is able to send an empty line to get the prompt back, but never receives it due to some networking issue such as firewall.

Since the dashboard gets its packets from the driver station, the Driver Station application just sends the packets to localhost if configured for Local Dashboard. If configured for Remote Dashboard, the IP address is configurable.

Remember that FIRST is not allowing a dashboard on the same network anymore (new this year). As such, your competition ready setup will not ever have a machine at the 10.xx.yy.6 address. If you want to use a remote dashboard, you will need to use a USB to Ethernet interface and create a completely separate network for your classmate and your dashboard laptop (something like 192.168.1.z).

It’s possible that when you set a static IP, you use one net mask, such as, but when using DHCP, you are assigned a different net mask (such as Since all devices are reachable using either net mask, it’s not clear to me why it would make a difference, but I noticed on another thread that it did make a difference. Compare the net masks using both static and DHCP.

By the way, on my home router, it does not appear to be possible to change the net mask sent out in the DHCPOFFER/DHCPACK to anything less then /24 (

As long as all the devices that you want to access that begin with “10.” will always also always have your team number, “xx.yy.”, then the subnet can be either /8 or /24 and work fine.