I can't comment on CAN from past experience because this is our first year using CAN too. But we have been researching CAN issues in order to avoid hitting them. So we should be able to tell you our experience after this season
. However, we can share some of the things we learned so far. For example, the issue about Jags browning out.
http://chiefdelphi.com/forums/showthread.php?t=101871
Reliability issue due to daisy chaining CAN bus.
http://chiefdelphi.com/forums/showth...light=backbone
There are a few issues we are still researching. One of them is about the bandwidth of CAN bus. It may be more relevant to you since you are using RS-232 instead of Ethernet which is much slower. Depending on how your program is structured, you may be sending multiple CAN messages across the CAN bus in each iteration of your robot loop. My understanding is that each message involves a send and a receive and they are synchronous. In our case, we have seven Jaguars on the robot. In an ideal scenario, our robot main loop will be updating all 7 Jaguars. 5 of our Jaguars have encoders so our ideal scenario is one Set() call for each Jag and one GetPosition() or GetSpeed() call for each Jag that has encoder. So ideally, we will have at least 12 CAN messages sent for each robot loop. I say ideally because I am making an assumption that we do not send more than one Set() or Get() for each Jag in a single loop. But we already found a few places in our code that's not true. So we are in the process of adding perf code to benchmark the number of CAN messages sent per loop and the average time each CAN command uses and how much time the CAN bus operation consumes in a single iteration of the main loop. We are doing this because we occasionally hit the MotorSafety timeout issue which we can't explain except for CAN bus traffic taking too much time in a single robot loop. We are instrumenting a CANJag wrapper class to collect this information. We hope to have some results in a week or so.