Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed myFocuserPro2 Autofocus Issues in Ekos #2098

Merged
merged 1 commit into from
Aug 19, 2024
Merged

Conversation

KenR001
Copy link
Contributor

@KenR001 KenR001 commented Aug 18, 2024

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

@KenR001 KenR001 changed the title Fixed autofocus issues in Ekos Fixed myFocuserPro2 Autofocus Issues in Ekos Aug 18, 2024
@knro
Copy link
Contributor

knro commented Aug 18, 2024

isn't this already called by TimerHit every second?

@KenR001
Copy link
Contributor Author

KenR001 commented Aug 18, 2024

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.

@knro knro merged commit 97d8031 into indilib:master Aug 19, 2024
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants