didn't restart guiding after meridian flip

Sun Sep 19 08:37:45 BST 2021

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 <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 <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 <mailto: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 <mailto: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 <mailto:murveit at gmail.com>> wrote:
>>> 
>>> In this forum post
>>> https://indilib.org/forum/ekos/10389-ekos-orchestration-a-very-weird-mystery.html <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/80250f19/attachment-0001.htm>