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.
Link to this thread. We are having major problems. http://www.chiefdelphi.com/forums/showthread.php?p=1028041#post1028041
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.
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:
- Power off the robot
- disable WiFi on the laptop
- Power on the robot
- Wait roughly 20 or 30 seconds for the robot and DAP to come up
- 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.
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!!!