<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Even better :-) So I will wait for the fix...<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Am 04.09.2021 um 08:16 schrieb Hy Murveit <<a href="mailto:murveit@gmail.com" class="">murveit@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Wolfgang, <div class=""><br class=""></div><div class="">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:<div class=""><br class=""><div class="">In align.cpp, <a href="https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3841" class="">https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3841</a></div><div class="">syncTargetToMount() gets triggered  <a href="https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3291" class="">https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3291</a></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Hy</div><div class=""><br class=""></div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 3, 2021 at 10:48 PM Wolfgang Reissenberger <<a href="mailto:sterne-jaeger@openfuture.de" target="_blank" class="">sterne-jaeger@openfuture.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">Had the same problem last night. I will try to find out what happens.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">Am 02.09.2021 um 19:34 schrieb Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank" class="">murveit@gmail.com</a>>:</div><br class=""><div class=""><div dir="ltr" class="">The other night I saw my image move several arc-minutes after a meridian flip.<div class="">After putting in some extra log statements and re-running last night, I traced the image issue to the following.</div><div class=""><br class=""></div><div class="">Align::syncTargetToMount()</div><div class=""><a href="https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3825" target="_blank" class="">https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3825</a><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I don't understand this code well, but<b class=""> it seems to me that this is a bug.</b> 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?</div><div class=""><br class=""></div><div class="">Hy</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div>
</div></blockquote></div><br class=""></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>