WiFi/Bridge/CRIO Boot Conflict

Sooooo. ever had one of those moments at competitions where you turn your robot on and it doesn’t connect to the field control system?
I know why.
This year’s new D-Link Bridge boots up slower than the CRIO. The CRIO boots completely and then the Ethernet port is already configured. When the bridge then tries to connect to the CRIO and the wifi. It Can’t. So I left the main robot power on and unplugged the power from the CRIO while the Bridge was still on. And the Bridge connected to the CRIO and WI-FI almost immediately.
This is a real problem. Has anyone else experienced it and is there a way to fix it without just having a hard switch wired to the CRIO to make sure the bridge boots first.
THANKS!
John Fogarty

That is an interesting theory. Our robot never seemed to have that problem; our only FMS issue was that we had an outdated image on our RIO. Anyway, our dlink’s slow boot time never seemed to effect connectivity.

Ewwww, that would be a problem. Is that because the DAP-1522 is set to “Auto” mode instead of “AP”? “Auto” mode waits 30 seconds before it “boots” looking for a DHCP server (so it can swap itself to bridged if it can find one). That could be the source of the discrepancy here.

-Danny

Our 2011 robot works fine with the bridge booting up and communicating every time. Nice to know not to use auto-mode due to that delay timer.

Ours was set into Bridge mode. SO yeah. STILL A BIG PROBLEM.

With some robots there was a similar problem last year, too.
You can use the reset button on the cRIO itself to cycle it, rather than pulling power.

Ugh. The underlying “problem” is that the cRIO only attempts to acquire a DHCP address at boot-up; if it doesn’t find a DHCP server, it negotiates/acquires a link-local address. There is a way to prevent this from happening - there’s a token you can add to an INI file on the cRIO that will tell the cRIO that if it cannot find a DHCP server it will reboot itself and try again up to 3 times.

FTP to the target, and find the following file in the root directory: ni-rt.ini

In the file, you’ll find a section called, “[TCP_Stack_Config]”. Under that section, add the following token:

*[TCP_Stack_Config]
Halt_On_Error=TRUE
*

Yup, I know, it’s poorly named, but for legacy reasons the name has lived on way past its deserved lifespan. Anyway, this will cause the cRIO to reboot up to 3 times looking for successful communication with a DHCP server. After 3 times, that’s it, you must reboot the cRIO yourself (via power or reset button). Give it a shot?

-Danny

I’ll make sure that this problem is well known at the palmetto regional this year. If the reset button solves the problem than we may save alot of time at the competitions.
Thanks!

This does not make sense to mew. The cRIO has no need of a DHCP server. The IP address is statically defined. There must be something else going on.

<shakes cobwebs out of brain> Yeah, you’re right. I completely stoned on the fact that it’s a static IP address - even if the DAP comes up last, there should absolutely be no issue unless the software running on the cRIO gets into a funky state without a network.

If you unplug the network connection from the cRIO, then reboot the cRIO, then after a couple minutes plug in the ethernet connection, can you talk to the cRIO? You should be able to …

-Danny

We’ve been using the new robot radio in bridge mode all build season so that we have been using the same networking configuration (on both the robot and driver station) that we expect to compete with. The issue we have seen is that the new radio takes about 40s to bridge to another network after you apply power. We’ve been rebooting the cRIO from the driver station to avoid power cycling the robot and hence the radio. That’s clearly not an option on the field, but it saves a lot of time in on the practice field.

We saw significant delays which I believe were bridging related at the week 0 event in Nashua, NH on Saturday as well.

Noel

We’ve never had a problem this year, but then again we’ve been using AP mode.

I’m sure that the field personnel are aware of this problem, if it exists, and will know what to check/reboot if your robot doesn’t connect.

For a slightly off-topic question, am I right in saying that bridge mode connects to one wireless source and Access Point mode connects to many wireless sources? But the router will still communicate with a second wired source in bridge mode, like the camera, correct?

Over the course of my FRC experience, I’ve learned to assume nothing.

I prefer to think of a client/server model instead. Look at the DAP-1522 as two devices; a wired switch connected to a wireless device. In the Access Point Mode, the wireless device is nothing more than just a glorified wireless router (server) - it acts as a DHCP server, provides a wireless access point (broadcasts an SSID that clients can connect to) and clients connect through it to get DHCP addresses and talk to other devices on the network. In Bridge Mode the wireless device is nothing more than a wireless ethernet cable (client) - it provides a wireless “bridge” from its switch component (which your cRIO and camera are sitting on) to a single wireless network (the field network) like a “wireless ethernet cable” from the DAP-1522 to the field network. In competition, your classmate will hard-wire into the field network, and the “bridge” mode of the DAP-1522 will connect your robot’s local network to the field network. This way the field software controls everything going into and out of your robot. This is a crude description, but accurate in my opinion.

-Danny

As far as I know, the DAP-1522 has no DHCP. It was very annoying for us because the computers we have access to do not allow us to set a static IP, making programming a nightmare. Eventually we were allowed static IPs.

Well, okay, it CAN provide DHCP if enabled (we just don’t enable it in competition).

-Danny

…it can? I didn’t see that functionality, and next time I get hands-on with it, I’ll go looking… I really want that option!

I was told last night in AP mode the Bridge can act as a repeater.

And to clarify I tried only unplugging the Ethernet cable from the cRIO when I plugged it back in all I got was the port light on the bridge to come back on. The bridge wasn’t configuring the connection. When I rebooted the cRIO however we noticed the Port 1 light on the bridge flash a bit. and then the bridge connected to the WiFi within seconds. The real issue is the bridge looks like it’s connected to the cRIO when looking at the lights, but then it never finds the WiFi. When I rebooted the cRIO and the IP was established between the Bridge and cRIO then the bridge immediately connected to the WiFi.

Just rebooting the cRIO with the bridge still on fixes the problem in seconds.

That sounds suspiciously like the DAP is in Auto mode.

I’ve just checked again. the bridge is definitely in Bridge mode.