I missed the start of this conversation so forgive me if I answer things that have already been answered or not even asked at all. I am intrigued by your problem, let me test this tonight and see if I see the same behavior.
This could be a software calculations problem which would be repeatably and symmetrical. This could also be some quirk in our interrupts that count the encoder steps, but I don’t think this one would repeat so consistently.
The firmware stores some of this data is a less than ideal manner. And I have wondered for a while if it is causing us a problem. In short, we track the position of each axis as a float of the number of rotations from zero.
When you ask an axis to move a distance, that gets translated into
635mm/mmPerRotation = 10.0. Now, we don’t want to request a position that falls in between an encoder step. So we do
10.0 rotations * encoderSteps per revolution = 81480.0 The firmware then rounds this to
81480, finally we divide by steps to get
81480/stepsPerRevolution = 10.
I added the multiply by 2 round divide by 2 code because I think I was under the impression that round operated like floor, but in looking now it doesn’t. So that is just wasted CPU time. I will mark that for fixing.
I have been worried that storing the position as a float of revolutions is an issue. Floats only have 6-7 decimal places of precision, plus I think a single integer for at best a precision of 8.
In theory, I think this should all work. We can get upwards of ~40 rotations to cover the entire work surface.
40 *8148 = 325,920 encoder steps Moving back 1 step to 325,919. 3.99998772E+2 and two steps is 3.99997545E+2.
However, there is this language on the arduino page “Floating point numbers are not exact, and may yield strange results when compared.” It has been on my todo list to convert the tracking to a long of the encoder steps. Maybe I need to speed that up.
Anyways, that was a long rambling answer that no one asked for. If anyone has a direct question about the firmware I may be able to help.