CAN bus errors on initialization

Technical CAN
#1

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.

Any insight is appreciated!

You can access our code on GitHub: https://github.com/WHS-FRC-3467/Skip-5.12

image
image555×528 23.7 KB

image
image3024×4032 1.3 MB

What technology became more popular in the FIRST 'scene' this year?
#2

Although utilization hits 100% quite often, you can see the average is closer to 80%. There is significant variability.

image
image3024×4032 1.7 MB

1 Like
#3

Your can utilization is too high.

1 Like
#4

This is what I feared. We are going to continue to try and increase status frame periods and order a CANivore.

#5

Might want to check out your CPU too - it’s entering high territory.

1 Like
#6

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

1 Like
#7

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.

1 Like
#8

Don’t forget control frames too. I recommend setting general to 45ms, and the rest to 255ms.

1 Like
#9

The CAN Bus utilization statistics in the driver station software is noisy. This is a known issue. See the page below for a workaround to find the true bus utilization:

80% utilization is a bit high but should be ok.

#10

Where would one go about setting these things?

#11

When you initialize the motor controller objects, there are methods to set status frames. The exact method would depend on the vendor.

Here is the documentation for REV.

#12

Here is the documentation for CTRE/Phoenix.

#13

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:

image
image927×695 219 KB

1 Like