Yes, it would slow down Autofocus. If say it takes 1 second to move between focus points but say 5 seconds for the initial movement and another 5 seconds for the final move you could set the timeout to say 7 seconds. You add a minute or 2 to the Autofocus but it should work. If it doesn't work then I'm thinking my theory on the driver bug isn't correct.

If I remember well I put the polling at 10 sec and then 20 sec (it's really a very slow focuser). The problem is that you don't know the state of polling when you push the autofocus button, and no matter whether it's 0 or 642 at the time it wants to do the follow-up move, it still starts from a wrong assumed position. I might have had looking on -- I'll have a look.

Out of luck -- I now remember that I did but it was going to "default" not file.

I'll try again next time it's clear.

Cheers,
Richard

So working on your idea that current position and "steps to go" have got confused, I took a look at the fli_pdf driver.

When a move completes it sets the absolute position to the current focuser position...
FocusAbsPosN[0].value = FLIFocus.current_pos;

However, on a polling update when the focuser is still moving it sets the absolute position to the steps remaining...
FocusAbsPosN[0].value = FLIFocus.steps_remaing;

Ekos is expecting the absolute position to always be the current position so this I think explains the problem.

I'll ask Jasem about this from an Indi perspective to make sure I'm not missing something.


Did you make any progress on this? The latest version I have is 3.6.9 and it's still broken, and it's driving me nuts.

As well as the overscan issue, which I can live with, the crazy aspect of this bug is that if focusing fails, the focuser heads off to position 0. This is far away from the correct value and there is no recovery except to stop everything, move it manually (well, with controls obviously) and start again. I've had it several times tonight.

It's a known bug and, in my book, should not be controversial to fix it.

Cheers,
Richard

Hi Richard,

Sorry about this. I've nudged @Jasem about it again. I'd rather not fix it myself as I have no means of testing it and don't have any experience of this driver. Jasem might not have access to the hardware either, I'm not sure, but does know the driver. I guess we may need your help to test it out.

I'm extremely willing to help!

Hi Richard,

I've raised this issue in Indi's git...
github.com/indilib/indi/issues/2028

Please feel free to add anything I've missed.

Hopefully one of the Indi folks will pick this up and fix it.

Hi Richard,

I've just pushed a change that might be helpful to you whilst the driver is being changed. I can't test it, so this is just a theory.

You can now configure a delay between the outward and inward movements of an Overscan....


If you set this > whatever the Indi timeout for your FLI_PDP is, then... when you do an Overscan, the outward leg will complete and the last update from the driver to Focus "should" be the current position (rather than steps to go). Then when Overscan triggers the inward move, it "should" use the current position rather than 0.

So, for example, if your Indi timeout is 1second, set this field to 2seconds and give it a go. Fingers crossed!