My focuser driver (FLI PDF) does not support backlash, so to investigate potential backlash I must use AF Overscan. However, this consistently causes errors, where in autofocus or just normal commanded focuser movements.

An example: I set it to 50 units and command a movement (from 50000) to 51000. The focuser moves to 51050, and the Steps field counts down to zero, a message appears in the console panel below saying "Focuser error, check INDI panel". Now the Steps field shows 51050 and there is a second message, also saying "Focuser error, check INDI panel".

The INDI panel shows 2 lines:
[INFO] focuser is moving to position 51050
[ERROR] Requested position out of bound. Focuser minimum position is 0

I'm attaching a trimmed log -- I removed a large number of identical entries from 14:34 until after 18:00 with reports every second of a stationary focuser.

Cheers,
Richard

Hi Richard,

Couple of things:
1. Can you post the full log please.
2. Does everything work well with Overscan set to zero (i.e. turned off)? I.e. is is definitely an Overscan problem or a general movement problem. I suppose the way to tell is to set Overscan to 0; start at 50000; move to 51050; then move to 51000.
3. I don't know anything about this focuser. Do you know if its an "absolute" or "relative" movement one. I.e. can you command it to an absolute position that is the same for different sessions or do you command it to move in / out by x ticks from its current position?

Hi John,

thanks for looking at this.

1. The full log is attached. I'm not sure it shows more.

2. Yes, it works fine with overscan set to 0 -- it's the only way I can get autofocus to work (sort of work anyway, which is why I want to explore overscan)

3. It's an absolute position focuser. I've been using it for years with TSX, but also there my focusing was never reliable. Mind you it's a scope with a focal length of 1962mm, at f5.45 and has a huge central obstruction, so it's a bit of a beast.

Cheers,
Richard

Hi Richard,

I was hoping to see the Focus process startup messages but they aren't in the file. Maybe you started up without logging and subsequently turned it on?

From the first log the focuser starts at 50000 and tries to move to 51050. But half a second later its at 663 then a second later its at 0. Then is reports OK which is weird because its been asked to go to 51050. OK is the signal that its arrived at its destination, so the Overscan tries to move it in 50 which would take it -50 which is out-of-bounds, hence the Indi error messages.

So its a bit puzzling. Why when the focuser is at 50000 and has been asked to go to 51050 would it go in the other direction to zero? Focusers move at different speeds but 50000 to 653 in half a second is unusually fast - does it sound feasible? And do you know if it was physically moving all the way to zero, or just reporting it was at zero?

There's nothing in the log to indicate why it moved to zero. No request to move to zero. Is anything else connected to the focuser at the same time that might be conflicting?

The part that has "gone wrong" is just an outward move from 50000 to 51050. The request to the focuser is the same as if you typed in 51050 and hit Goto. It might be worth just trying the moves with Goto and try and narrow down where it goes wrong.

Very puzzling.

Hi John,
I was hoping to see the Focus process startup messages but they aren't in the file. Maybe you started up without logging and subsequently turned it on?

That's why I trimmed the file! -- there was nothing useful there. I tried resetting logging hoping to obtain a header but no joy. I gather from your post I have to start up the whole app with logging already on. I can do that later (I'm characterising filters at the moment -- I found that with increasing the span per step to 1000 and averaging over 3 samples, and also my zenith seeing tonight is 1.4", it's working pretty well).

From the first log the focuser starts at 50000 and tries to move to 51050. But half a second later its at 663 then a second later its at 0. Then is reports OK which is weird because its been asked to go to 51050. OK is the signal that its arrived at its destination, so the Overscan tries to move it in 50 which would take it -50 which is out-of-bounds, hence the Indi error messages.

The focuser is pretty slow -- those values are the remaining steps to the commanded position. That wasn't obvious to me at first, but it's the case. I suspect the slowness of its movement is what's causing the problem. Maybe all focusers have these steps-to-go messages but they're gone before they have a chance to cause a problem.

So it's a bit puzzling. Why when the focuser is at 50000 and has been asked to go to 51050 would it go in the other direction to zero? Focusers move at different speeds but 50000 to 653 in half a second is unusually fast - does it sound feasible? And do you know if it was physically moving all the way to zero, or just reporting it was at zero?

It was reporting zero, but it was the remaining steps until the destination which was interpreted as position. It shows up in the left hand field which should show position.

The part that has "gone wrong" is just an outward move from 50000 to 51050. The request to the focuser is the same as if you typed in 51050 and hit Goto. It might be worth just trying the moves with Goto and try and narrow down where it goes wrong.

Then it would go to 50100 and the same error would pop up. I've tried it before.

I suspect this focuser is just slower than others you've dealt with -- after all it has 105000 steps for just 13mm of travel, and takes a couple of minutes to move those 13mm.

Cheers,
Richard

And another problem in consequence of this confusion between steps to go and position -- if autofocus fails it wants to move to the starting position. Depending on when it decides it failed it really does move back to 0. This is in about half of failure cases. Hitting Stop doesn't stop it. It takes ages to go back to 0, and more ages to get back to mid-scale where I'm operating it.

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.

In the interim, you could set the polling period above what Autofocus needs to complete each move so that the polling update doesn't get called. If this theory is correct then that should fix the problem.

Thanks. I'll give that a try. It will allow me to check out AF overscan.

In the meantime I packed up for the night. The seeing degraded to more than 5", which was a mystery until I left the warm room to close the roof: the wind had got pretty strong. From flat calm until 20:00 we now have gusts of > 25 km/h.

Cheers,
Richard

No astro for me, I have a storm coming - winds between 95 - 130kph tomorrow.

Oh, that's nasty. Hope you have everything tied down!

Guess I'll find out

Guess I'll find out
I hope that worked out!

In the interim, you could set the polling period above what Autofocus needs to complete each move so that the polling update doesn't get called. If this theory is correct then that should fix the problem.
I tried it, but the problem I found that whatever interval I set for polling, there's no way to synchronise the polling with what's happening in autofocus. So I still ended up with anomalous values of position.