View Single Post
  #2   Spotlight this post!  
Unread 16-02-2014, 12:40
nuttle nuttle is offline
Registered User
AKA: Allen Nuttle
FRC #4080
Team Role: Mentor
 
Join Date: Mar 2010
Rookie Year: 2009
Location: United States
Posts: 104
nuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud of
Re: Can the CAN bus be overloaded with too many transactions ?

Using a 2CAN instead of the serial bus should help a whole lot.

Really, you want an async interface where nothing gets serialized except on the actual transmission of messages out onto the bus. The CAN protocol handles collisions from multiple devices, so receive works out to just listening and being able to keep up. If some device does not respond for some reason, each exchange should have an independent timeout.

Of course, the S/W stack is not ideal and you have to respect any constraints the Jaguar has in terms of handling overlapping commands.

At any rate, there should be plenty of bandwidth for this to happen, assuming a solid S/W implementation and a low error rate. The first thing I'd look into is the error rate, using the 2CAN web utility and also checking the cabling, particularly the terminators.

Then I'd check to see if your thread scheme is fighting with the serialization that happens to commands. If you issue a bunch of commands and they wind up being serialized, some commands may sit in a queue for a long time before they ever get sent. This could even be creating an unbounded queue that eventually winds up being emptied by timeouts.

Maybe a good way to go would be a thread per Jaguar, to match the serialization. Avoid issuing the same command while waiting for a prior instance of the same command to complete. If you're using synchronous commands (where the function to issue a command does not return until the command exchange has completed or the command has timed out), this will automatically throttle things and you probably don't have to worry about issuing multiple overlapping instances of the same command. Avoid having these threads do anything that can hold up the main thread that is doing the periodic interaction with the driver station.

Watch out for something like a Jaguar resetting -- if you do get errors, you may need some sort of exception handling to reconfigure the affected Jaguar as they lose configuration (except for CAN ID) when they reboot. Sometimes, not everything reboots at once -- Jags may not reboot across a cRIO reboot and also it is possible for them to reboot by themselves if there is something like a brownout or high current fault.

Anyway, the bottom line is the 2CAN works very well in my experience and you should be able to do what you are trying to do. However, it is possible you run into a bug in the Jaguar or the CAN S/W and lose a whole lot of time on this. Given the date, you may not want to mess with this unless you can do so while the robot is in the bag (withholding, a second control system or robot, ...).