Eric,

I missed any code to correct the position so that given physical tube position is always at the same number of ticks. This is the reason to move out past the target and then back. If backlash is always added to move out, the backlash going inwards must be taken out to have the gears in full contact. If the gears are in full contact, there will be minimal slippage of the focuser outwards. Without the inward backlash taken out, the focuser can slip out up to the amount of backlash. As programmed, I'm moving out dist+actual_backlash+extra and moving back actual_backlash+extra. (Backlash is defined as actual_backlash+extra.)

Since the Uno version seems to be working, I'll take it out the next time I have a chance and will see if it works better than the original version I had. I already like AccelStepper over the simple stepper that was in the other code.

Thanks.

Aah yes, slippage, understood. I didn't cater for slippage at all on my setup, the stepper controls the micro knob of the scope focuser, which doesn't slip at all, even with stepper backlash. But "at all" might be a little presomptuous here, thanks for reminding me.

I'll try to use your patch if my setup, that seems a very good idea. But don't you need to do the same on both sides? Else the position value will be wrong when the Ekos focuser looks for the local minimum and there will be some sort of dead zone I'm not sure it is able to manage.

-Eric

My thinking is to always focus inward. Even when going to a higher number of ticks, the number of ticks goes up by the backlash, the focuser moves out extra+ y (y is the desired movement outward) ticks, the number of ticks goes down by the backlash and the focuser moves in the extra ticks to leave the focuser at +y with backlash compensated.

In my normal usage, I go to a preset which requires inward focus to get to the minimum. After the minimum is reached, which is defined by drawing in past the minimum, the focuser commands an outward movement. Using your logic, I compensate for the backlash and go out the number of ticks. An unfortunate side effect is the focuser could slip on out the outward backlash. Using my logic, we command the focuser to move as described above and return to the target position.

To move the focuser inwards, the backlash was compensated on the outward movement. Think of this as being equivalent to biasing the RA axis east heavy.

That's clear. Do you manage movement requests smaller than the backlash value?

-Eric

Any movement outward, no matter how small, should be compensated with this logic.

For example, I'm using 24 for the backlash plus extra value. A command to move outward 4 ticks would result in unwinding the true backlash and moving outwards by an amount of 28 ticks (24 + 4). After that, the default command outside the if() block would move the focuser inward 24 ticks (unwinding the true backlash and moving the extra included in the 24), leaving the focuser at a true 4 ticks outward.

I am concerned the if() never evaluates as true. I need to see what I can do to confirm it does and the focuser responds as intended. I was thinking increasing the delay to 1000ms might give me a simple chance to see the move past and then the move back in INDI. The alternative would be to include a print that "outward test is true, moving out plus backlash". Your thoughts?

I now have code that implements the backlash compensation, but I don't get progress information until the scope moves forward.

Here is the code:
Any suggestions on how to get the position to update while going outward? There will be no feedback moving from all the way in to a defined preset.

Thanks.

I finally got this sorted and have reasonable focus results. There may still be a bit of seeing issues, but, in general, the v-curve looks better than before backlash compensation.

I forked TallFurryMan's firmware and removed the dustcap control as well as implementing backlash compensation. The firmware can be found at github.com/beckrd/Moonlite_Focuser .

That's great! Do you have a screenshot of the v-curve resulting from the Focuser module activity?

-Eric

I don't have a screenshot, but I have re-created the v-curves from the logs.





After reviewing all the filters, I may not have enough backlash compensation yet. Thoughts?

This graph is a cool source of information! Assuming the order in which you focused with filters is L, R, G then B, it seems the position reported to Ekos is wrong as moves become smaller. The problem seems located for moves lesser than 10. I know that my original attempt at managing backlash is wrong when the movement request is smaller than the backlash amount, and I measured a backlash of ~10 ticks on the 28BYJ-48. It might be a similar problem?

-Eric

I'm still biased that the backlash isn't fully compensated. My goal of having enough engagement for the focuser to not slip outwards seems to have been met. I ran the R, G & B frames through PixInsight's SubframeSelector script and had the most consistent results I've had since the focuser was installed.

For the next night out, I think I'll change the backlash to 100 to improve the meshing of the gears both directions. If the issue on HFR vs focus position the other night is because backlash is non-symmetric, I can't think of how to correct it.

This is a good idea, now that you actually removed the backlash value from your equation. As you say, that will work only if the backlash is identical if both directions, but there's no physical reason it should be different.

I think the auto-focus procedure goes far for the L filter because it is the first filter, and only refines with smaller values for other filters, expecting the focus point to be close. It might be a problem, it seems you have a very low number of iterations when focusing subsequent filters. To me the number of samples that we see on the curve for G and B can't be used effectively to provide a minimum, and is certainly used jointly with the previous results. That is probably not what you want.

Perhaps you could use the filter offset panel to force a large outward offset before starting the procedure and see how it behaves? One thing you could try is change the order of filters to check if the weird curve slopes follow the filter type or the filter order.

In all cases it's good that you could achieve your primary objective indeed, congratulations

-Eric