WiFi/Bridge/CRIO Boot Conflict

[JohnFogarty]

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

[plnyyanks]

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.

[Danny Diaz]

This year's new D-Link Bridge boots up slower than the CRIO.
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

[MagiChau]

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.

[JohnFogarty]

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
Ours was set into Bridge mode. SO yeah. STILL A BIG PROBLEM.

[Mark McLeod]

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.

[Danny Diaz]

With some robots there was a similar problem last year, too.
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

[JohnFogarty]

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!

[wireties]

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.

[Danny Diaz]

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

[CoachPoore]

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

[WizenedEE]

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?

[Danny Diaz]

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.
Over the course of my FRC experience, I've learned to assume nothing.

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?
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

[Geek 2.0]

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


Yes, in a manner of speaking; think of a server/client model instead. Think of the Access Point Mode as being 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 the router to get DHCP addresses and talk to other devices on the network. Think of the Bridge mode instead as a wireless ethernet cable (client) - it doesn't provide any wireless services for others to connect to or use, but instead looks for wireless networks to connect to; as well as providing services as a local "switch", it provides a wireless "bridge" from its network (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 full-service network you're connecting to. 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.

[Danny Diaz]

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

[Geek 2.0]

...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!

[JohnFogarty]

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.

[JohnFogarty]

<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

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

[Alan Anderson]

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.

That sounds suspiciously like the DAP is in Auto mode.

[JohnFogarty]

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

[Rick Vogl]

Link to this thread. We are having major problems. http://www.chiefdelphi.com/forums/showthread.php?p=1028041#post1028041

[Mark McLeod]

Continuing the tradition of circular links between these two threads... :)

I recreated one instance where the cRIO and DLink failed to communicate properly and, in addition to the cRIO reset, I was able to simply unplug and replug in the cRIO Ethernet connection to get them talking again.

The symptoms in this particular case were no connectivity between the DLink and cRIO, but the cRIO Ethernet port lights were solid green and yellow, i.e., no packet traffic.

Unplugging and re-connecting to the cRIO port 1 started the yellow traffic light blinking and everything was fine again.

[jwakeman]

We have been using the DAP in AP mode. I also noticed that it takes much longer (gets there eventually though) for the laptop to communicate with the robot when power on the robot is cycled compared to when we just reboot the robot from the Drivers Station.

However, in the case of power cycling the robot I have also noticed that if I disable the WiFi radio on the laptop and reenable it I can get comms much faster. So the sequence is:

1. Power off the robot
2. disable WiFi on the laptop
3. Power on the robot
4. Wait roughly 20 or 30 seconds for the robot and DAP to come up
5. Enable WiFi on the laptop

This get me connected much faster than if I just leave WiFi enabled on the laptop and power cycle the robot. Maybe this doesn't have any value for fixing comm issues during competition but I thought it might provide some clues as to the root cause.

[Lightfoot26]

We have been having a similar problem as well. The robot won't connect when power has been turned on. So we unplug the cRio, turn on robot (which includes the bridge), wait 10-20 seconds, then plug the cRio back in, wait for cRio to boot, and right away it connects like normal. If this is a huge problem I'd like to know how to fix it ASAP! Thanks for the help!!!!!!

[JohnFogarty]

Continuing the tradition of circular links between these two threads... :)

I recreated one instance where the cRIO and DLink failed to communicate properly and, in addition to the cRIO reset, I was able to simply unplug and replug in the cRIO Ethernet connection to get them talking again.

The symptoms in this particular case were no connectivity between the DLink and cRIO, but the cRIO Ethernet port lights were solid green and yellow, i.e., no packet traffic.

Unplugging and re-connecting to the cRIO port 1 started the yellow traffic light blinking and everything was fine again.
The Solid Ethernet Lights are exactly what happens. But still the only way mine will solve the problem is reseting the compactRIO. I've tried unplugging the Ethernet cable several times.

Funny Story. Yesterday all day. Whenever I powered the robot up. They started and connected right the first time. The problem isn't to consistent.