Thread: Weird Socket Problem with Arduino & cRio
View Single Post
  #2   Spotlight this post!  
Unread 16-04-2012, 02:08
taichichuan's Avatar
taichichuan taichichuan is offline
Software Mentor
AKA: Mike Anderson
FRC #0116 (Epsilon Delta)
Team Role: Mentor
  
Join Date: Feb 2010
Rookie Year: 2010
Location: Herndon, VA
Posts: 328
taichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud of
Send a message via AIM to taichichuan
Re: Weird Socket Problem with Arduino & cRio
Quote:
Originally Posted by codes02 View Post
What symptoms are you observing from the cRIO that causes the appearance that it has "locked up"?

Are you certain that the Arduino is still outputing data over ethernet? (relevance of this depends on the above q. From your description about "not actively reading" on the cRIO, this doesn't seem a likely issue, but do check).
On checking this: connect a ethernet hub between the cRIO and the Arduino. Plug in a computer to this hub as well. Use wireshark to watch packets.

Also: what is the network setup like? For example: are you running the Arduino's ethernet through the Router, or directly?
In the failure mode, the cRio completely drops off of the network. The communications "led" on the driver station goes red, the net console stops responding and the only way out is to reboot the cRio. I can monitor the link with Wireshark and see that the packets are still going out over the wire. The Arduino is hooked up to the Dlink router as is the cRio.

The Arduino is outputting a packet once a second that contains a message ID and the RPM count in a null-terminated packet of about 8 characters in length. This is a directed unicast specifically to the cRio's IP address. I've tried both the UDP port for DS to cRio and a generic port (8888) with similar results. Of course, the Arduino starts outputting packets as soon as it's powered up.

We find that if we create the socket in the robot constructor and then just let it sit (don't enable anything like it would be on the field waiting for the FMS to get going), that the system will fail in typically 2-3 minutes. However, if we have a piece of code that consumes the messages, everything works as it should.

I've been a VxWorks user since 1987 and even helped write sections of the O/S back in the day. I've never seen this sort of behavior in the base O/S. So, It must be something FIRST/wpilib related. If anyone can shed some light on this, I'd be really interested try an understand what's happening. I'm hoping that I can create a similar piece of code on my Linux box to generate packets and send them to the cRio to test to see if it has the same failure mode.

TIA,

Mike