cRIO Bootup and Networking question

[Marc L]

My team has experienced some hiccups with our wireless connection to the cRIO and have a few questions about how the cRIO boots up.

(There is a thread on Chief Delphi that discusses this, my username there is Ziaholic ... http://www.chiefdelphi.com/forums/showthread.php?p=903772#post903772 )

(I'm not the OP in that thread, but have contributed a few posts about this topic)

A little background ... we find that when we power up the robot from scratch, we do not get an ethernet link to the driverstation.  We have observed that the cRIO ethernet apparently boots up faster than the wireless bridge. We have a workaround where we use a paperclip to reset the cRIO after the bridge boots up.  Using the workaround, we get a solid connection.

My question for NI is related to the timing of the cRIO bootup process.  I'd like a description of the bootup timeline, and what might occur if the wireless bridge has not booted up when the cRIO checks its ethernet port(s).  Is there a re-try timer?  If so, how many seconds?

Thanks.

[OliviaC]

Hi MarcL,

The cRIO, wireless bridge, router and the Classmate should always be continuously trying to communicate with one another. If you disconnect anything and then reconnect them, they should all find one another again fairly quickly. How long are you usually waiting for communication between the Driver Station and the wireless bridge?

[DAQjr]

We're looking into this issue.  We've been able to reproduce it but have not yet found the cause.

-Joe

[Marc L]

O54E wrote:

Hi MarcL,

The cRIO, wireless bridge, router and the Classmate should always be continuously trying to communicate with one another. If you disconnect anything and then reconnect them, they should all find one another again fairly quickly. How long are you usually waiting for communication between the Driver Station and the wireless bridge?

At yesterday's team session, we only power cycled the 'bot a couple times ... for the most part we were on and connected the entire time.

Not surprisingly, now that I've posted this question, we didn't have any connection issues yesterday.  When we first powered up I went reaching for our paper clip (a.k.a. reset tool) but before I could even walk back over to the cRIO, the connection light (a.k.a. green indicator on the classmate driverstation software) came on and stayed on the entire time.  I didn't time it, but it was probably no more than 30 seconds from ON to CONNECTED.

Rather than troubleshoot this issue by powering ON and OFF multiple times, we chose to work on developing SW.  We must've deployed a half-dozen different robot project versions without a single hiccup.

We will keep notes at our next few sessions to see if occurs again, and we'll time how long we have to wait between power-up and valid/green connection status.

Thanks for your attention with this.  I hate non-reproduceable errors.  I don't know if I should be happy that we didn't experience it yesterday, or sorry that we can't offer up any new troubleshooting data.  Thanks again.

[DAQjr]

We've identified what's going on with the wireless bridge (gaming adapter). It seems that it maintains an arp table to direct traffic to its wired interface. It makes sense that it would want to filter what traffic it puts onto its wired interface to limit the wasted bandwidth from traffic destined for devices that are not on that segment of the network. However it only snoops arp traffic, so if the classmate has already cached the MAC address of the cRIO (i.e. you haven't stopped the driver station app on the classmate) then there is no arp request for the wireless bridge to snoop.

The reason it works sometimes is that there is a race condition between the cRIO network interface coming up and the bridge connecting. When the cRIO boots and brings up the network interface, it sends a gratuitous arp reply to announce itself. If the bridge is already booted, this gratuitous arp reply will cause the bridge adds the cRIO to its list-of-devices-connected-to-its-wired-interface and begin to put traffic destined for the cRIO on its wired interface (where the cRIO is) and therefore will work. If the bridge is not booted when this gratuitous arp reply is sent, then when it is booted, there is no arp traffic for the bridge to snoop and therefore won't forward traffic destined for the cRIO to its wired interface, making the cRIO unreachable. This very fact is why a warm boot of the cRIO fixes the problem (since there will be a new gratuitous arp reply from the cRIO).The other way to address the issue is to force the classmate to resend its arp request for the cRIO so that the bridge can snoop it. After this happens, the bridge knows about the cRIO on its wired interface and starts forwarding traffic and everything works. This can be done by running "arp -d" on the classmate to clear the arp cache.There will be an update to the driver station application that will clear the arp cache if it has trouble connecting to the cRIO.Cheers!
-Joe