CANcoder configurator refresh has chance to fail the first time it is called

[mjansen4857]

For the first call to CANcoder.getConfigurator().refresh() (maybe TalonFX too, we don't use that however so unsure) there is a small chance that the refresh method will fail, regardless of how long the timeout is.

In our code, we are loading the current configuration using the refresh method to keep its magnet offset, then changing the sensor direction and sensor range before reapplying the configuration. However, sometimes this refresh can fail leading to an encoder losing its offset after starting code.

This only happens for the first call to refresh, every other call after always works. We have tried using a large timeout (2 seconds) and that does not prevent it from happening. We have worked around this for now by also storing the magnet offset on the RIO, and using that if refreshing the config fails.

[CoryNessCTR]

Can you take a hoot log of the problem occurring and send it to us?

[mjansen4857]

I’ll try to get one, but the problem is very rare. It’s only happened 2-3 times in the past few weeks.

We don’t record hoot logs by default so we don’t currently have one.

The refresh call that fails is the first configuration related call whatsoever in our code, if that helps.

[CoryNessCTR]

I can try to reproduce it, but the hoot log would be a great help for debugging the issue. Just make sure you start logging before the refresh call.

Do you have a github link of where it's happening? I want to get as close as possible to your scenario to try to reproduce the issue.

[mjansen4857]

Our repo is private, but I sent you an invite. The current code is in the pre-flr branch. The line where the refresh is happening is in frc/robot/subsystems/swerve_module/SwerveModuleIOPhoenix.java.

This first gets called when the FL module gets created at line 141 in RobotContainer.java

[mjansen4857]

The refresh call that fails is the first configuration related call whatsoever in our code, if that helps.

Correction on this, we configure a Pigeon 2 first, so its not the overall first config call, but is the first refresh call.

[daltzctr]

We haven't received any other reports of this issue and haven't been able to identify this problem in our own testing. Is it possible that the occasional instances you had were instances were the bus was bad/unhealthy for a brief period of time?