We are struggling with some intermittent CAN-related errors that seem to impact communication to the robot. Upon robot code initialization (either bootup or code deploy), we can see several CAN-related errors (see screenshot below). We have verified continuity on our CAN bus, ensured that there are no overlapping device IDs on configuration even across different device types, and have attempted to increase status frame periods to the maximum 255ms on whichever status frames are available.
My mind went to status frame periods , CAN wiring, and overlapping/incorrect CAN bus IDs, but it sounds like you have already checked all of them. One more thing to check: Is your CAN bus correctly terminated?
I don’t see anything obviously wrong in your code. If you look in your Driver Station event log it might give you some idea where the CPU time is going. (Or you can post your DS log here.)
I recommend trying to fix this with status frame periods (as well as double-checking wiring and IDs) first: you’d be surprised by how much a difference it can make. We’ve been able to lower CAN utilization to ~25%; our CAN bus has the RIO, PDP, PCM, and 10 SparkMaxes.
Since dropping the status frame periods does not persist, it could take some time for these to initially come into effect. This could lead to problems at start-up. Just another consideration. Also, if one or more controllers reset, these settings will be lost, unless the code detects and handles this condition.
FWIW, here’s a robot with solid electrical construction, running C++. It has 14 SPARK MAXen (swerve), roboRIO, REV PH, and REV PDH all on one CAN bus: