[AndyB871]

We're having exactly the same issue here with team 871. Sometimes code deploys most of the time it does not. We've tried everything we can think of from switching radios, to cRIOs to cables to laptops, various combinations of rebooting, battery changes, cable orientations (away from motors/controllers anything that could possibly put out any kind of EMI). We've done this with shiny new example projects created directly from the FRC labview 2012 splash menu. Always the same results, lots of "waiting for cRIO to respond" and occassionally a success, but rarely. I've brought my controller home to see if i can get any more information from it, but I don't have high hopes. We've already wasted valuable hours trying to just deploy ANYTHING but it always ends up being 5 minutes of coding, 45 minutes of rebooting things and trying to download.

Also, we re-flashed to last years cRIO image and the problem goes away, of course this is unacceptable since it's not compatible with this years FMS and all that jazz...

Any help would be appreciated, we're practically dead in the water.

Edit:
After nosing around with Wireshark for a while I found this: When the robot is operating normally (IE after a reboot without doing a code download) I'm seeing traffic between the robot and PC on TCP port 1735. Every TCP packet from the laptop gets a good ACK from the cRIO.

Now as SOON as i start downloading code, i see some traffic on TCP 3079 between the pc and crio (Wireshark is calling it lv-frontpanel), then it halts, then I start seeing TCP RST's from the robot when the PC pokes it on 1735. Is this symptomatic of something? I noticed that port 1735 stays solidly dead until the robot reboots, at which point it's accepting connections/traffic on this port.

I haven't done the research on what NI LabView does with 1735 or the FRC software does with it yet, but i wanted to get the info up here

I can re-create and provide wireshark logs to the NI gurus if anyone needs it