search

CrossTheRoadElec / Phoenix-Releases

Release repository for Phoenix-Framework and Phoenix-Tuner
76 stars 7 forks source link

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

Open mjansen4857 opened 4 months ago

mjansen4857 commented 4 months ago

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 commented 4 months ago

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

mjansen4857 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.