-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CANcoder configurator refresh has chance to fail the first time it is called #76
Comments
Can you take a hoot log of the problem occurring and send it to us? |
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. |
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. |
Our repo is private, but I sent you an invite. The current code is in the This first gets called when the FL module gets created at line 141 in RobotContainer.java |
Correction on this, we configure a Pigeon 2 first, so its not the overall first config call, but is the first refresh call. |
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.
The text was updated successfully, but these errors were encountered: