search

indilib / indi

INDI Core Library Repository
https://www.indilib.org
GNU Lesser General Public License v2.1
377 stars 394 forks source link

Fixed myFocuserPro2 Autofocus Issues in Ekos #2098

Closed KenR001 closed 3 months ago

KenR001 commented 3 months ago

This small change resolves an issue with autofocus using the myFocuserPro2. It simply refreshes the driver's internal position whenever the client requests the isMoving state of the focuser. For full details of what I found please see this forum post. https://www.indilib.org/forum/development/14887-myfocuserpro2-driver-fix-for-ekos.html

knro commented 3 months ago

isn't this already called by TimerHit every second?

KenR001 commented 3 months ago

Yes, by default. The problem is the focuser can move quite a distance in 1 second. The problem is if the client commands two moves in quick succession. For example, in Ekos this issue generally shows up when the AV Overscan value is set to non-zero (default is 100). So in the example I posted above, move out 200 then immediately in 100. The INDI driver may not call the TimerHit and exactly the right time during this sequence of moves to update the current position. Therefore the in 100 command ends in some generally random location which completely breaks the autofocus algorithm. See my forum link above for a detailed example from the Ekos logs.

My proposed fix for the myFocuserPro2 driver is to simply update the position when the client is checking if the focuser has stopped moving. Generally, the client will request a move and then enter a state waiting for the driver to report the focuser has completed the move. My fix will update the current position of the focuser before reporting back to the client that the move is complete. This eliminates the error caused by the asynchronous update of the position by the TimerHit.

I believe this may be a good thing for all focuser drivers but I can only test with my myFocuserPro2.