Periodic Status 5 timeouts on disabled-frame SPARK MAXES

We use Rev’s absolute encoder mode heavily on our bot (4 swerve steer neos, arm pivot neo, wrist neo) with 8 other neos on our bot. Because we rely on them for direct feedback, we turned status 5 to 20 ms on the ones with encoders and 65535 on the rest. Status 6 is the same way, but only enabled for pivot and wrist. We disabled frames 3 and 4 on everything because we use no alternate encoders. Our CAN util is about 50% avg.

This seems to work okay except for two problems.

  1. Nearly every boot up, one or more of the absolute encoder controllers will not get the status 5 frame period set. It’s not a particular controller every time, but it’s usually one of the swerve steers. This gives us consistent timeout errors and issues with PID and odometry.
  2. About every 3-5 seconds, a DS error tells us [every spark ID on our bus] timed out waiting for periodic status 5. This includes things like the elevator,drive and intake motors. Those shouldn’t even be expecting frame 5 Rio-side right?

Background info:

  1. Checking error codes on a few steer config messages, I do see kHALError sometimes. Similarly, more rarely than the timeout messages, most to all the controllers show CAN TX and RX sticky faults in the hardware client.
  2. Our CAN bus has a long run between our base and our hand, but we tried terminating out at the hand and it didn’t improve the situation. Ending the CAN bus before it went out to the hand solved the timeouts, but this is not a usable solution for obvious reasons.

Please help if you can.
Thanks, 6995

Did you ever find a solution to this? We’re encountering a similar issue with our swerve driving neos

It turned out that burning configuration to flash was an issue if it was not delayed long enough after sending configuration messages. We used a wrapper from 1018 that put all constructed SparkMaxes into a list, and flashed them all simultaneously after all configuration was done +an extra 200ms.