Problems arise when:
-Changing bumpstop strength and ramp values
How it behaves:
-Wheel centering offsets with approximately the amount of bumpstop ramp degree value every time I change any of the bumpstop fields and wait for the drive to acknowledge the change.
-e.g.: I fiddle with bumpstop with a perfectly centered calibrated wheel, say I change either value by any amount in any direction, after about 9 different changes and turning the wheel lock to lock to test the effect, the wheel center goes all together 90 degrees offset to the right. Always to the right.
I have to re-run motor and encoder calibration after I finished playing around the bumpstop.
Is it with just my wheel or is it a valid bug in the configuration tool?
Before I get to test this, you can verify that this is not a mechanical issue by using a pen to draw a marker on the servo shaft and the shaft clamp to verify that it is not rotating/slipping.
That was my first thing to do installing the wheel. I marked the index point on the shaft.
After the first time I encountered this issue, I removed the wheel from the shaft and the motor shaft did not lose center mechanically.
Then I reproduced this bumpstop issue several times with the same result without using excessive force.
I did some fast analysis of the things the code does.
Changing those values is no different to changing any other values on the hardware tab, or in fact on the profile tab. First the hardware setup values are re-sent to SimuCUBE, and then all the profiles are sent as well.
Does any other setting change result in the same type of behavior?
I’m not aware any other setting does this.
I will try to replicate it tonight and see if I find a more direct relation
Maybe the wheel was in motion close to the endpoint while changing settings. There is a small delay between changing the value and feeling the effect in the force. I might have turned the wheel out of the limit zone while changing its value.
That might be it, as setting up the parameters to SimuCUBE might take just enough time that the SimuCUBE firmware misses some or many of the 16-bit differential encoder values.
The next version of the firmware already has a mitigation in place (pending testing), where the full 32-bit encoder position is read again after the possible pauses in IONI communication updates. If that turns out to not work, then I also implemented a dialog which prevents the updates to be sent to SimuCUBE if wheel is observed to be rotating too fast.
