[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.