Moving an issue raised by Peter Sütterlin from another thread...

Not sure if that's the right spot, or should go into another thread. But something is messed up with this backlash compensation in the AF module. I never understood why that value should in any respect be related to the BL compensation of the focuser driver (if that offers one), as it is done at the moment. IMO, this has to be a completely separate action: If BL comp is enabled for the focus module, then it will just always do this additional overshoot-and-return with the amount specified for the focus module. You do not need to know if the driver will (also) do some BL correction or not. If it does, both of the positions you go to will be correct. If it doesn't the first one (likely) will be wrong, but you're not interested in that one anyhow.
I do not see how, in such a scheme, the two corrections can interfere. All you do is tell the focus to be set to some value. If that does not work properly, then it is an issue of the focus driver only, and needs to be solved there. But don't touch the drivers BL setting.
(For me that even completely messes up the BL settings: I have two trains, with different telescope/camera/focuser, and switching between them with the 'BL correction' active, will erase my BL settings in the driver when toggling between the two. Status git as of yesterday)

Hi Peter,

I guess this is some older code I don't really know the history of. My guess is that the Linear focuser built in some backlash compensation for focusers where the driver did not offer backlash support. As you say if the driver offers support then Linear just gives a double dose that should all work out. As to why the driver backlash field and the autofocus routine backlash use the same field I have no idea, although it seems to work and I can't see what benefit have 2 different values would bring (but maybe there is some value).

Linear 1 Pass inherited the approach from Linear.

In Ekos 3.6.1 there is no way to "turn off" focus algorithm's backlash compensation. I put a patch in for 3.6.2 to allow it to be turned off (or left as it is in 3.6.1) by the user.

This flag is just a part of the focuser config that is saved per optical train as is the backlash field.

I've just tried creating a couple of OTs on the simulator and storing a different backlash value for each and it seems to work fine. Can you explain a bit more about how your backlash is getting messed up?

Thanks for moving it to a separate thread, John.

OK, two parts.

If a BL comp is defined in the driver, and AF uses the same number, it is actually applied twice. Always. Doesn't make too much sense (IMO). OTOH, I might have BL comp active, and set it to an approximate value. In my experience, the reaction of the focuser often isn't a step function, and for shorter moves (in the range of maybe twice the BL) the correction isn't correct to the digit. So I'd set my driver BL to 80, and the AF one to 20, to remove the last play.

If there is no BL comp from the driver, right now it uses a fixed value (not sure?) - but is that a good value for everyone?

So I think it would be reasonable to have a separate overshoot setting and not care about what the driver does at all. Have a checkbox to use the overshoot in the input field. Or, don't have a checkbox at all, and always use the value of the input field (defaulting to 100), or do nothing if the user sets this to 0.


