I would like to propose an alternative solution for the Backlash compensation. By always ending the movement in one direction, such as if the movement requested is in the other direction, the focuser overshoots the target position by a given number of steps and then goes to the target position. This way, the position of the focuser is always measured with the gears tight against the same direction, so backlash doesn't affect the position of the focuser.
This is better than backlash compensation, as it avoids any error in backlash measurement, plus any possible changes in backlash depending on weight and orientation of the focuser.
Also, SCTs or any telescope which focuses by moving the main mirror suffer from focus shift, which is minimized if the last movement is done so the mirror is moved against gravity (counter-clockwise in a C8).
EDIT: I forgot to say that the overshoot distance has to be greater than the backlash to correctly work. I use x3 times the approximate backlash I measured, but any value sufficiently large will perfectly work.
Last edit: Daniel 2021-03-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Daniel
The myFocuser only applies backlash if there is a change in direction.
The code applies backlash before any move takes place
The move is done after backlash has been applied - and the move will always been the same direction as the backlash compensation.
The myFocuser also allows backlash compensation in either or both directions and each can be configured independent of the other.
To support other methods of backlash the myfocuser allows the firmware backlash code to be "disabled" and this lets packages like NINA and others handle backlash using their own algorithms. That sort of negates the argument for including it into the firmware.
I am familiar with the method you have pointed out as well as other alternative methods of backlash compensation.
The myfocuser has got to the stage where any additional code can only be added at the expense of existing code. In others we have run out of space and there are litle if any more "tricks" we can use to add extra things or reduce code size to make more room for extras.
With the myFP2ESP, especially using the ESP32 chip, we have a little more room to play with and some of the code branches support multiple methods of dealing with backlash.
Regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to propose an alternative solution for the Backlash compensation. By always ending the movement in one direction, such as if the movement requested is in the other direction, the focuser overshoots the target position by a given number of steps and then goes to the target position. This way, the position of the focuser is always measured with the gears tight against the same direction, so backlash doesn't affect the position of the focuser.
This is better than backlash compensation, as it avoids any error in backlash measurement, plus any possible changes in backlash depending on weight and orientation of the focuser.
Also, SCTs or any telescope which focuses by moving the main mirror suffer from focus shift, which is minimized if the last movement is done so the mirror is moved against gravity (counter-clockwise in a C8).
I find this solution very practical, easier and better than typical backlash compensation, and would be great to have it in the focuser firmware. It is already implemented in NINA and APT (discussed here: https://aptforum.com/phpbb/viewtopic.php?f=16&t=4313&p=27729&hilit=overshoot#p27729 ).
Best regards.
EDIT: I forgot to say that the overshoot distance has to be greater than the backlash to correctly work. I use x3 times the approximate backlash I measured, but any value sufficiently large will perfectly work.
Last edit: Daniel 2021-03-30
Hi Daniel
The myFocuser only applies backlash if there is a change in direction.
The code applies backlash before any move takes place
The move is done after backlash has been applied - and the move will always been the same direction as the backlash compensation.
The myFocuser also allows backlash compensation in either or both directions and each can be configured independent of the other.
To support other methods of backlash the myfocuser allows the firmware backlash code to be "disabled" and this lets packages like NINA and others handle backlash using their own algorithms. That sort of negates the argument for including it into the firmware.
I am familiar with the method you have pointed out as well as other alternative methods of backlash compensation.
The myfocuser has got to the stage where any additional code can only be added at the expense of existing code. In others we have run out of space and there are litle if any more "tricks" we can use to add extra things or reduce code size to make more room for extras.
With the myFP2ESP, especially using the ESP32 chip, we have a little more room to play with and some of the code branches support multiple methods of dealing with backlash.
Regards
Robert
Thanks for the explanation, and for your great work. This is an awesome project!