So maybe you didn't upload the latest? because it is a different time than what you said: 7.1.24 19:04
Looking at the size it is the correct build, despite the different date and time. (This is normal if you did not copy or download with the corresponding switches, like "cp -p <file>" in a LINUX terminal.)

I do not understand, why [Capture & Solve] did not catch the ominous initialization values. The program flow in the module align is extremely complicated and I still do not understand all the turn-offs. I'll put another version this night with even more logging regarding the capture & solve routine.

Project "Difference Slewing" Version 11.1.2024 22:11 with more logs for [Capture & Solve]:

• KStars binary UBUNTU 22.04 x86_64 -> invent.kde.org/escriban/kstars/-/issues/1

Downloaded and installed. Hoping for clear skies. Not this week much. Probably enough to test.

Thank you.

Bryan

I'd like to join in here. I'm a new user of Kstars/Ekos (since about a week). I have a Paramount (2 actually) and have been using TheSkyX for many years, so am pretty experienced in using it.

I've been slowly getting the Ekos ecosystem up and running (not helped by the bad weather we've been having recently) and tonight (during a clear but cold spell) got around to checking the Align module. I had the same problem reported above. The image apparently solves, and comes up with a correction. Then it moves the scope and takes an image, which looks to be properly aligned. But in doing so it updates the scope position and solves again - but since both scope position and the new solution have moved by the same amount it generates the same error a second time. So the progression starts, moving across the screen by uniform increments (with a direction determined by the initial error).

I thought I was going nuts, until I found that this is a known, although recent, problem.

I'd love to get it fixed, though as I'm using macOS I'll have to wait for a new distribution.

Cheers
Richard

Maybe it's due to how Paramount syncs and this why "differential slewing" might be a better option?

I don't think it's that. I was using Differential Slewing, not sync. Specifically, in the Options->Scale & Position tab I checked "Use differential slewing instead of syncing". The behaviour I described was when I selected "Slew to Target" as the Solver action, then click "Capture and Solve".
If I select "Sync" as the Solver action then I get a message saying "Mount is synced to solution coordinates", but no further movement (and no change in subsequent capture and solve behaviour).
If I select Nothing, then the Solver works of course, but the target remains uncentred. It's not much of course - about 3 arc minutes in this case, but annoying all the same.

As I mentioned before, it looks like the problem is caused by the slew to target also updating the telescope coordinates (in the box above solution coordinates. So when the solver finds the coordinates of the new image, it's comparing them with the moved telescope pointing, and so, of course, finds the same error.

Thinking more about it:
When the telescope slews to an object, say a star, it slews to the location of the star, and reports this as the scope position.

When the image is solved, a position error is determined, and the scope (a Paramount with differential slewing enabled) is moved by the required amount so that it actually points to where it was supposed to be. So it's not correct at that point to report the position back from the scope -- instead the reported positions need to be adjusted for the amount of the differential slew, so that the scope position reports the same as it did before (i.e. the position of the star).

Then the solver will find the image in line with the scope position.

Cheers,
Richard

Jasem, there is indeed a problem with differential slewing for at least Paramounts, and other mounts that shouldn't sync. Toni has been working on it, and his beta build is much improved. Ive still had some strange issues with flips, and an occasional issue with failing to center. Apparently it all started with some changes trying to fix the rotator logic. If you read through this thread you'll see the progression. Richard's issue is exactly the same as mine running the current official bleeding build. Im using Toni's binary at the moment, and it's mostly functional. I have yet to characterize the issue with flips, other than to say that it seems to flip at a nonsenical time, making the mount point to a dangerous place. and then pointing into the wall of my observatory not being able to use the camera at all (everything greyed out). Once I issue a flip again from TSX, then it recovers and seems fine. But this is probably unrelated. I saw a similar thread here, but havent had a chance to review what was said or if there was a resolution.

As to the differential slewing issue, maybe you could review it with Toni? Id love to see at least the current he has updated/published because it certainly is a huge improvement. I suspect anyone with a Paramount or 10 micron is nonfunctional at the moment. Earlier in this thread there was a 10micron user who I believe encountered the same problem but is using stellarmate.

Thanks again all!

Bryan

Richard,

your problem is exactly as I have with my paramount. Im using X86_64 linux, but the issue is the same. Your only option I think until the changes are published is to compile your own mac binary using Toni's beta source. For me there is a huge improvement. Maybe a mac maintainer can compile it for you. I was lucky that Toni is using linux x86_64 so he could just provide me a kstars binary to test.

Don't give up! Im living EKOS compared to TSX workflow. Now if there was a way to just use the mount without TSX at all!

Bryan

Thanks Bryan, I'm not intending to give up! What I've seen so far is a far more performant overall system than TSX, so I don't plan to go back.

But we'll never be able to leave TSX behind: we need it to develop and improve T-point models and to refine PEC models.

Apart from that, it can just run away in the background.

Cheers,
Richard

Hi Richard
Thanks for your report concerning the "differential slewing". It's most important to have information about this case, because It's hard to simulate the behaviour of the TPoint model of TheSkyX and alike. As you can read in this thread all began with the new rotator module I needed to integrate into the align module. By mischance I totally lost to have a sight on the "difference slewing" option. Thus there were introduced some problems regarding this feature.
But I think there are now big improvements on the way and I'm happy that Bryan is willing to assist unremitting in finding the solution. Thanks again!

Unfortunately I'm not able to compile a macOS binary. Thus the only way for you would be to compile the source code of the beta code

BTW: The best solution for a perfect integration of TSX would be a sync that doesn't break the model. In this contribution I cite a thread of Michael Fields who makes mention of a "Sync align mode (which) is for shifting/correcting an existing model" in TSX. Alas it seems there was no endeavor to follow this track.

Project "Difference Slewing" Version 15.1.2024 17:53 with more logs for Capture&Solve button and captureAndSolve() function:

• Source code on -> invent.kde.org/escriban/kstars/-/tree/DiffSlew+
• KStars binary UBUNTU 22.04 x86_64 -> invent.kde.org/escriban/kstars/-/issues/1