That is not how it works with INDI/Ekos and OnStep (4.24).
It does what you expect it to do.
I use the "Sync" function to compensate for the initial Goto errors, and the "Slew" to center the object perfectly before imaging.

One thought: do you have backlash in the gears?
In my case, there is backlash, and I got OnStep to compensate for it (~ 160" for RA, and ~ 30" for Dec).
If you have significant backlash, and you don't compensate for it, the motors will be turning for a while but there will be no movement, and could lead to symptoms similar to what you are seeing.

Hi Khalid.
Thanks for the reply. I don't think it was backlash since I am using a friction drive mount and it has absolufely zero backlash. I contacted Howard and he confirmed it's a bug in the way OnStepX handling sync. He made some correction to OnStepX code yesterday and that supposed to solve this problem. I am going to update the mount and try that again with Kstars.

Hi Khalid,
The latest OnstepX driver does not solve the problem. The pointing error calculation of Kstars seems to compute the pointing error based on the synced coordinate from plate solve and the last GOTO coordinate instead of the reported pointing of the scope, that is why the sync command keeps reporting the same error after sync. If I perform the goto then do a plate solve and sync, the error, say it is 100 arcsecs, then without moving the mount, I sync the mount to a different part of the sky (by right click on the sky chart then sync), then do a plate solve, the error is still 100 arcsec. The mount compare the plate solve to the last GOTO instead of the current pointing of the scope.
This is a driver bug right?

Nguyen,

Here is a suggestion that can help narrow down the problem.

You can flash your controller with OnStep 4.24, then try the same scenario that causes trouble.
If you do not see the problem, that says the problem is in OnStepX.
If you see the same problem, then it is a problem elsewhere.

github.com/hjd1964/OnStep

The only limitation here is whether your controller supports OnStep 4.24, or supports OnStepX only.

Good evening I encountered this error with my onstepX 10.22c connected by usb, "2024-02-16T17:26:20: [WARNING] Communication error on backlash (:1D#/:10100101100001110001001001010000R#), this update aborted, will try again... " what is it?
Ettore

I can confirm something is wrong with latest OnStepX and Ekos.

I have E4 and on 10.14 it worked as a charm with astroberry.

Now with OnStepX10.20a and lastest Stellarmate, sync causes driver to crash, after that guding does not work simply as command does not go through... anyone else having issues?
2024-02-16T18:46:13: [ERROR] Check system & Align if doing align to see if it went through!
2024-02-16T18:46:13: [ERROR] Unexpected return on sync call!

2024-02-16T18:30:55: [WARNING] Communication error on Degrees past Meridian East (:GXE9#), this update aborted, will try again...
2024-02-16T18:30:55: [WARNING] Invalid response, check connection

The latest release of OnStepX is version 10.20a:
github.com/hjd1964/OnStepX/releases

If using later than that you are running something significantly less proven.

Also, make sure DEBUG mode (Extended.config.h) is disabled if using a serial/USB for comms.
Also, make sure you flash according to the OnStep Group Wiki instructions (else the ESP32S might be crashing for all I know.)

If none of that does it post some INDI logs to the OnStep Group.

Hi Howard, Yes I misstyped and updated, driver version is 1.22 in Indi.

I have also included logs now in post above

2024-02-16T18:46:13: [ERROR] Check system & Align if doing align to see if it went through!
2024-02-16T18:46:13: [ERROR] Unexpected return on sync call!

My uneducated guess it is indi/ekos, as I need to restart Stellarmate, while onstep continues to work. And Astroberry works fine with 10.20a if I remember correctly.

Ok i flash tomorrow
Ettore

I really can't tell where the problem is but OnStepX had changes to the sync commands ahead of 10.20a so who knows.

More detailed command logging... even enabling logging in OnStepX (on a different serial interface than this is talking across) might shed some light on it.

I see weaknesses in the Sync :CM# command return and added code to the master to "harden" it against that. Not sure there is a problem but it's not impossible.

Oh I see that I am not the only one have problem with the sync command here. The Onstep driver on my setup also crashes everytime a Sync issued

Something has changed, or I changed something, now sync works on first or second solve, then it breaks, i need to disconnect and then reconnect, to be able to sync.

From sky safari no issues at all, so I would think it is on ekos side