didn't restart guiding after meridian flip

[Hy Murveit]

Wolfgang,

Sorry I worded that poorly. I agree with you that there is no “wrong
direction”. His complaint seems to be that during the RA-out phase, the
tracked star goes in some direction, and then when it should turn around
for RA-in, instead of reversing, the star continues to move in the same
direction as it was moving when going out. You can see that on the plots.

Hy

On Sun, Sep 19, 2021 at 12:38 AM Wolfgang Reissenberger <
sterne-jaeger at openfuture.de> wrote:

> I still do not understand what is meant by „RA is going in the wrong
> direction“. For the guide calibration I thought it doesn’t matter in what
> direction it is going, since the direction will be inverted anyway and the
> task of calibration is learning the direction effect a guiding pulse will
> have.
>
> Do you understand what the problem is?
>
> Wolfgang
> --
> Wolfgang Reissenberger
> www.sterne-jaeger.de
>
> Am 18.09.2021 um 17:46 schrieb Hy Murveit <murveit at gmail.com>:
>
> 
>
> Jasem: the log spam is my fault, but it's already gone:
>
> https://invent.kde.org/education/kstars/-/commit/31eaa16abac3cd2d3e0c9986b14f7a6efae15947
>
> Wolfgang: do you think this is related? Another post-flip issue. Earlier
> on the thread he complained about the mount going in the wrong direction
> post flip
>
> https://indilib.org/forum/ekos/9640-guider-calibration-is-wrong-after-meridian-flip.html?start=24#75644
>
>
> On Sat, Sep 18, 2021 at 3:11 AM Wolfgang Reissenberger <
> sterne-jaeger at openfuture.de> wrote:
>
>> Folks, I think I have an idea where the problem lies.
>>
>> The original target has RA 22:48:14 and the mount obtains a slew command
>> to this position. When the slew completes, it should report exactly the
>> same position.
>>
>> The problem is, that it doesn’t! Instead, the slew finished at RA= "02h
>> 48m 14s“. And here the mess starts, a new meridian flip is planned and
>> started although the post-flip activities aren’t completed yet:
>>
>> [2021-09-17T00:33:51.921 EDT DEBG ][     org.kde.kstars.ekos.mount] -
>> Meridian flip planned with LST= "22h 59m 56s"  scope RA= "02h 48m 14s"  ha=
>> 8.19508 , meridian diff= 0.13 , hrstoFlip= -8.06508 , flipDelayHrs= 0 ,
>>  "Pier Side: East (pointing West)“
>>
>> *Conclusion*:
>> 1. We need to check after a meridian flip slew whether the target has
>> been reached. If we are too far off, I think aborting the capture is the
>> right reaction. With a running scheduler, it will recover.
>> 2. Align needs to listen to the mount about MF announcements and should
>> abort upon MF_STARTED or similar.
>>
>> Cheers
>> Wolfgang
>>
>>
>> Am 18.09.2021 um 09:36 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com>:
>>
>> I found several interesting things:
>>
>> 1. Why "Scheduler iteration never set up." is spammed all over the
>> log? what does it mean?
>> 2. Meridian flip is odd
>>
>> It starts here:
>>
>> [2021-09-17T00:31:46.079 EDT INFO ][     org.kde.kstars.ekos.mount] -
>> "Meridian flip slew started..."
>>
>> Finishes here:
>>
>> [2021-09-17T00:33:45.927 EDT INFO ][     org.kde.kstars.ekos.mount] -
>> "Meridian flip completed OK."
>> [2021-09-17T00:33:45.929 EDT DEBG ][     org.kde.kstars.ekos.mount] -
>> Setting meridian flip status to  "FLIP_COMPLETED"
>>
>> Post-flip alignment starts:
>>
>> [2021-09-17T00:33:46.349 EDT INFO ][   org.kde.kstars.ekos.capture] -
>> "Performing post flip re-alignment..."
>>
>> Then mount modules re-schedules another meridian flip?
>>
>> [2021-09-17T00:33:51.921 EDT DEBG ][     org.kde.kstars.ekos.mount] -
>> Meridian flip planned with LST= "22h 59m 56s"  scope RA= "02h 48m 14s"
>> ha= 8.19508 , meridian diff= 0.13 , hrstoFlip= -8.06508 ,
>> flipDelayHrs= 0 ,  "Pier Side: East (pointing West)"
>> [2021-09-17T00:33:51.921 EDT DEBG ][     org.kde.kstars.ekos.mount] -
>> Setting meridian flip status to  "FLIP_PLANNED"
>>
>> Then while alignment is running, another meridian flip is executed!
>>
>> [2021-09-17T00:33:52.156 EDT DEBG ][   org.kde.kstars.ekos.capture] -
>> Align State changed from "Complete" to "In Progress"
>> [2021-09-17T00:33:52.203 EDT INFO ][     org.kde.kstars.ekos.align] -
>> "Capturing image..."
>> [2021-09-17T00:33:52.220 EDT DEBG ][ org.kde.kstars.ekos.scheduler] -
>> Align State "In Progress"
>> [2021-09-17T00:33:52.433 EDT DEBG ][   org.kde.kstars.ekos.capture] -
>> setMeridianFlipStage:  "MF_READY"
>> [2021-09-17T00:33:52.433 EDT DEBG ][     org.kde.kstars.ekos.mount] -
>> Received capture meridianFlipStatusChange  "FLIP_ACCEPTED"
>> [2021-09-17T00:33:52.433 EDT DEBG ][     org.kde.kstars.ekos.mount] -
>> meridianFlipStatusChanged  "FLIP_ACCEPTED"
>> [2021-09-17T00:33:52.435 EDT DEBG ][ org.kde.kstars.ekos.scheduler] -
>> Scheduler iteration never set up.
>> [2021-09-17T00:33:52.923 EDT INFO ][     org.kde.kstars.ekos.mount] -
>> Meridian flip: slewing to RA= "22h 48m 14s" DEC= " 58° 14' 51\""  Hour
>> Angle  "00h 00m 47s"
>> [2021-09-17T00:33:52.923 EDT DEBG ][     org.kde.kstars.ekos.mount] -
>> Setting meridian flip status to  "FLIP_RUNNING"
>> [2021-09-17T00:33:52.924 EDT DEBG ][     org.kde.kstars.ekos.mount] -
>> meridianFlipStatusChanged  "FLIP_RUNNING"
>> [2021-09-17T00:33:52.924 EDT INFO ][     org.kde.kstars.ekos.mount] -
>> "Meridian flip started."
>> [2021-09-17T00:33:52.975 EDT DEBG ][   org.kde.kstars.ekos.capture] -
>> meridianFlipStatusChanged:  "FLIP_RUNNING"
>>
>> So this issue is about executing meridian flip twice in a row.
>>
>> --
>> Best Regards,
>> Jasem Mutlaq
>>
>> On Sat, Sep 18, 2021 at 2:57 AM Hy Murveit <murveit at gmail.com> wrote:
>>
>>
>> In this forum post
>>
>> https://indilib.org/forum/ekos/10389-ekos-orchestration-a-very-weird-mystery.html
>> The user's log seems to show that guiding was not restarted after the
>> meridian flip, even though the other procedures (slew, align, capture) were
>> restarted after the flip.
>>
>> I'd guess that's his main issue.
>>
>> Is there some known bug that might cause guiding to not get restarted
>> after a meridian flip?
>>
>> There is also some strangeness where 4 hours later the system decides to
>> re-align and does re-start guiding, but I'd guess what's happening is the
>> scheduler job completed at ~5am (it kept capturing even though guiding was
>> never started up again) and perhaps the user had the scheduler job set to
>> repeat multiple times or forever, so the scheduler restarted the job, and
>> then re-aligned properly and re-started guiding.
>>
>> Hy
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20210919/12124c57/attachment.htm>