As for what I did - maybe something stupid, I don't know. I was about to start observing (after almost 3 weeks of bad conditions), so I probably wasn't patient enough. I had switched OT to the secondary (ASI1600, DMFC with BL 139) and done an AF run. Then switched to main (ASI2600, EAF with BL 84) and did a run there. I wanted to verify that number change properly, switched back to secondary, and it displayed BL 1. Switched to primary, and that one was 0. Checked the INDI tab of the EAF, and BL comp had been disabled....
I will check again today once the devices are connected, maybe I had a bad setting somewhere (I don't focus the secondary too often, it was the first time since the switch to OTs).

But I think the first point should be considered, likely in discussion with Hy who did the first linear implementation IIRC. Already at that time I had wondered about the link to the driver BL value....

OK, it seems I had some bad value in the focus tab, and that was overwriting the setting. I've now "defined" the values there - I was used to doing this in the driver.

What I don't like is that - regardless of the setting in the "AF Backlash Comp" checkbox, whatever value you enter there will be also written in the drivers BL field in the INDI tab. And the BL comp in the driver gets enabled if it was disabled...
That isn't consistent with the tooltip, as it will do the correction both in the driver and in the AF module.
So currently there's only the choice to use only the drivers BL, or both.

My two pence worth…

surely it would be better to split off the backlash settings from the actual focusing algorithms given they are more to do with the focuser mechanics than how you work out how to do a curve to determine the best focal point?

Also looking at NINA that seems to have an idea of both in and out backlash compensation. Not sure whether you use both or just one. Which also brings me to in/out direction and sct’s, I’ve yet to try this out at night, but it looks like working in the in direction drops the mirror when really want it to be raising it. Maybe a switch would be of use for that, again maybe as part of the focuser mechanics.

Well, the great deal of the linear algorithm was that it did introduce such an overscan L compensation, as EKOS/INDI have no way to do this (I had posted a wish for that, but it had been declined). If there is a way to migrate that from the linear module to a general feature, I'm all for it

Also, one has to be careful with what the "compensation" does. AFAIU, the one in the driver is (usually) changing the number, i.e., if you reverse direction, it will make the additional BL steps, but not count/report them. This can only work if the number is the same in both directions. Different in and out values are only possible with this overscan method. But I also don't fully get why one would do it - can they even be active at the same time??

As for your direction issue: Usually the driver has a 'Reverse Direction' setting that will define what 'in' and 'out' is (e.g., it obviously depends on which side you mount the motor). For an SCT one issue is that lifting the mirror up will move the focus outwards (away from the telescope). So be sure to pick the right one...

Looks like I was misunderstanding NINA.

The relevant page is nighttime-imaging.eu/docs/master/site/advanced/autofocus/

They have two types of compensation.

1.Absolute where it adds on a set of steps at a change of direction - looks to require knowing quite accurately your backlash. Not sure if this can have different numbers of steps for in and out as it doesn’t say but the gui having both seems to point to a possibility.

2. Overshoot which moves past the point then back to it. This has either in or out steps set but only one. This is so the focuser always completes its movement in one direction.


There’s a tip later in the manual - “ Overshoot can be very useful for SCT users to avoid mirror flop. In fact, when setting the Backlash Compensation to IN, the last focuser movement will always be outwards.”. Looks like NINA uses this rather than a switch like I was suggesting. I suppose the extra back and forthing is of little consequence just doesn’t seem tidy to me.

Now time for me to check whether the Celestron sct does the backlash compensation wiggle each move or not..

ok the relevant code looks to be :-
——-
// implement backlash
int delta = targetTicks - FocusAbsPosN[0].value;
if ((FocusBacklashN[0].value < 0 && delta > 0) ||
(FocusBacklashN[0].value > 0 && delta < 0))
{
backlashMove = true;
finalPosition = position;
position -= FocusBacklashN[0].value;
}

if (!startMove(position))
return IPS_ALERT;

———
so the answer looks to be yes. If it’s moving inwards - delta <0 and focusBacklash is positive then it will subtract the backlash ie move further inwards, then later in another bit of code move outwards to the final position. This occurs for both absolute and relative moves. Doesn’t seem to worry about whether this is a change of direction or not which in this case is for the good.No idea why it would want to have backlash compensation in the other direction but the code seems to allow that.

Thanks for your thoughts both.

Peter, I'm still a little unclear what the benefit of using both driver backlash and AF backlash compensation is? Let me replay what I think you're saying and you can correct me. Lets define:
"consistent" = backlash in equals backlash out
"predictable" = backlash value is always the same everytime the focuser is moved.

Now "predictable" isn't really black or white but more shades of grey. On my focuser 1 or 2 ticks makes no different to focus so if my focuser is unpredictable by 2 ticks then as far as I'm concerned thats good enough to be called predictable. One may be able to argue that as long as the focuser is accurate to within +/- half the critical focus zone then as far as focusing is concerned it can be thought of as predictable.

1. If your focuser has consistent and predictable backlash then just set the number in the driver and all's good. Overscan provides no benefit.
2. If your focuser has consistent and unpredictable backlash then you could set an average value in the driver but moves will be wrong by +/- half the range of values of deltas of backlash. A better approach here is to use the overscan method as it will be more accurate. Combining overscan with driver backlash will also work.
3. If your focuser has inconsistent and predictable backlash then you'll need to set different backlach in and backlash out numbers. Since there is only 1 field in indi this isn't possible (unless the driver stores the values somewhere else, like for example, the firmware of the focuser). Overscan won't work as it assumes a consistent focuser. It could be changed of course, but probably better to add this to the driver and keep overscan simple (just my opinion).
4. If the focuser has inconsistent and unpredictable backlash. You're not going to get good results with this so upgrade the focuser!

Hi John,

Your item number 2 already is the case where both methods are used, and to the benefit of the user IMO.

Also, we clearly have two approaches that do different things. So - again IMO - they should stay separate and independent, especially when one of them is only used in a subset of applications (i.e., the linear algorithms). So just make it optional to use the overscan method (either with a check box, or just by setting the field to 0), but without changing anything in the driver settings.

The use case then is if I don't trust the accuracy of the focus position (be that with or without internal compensation) then I use the overscan, else not. Even if the focuser is absolutely perfect the additional overscan will only cost you some time, but not degrade performance/accuracy.

Definitely in the current state things can/will go badly wrong because the value entered there is copied to the driver setting. For overscan, one usually sets the number higher than the actual BL of the unit. If you do that, also the driver will be set to this (too high) number. This will not affect the linear algorithms, as they always do out/in combinations. But if you manually move the focuser, or switch to another algorithm, that (wrong) correction will stay active, and mess up your focusing.

As I see it, currently the only safe method is to have overscan active, and use the correct value of the BL. This will do the correction twice, yes, but at least the behavior will be the same for other algorithms, too.

Hi Peter,

So in case 2 it wouldn't it be better to drop the driver backlash and just use overscan, as by definition driver backlash has been deemed poorer than overscan. You can do this today by setting backlash to 0, setting AF Backlash Compensation on. Linear and L1P will use overscan of 5 * Step Size.

Out of interest are you using the ZWO EAF?

Let’s split things down a bit.

1. You have the algorithms - they take a set of data and work out where the optimal focus point is. The data could be a set of images plus focuser position or something like the current temperature and some preprocessed info for it to work out where the focus point is.

2. Backlash - this occurs afaik on change of direction of the focuser mechanism. Simplest solution appears to be to overshoot by some amount greater than the max backlash then move to the real position. It doesn’t really matter if the backlash varies each time or in either direction as long as the overshoot is greater. (I’ve no idea why NINA looks to have settings for both - this could just be the gui misleading me and only one is actually used).

3. Final move direction - in the case of sct’s with a focuser moving the mirror final the move direction needs to be against gravity. This move would also need to apply backlash compensation if it was a change of direction.

Current setup seems to not be quite right as it different parts seem to try and solve problems of other parts. I think the link between the backlash setting in the main gui needs splitting off from the focuser indi driver. Then the backlash compensation done independently of the algorithms and drivers if wanted by the user. The algorithms shouldn’t have anything to do with backlash. The indi driver could implement some focuser specific compensation if needed. The final move direction I think would be in the driver and would be active on every move that’s not in the ideal direction. This would shield the algorithms from bad positions without them having to know about it.