1. Automatic Meridian Flip at Limit: (on SWS) : Off

I think that might be the cause of your problem. It is the mount that decides to and performs the meridian flip. KStars just issues a goto that the mount decides requires a flip.

Thanks, Ed.
How should I put the meridian limit on the mount and on Ekos? For my CEM70, if I set meridian limit on my mount to say 7 degs then I have to set it to lower than 7 on Ekos and the mounts perform just fine. Is OnstepX's settings the same?

I believe it's similar but you'll have to test with your kit to determine effective limits.

Okay so here's how the setting should be with OnStep for it to work with Scheduler automation
I put this here for reference for anyone else run into the same problem as I did:
1. The flip limit on Mount panel in Ekos should be set to 1-2 deg pass meridian.
2. The flip limit on OnStep should be set to a number higher than what you have on Ekos (if Ekos has 1 deg then OnStep should have 4-5 deg, the number should be positivel
3. The preferred pier side should be EAST (this is important, without this, the mount wont flip).
That's all. The mount should now flip in tandem with Ekos scheduler.

I have ran into this weird little bug on ekos and OnStepX (10.19.k) i am not sure it's an OnStepX problem or a problem with how the INDI driver work. The problem is as following:
1. Action set to Sync in the Alignment tab.
2. After a goto and plate solve, there is an amount of pointing error. (Lets say it's RA:250 " DEC: 300"). The INDI perform a sync with the scope and it says the sync is completed successfully.
3. Now if the mount is tracking and you continue to perform a platesolve without any goto/slew then you'd expect the new platesolve error to be near Zero (since the scope pointing was synced with the last platsolve) But no, after the solve, the error still showns exactly as before. (Still RA:250 " DEC: 300"). This will continue no matter how many time you do the platesolve/sync. The only way to bring the error to zero is by changing the action to "Plate solve and slew". The mount will platesolve, sync the error, then goto the new position, after the second sync, the goto error now is corrected.
Is this how the sync should work on OnstepX or is it a bug? I think because of this, the mount unable to build a model correctly with KStars?

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.