(poorly) re-setting the target

[Hy Murveit]

I was planning on addressing this in the scheduler in the next couple
weeks, e.g. by storing the target value and resetting the target when the
scheduler wants to re-align.

However, check out
https://indilib.org/forum/ekos/10399-plate-solving-changed-coordinates-of-object.html#75668
which is the same issue, however, the way Jürgen uses it, wouldn't get
fixed by storing the target in the scheduler (he isn't using the scheduler).

Honestly, I don't understand why syncTargetToMount() is being called there
(e.g. if I removed that, then Jürgen's issue as well as mine would be
fixed).

Jasem, Wolfgang: Can you please remind me again why we're calling
syncTargetToMount here?

Thanks,
Hy

On Fri, Sep 3, 2021 at 11:20 PM Wolfgang Reissenberger <
sterne-jaeger at openfuture.de> wrote:

> Even better :-) So I will wait for the fix...
>
> Am 04.09.2021 um 08:16 schrieb Hy Murveit <murveit at gmail.com>:
>
> Wolfgang,
>
> Sorry I didn't mention this earlier, but Jasem and I hashed out what the
> issue is, based on some extra logging I inserted, and Jasem is working on a
> fix.  In short:
>
> In align.cpp,
> https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3841
> syncTargetToMount() gets triggered
> https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3291
> when capture goes through a state sequence, that I believe is triggered
> when the scheduler repeats a sequence that finishes and the scheduler is in
> "Repeat Until Terminated" mode.
>
> What syncTargetToMount does is set the align target (e.g. the target that
> would be used after the next meridian flip) to the current mount's
> (internal) position instead of setting it to the target that was specified
> by the user in the scheduler job's setup.
>
> One might think those are the same things, since the mount is sync'd after
> the alignment succeeds, but if the job ran for a while, and there is some
> drift that is corrected by the guider, as the guider sends correction
> pulses, then the mount's internal position will vary from the original
> target/sync.
>
> I believe the align target should be reset to the original user-specified
> target (or the solution to the FITS file target) and not the mount's
> internal position.
>
> Hy
>
>
> On Fri, Sep 3, 2021 at 10:48 PM Wolfgang Reissenberger <
> sterne-jaeger at openfuture.de> wrote:
>
>> Had the same problem last night. I will try to find out what happens.
>>
>> Am 02.09.2021 um 19:34 schrieb Hy Murveit <murveit at gmail.com>:
>>
>> The other night I saw my image move several arc-minutes after a meridian
>> flip.
>> After putting in some extra log statements and re-running last night, I
>> traced the image issue to the following.
>>
>> Align::syncTargetToMount()
>>
>> https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3825
>> resets the target on some capture status change (which I'm assuming
>> happens because I was running with scheduler mode "Repeat until Terminated"
>> and the scheduler job completed and started its repeat, and that caused the
>> capture status change). If the target isn't used anymore, then this target
>> change is harmless, but if there's a meridian flip, then it would be used
>> again and can move the image position.
>>
>> I don't understand this code well, but* it seems to me that this is a
>> bug.* The target is set by the user in the scheduler -- e.g. a certain
>> coordinate, or the solution of a certain fits file -- and the mount has
>> nothing to do with that, at least if we're plate solving to refine the
>> position.  Is there any good reason to reset the target position in the
>> above code link?
>>
>> Hy
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20210919/1e487641/attachment-0001.htm>