2CAN firmware 2.5

[ozrien]

There is a new version of firmware (2.5) for the 2CAN...
http://www.crosstheroadelectronics.com/2CAN.htm

Major Fixes....
-Fixed a potential situation where 2can stops sending udp frames - only happens on higher Ethernet utilizations.
-There is an improvement to lagging Web dash browsing while robot is enabled.
See release notes for details on all fixes.

There is no FRC legal obligation to update from 2.1 to 2.5. Both function with the FRC_2CANPlugin (SVN rev66).

[boomergeek]

Thanks for working so hard to isolate and correct issues and release software on a Sunday morning!

Is there any easy way to consistently stimulate "sending udp frames [at] higher Ethernet utilizations" to demonstrate the problem of stopping udp packets with previous firmware?

Is there a rate of udp frames that are now deemed robust with the new firmware ? How does it compare to the rate currently deemed robust in the previous firmware?

Is more or your testing done on port 1 or port 2 of the CRio?
Is connecting the 2CAN to the DAP-1522 and the DAP-1522 to port 1 of the CRio an allowed competition configuration or should the 2CAN always be connected directly to port 2 of the CRio for competition?

[ozrien]

The only way I could reproduce the udp issue was after creating a simple Wind River project that sent (sendto) udp frames as fast as possible in a tight loop.
Something like this...
count = 0;
time1 = GetTime();
while(1)
{
if(count < 10240)
break;
++count;
sendto(...);
}
time2 = GetTime();
average = (time2 - time1) / 10240;

I wanted to find the absolute fastest update rate per transaction (which is about average = 320us). I found that at 10240 frames, the 2CAN sometimes went into a state where it stopped receiving CAN requests (bug1) and then later would drop a few out of the 10240 (bug2) . I don't expect actual Robot applications to be anywhere near this threshold. In fact in CANJaguar.cpp when a CAN request is sent there is blocking code that waits for the CAN response. In my test I'm just blasting transmits as fast as possible without waiting for a CAN response, so I would say my testing is more aggressive than would is done in an actual Robot application.

Most of my testing is done on port1(cRIO). For teams I generally recommend port2 only to isolate the 2CAN from the communication port used for FMS. The cRIO plugin doesn't care which port the 2can is on (it finds it regardless) but when things go wrong (comm issues on the field) it's very easy to suspect CAN related issues, using port2 reduces the number of factors to rule out when comm problems occur.
However for practice port1 is useful to get to the webdash over Wi-Fi.

Putting 2CAN on DAP -1522(Which is on cRIO port1) is legal.

[Hugh Meyer]

Omar,

Thank you for the update!

-Hugh