scheduler issue
Wolfgang Reissenberger
wolfgang at openfuture.de
Tue Dec 8 16:00:05 GMT 2020
Makes sense to abort capture and giving the scheduler the opportunity to re-start the sequence. Retrying to calibrate would also be an option, but is a) more complicated and b) I would question whether simply repeating the procedure will lead to a different result.
> Am 08.12.2020 um 05:16 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com>:
>
> Hello all,
>
> Let me explain again what is perhaps going on. The Scheduler can not handle calibration failures UNLESS it is explicitly performing a guiding step BEFORE Capture starts.
>
> Once capture starts, the scheduler does not check or recognize at all calibration failures. Therefore, IF a calibration failure post meridian flip. This is supposed to abort the capture module, right? So why wasn't capture aborted? If capture is aborted, the scheduler can then handle this. So I think we have to look into that direction.
>
> Note: I'm sending this to kstars-devel at kde.org <mailto:kstars-devel at kde.org>, it's better to use the mailing list to discuss this since everyone subbed to it.
>
> --
> Best Regards,
> Jasem Mutlaq
>
>
>
> On Tue, Dec 8, 2020 at 12:56 AM Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>> wrote:
> Eric et al,
>
> Not clear on how this works, but the code is copied below.
> Note the emit newStatus().
> What is the state change you are referring to?
>
> FWIW, I've included the code snippet below (pretty complicated code to follow--there's a state machine in guide.cpp -- I guess that's either controlling the internal guider or PHD2), and there's a calibration state machine in internalguider.cpp. From what I can tell, I don't think it's the issue you described, but I'm not too familiar with these state machines, nor the scheduler.
>
> Hy
>
>
> From internalguider.cpp, line 505
> void InternalGuider::processCalibration()
> {
> pmath->performProcessing();
>
> if (pmath->isStarLost())
> {
> emit newLog(i18n("Lost track of the guide star. Try increasing the square size or reducing pulse duration."));
> reset();
>
> calibrationStage = CAL_ERROR;
> emit newStatus(Ekos::GUIDE_CALIBRATION_ERROR);
> emit calibrationUpdate(GuideInterface::CALIBRATION_MESSAGE_ONLY, i18n("Calibration Failed: Lost guide star."));
> return;
> }
> ...
>
> From internalguider.cpp, line 542
> void InternalGuider::reset()
> {
> state = GUIDE_IDLE;
> //calibrationStage = CAL_IDLE;
> connect(guideFrame, SIGNAL(trackingStarSelected(int, int)), this, SLOT(trackingStarSelected(int, int)),
> Qt::UniqueConnection);
> }
>
> guide.cpp:2381
> connect(guider, &Ekos::GuideInterface::newStatus, this, &Ekos::Guide::setStatus);
>
> guide.cpp:1935
> void Guide::setStatus(Ekos::GuideState newState)
> {
> if (newState == state)
> {
> // pass through the aborted state
> if (newState == GUIDE_ABORTED)
> emit newStatus(state);
> return;
> }
>
> GuideState previousState = state;
>
> state = newState;
> emit newStatus(state);
>
> switch (state)
> {
> ...
>
> case GUIDE_IDLE:
> case GUIDE_CALIBRATION_ERROR:
> setBusy(false);
> manualDitherB->setEnabled(false);
> break;
>
>
> On Mon, Dec 7, 2020 at 12:31 PM Eric Dejouhanet <eric.dejouhanet at gmail.com <mailto:eric.dejouhanet at gmail.com>> wrote:
> Could it be that the emission of the guide failure is done before Guide's state is changed? That was the case for Focus, and Scheduler's immediate reaction for a new autofocus was thus rejected.
>
> Unfortunately I haven't had time to check the log yet.
> eric.dejouhanet at gmail.com <mailto:eric.dejouhanet at gmail.com> - https://astronomy.dejouha.net <https://astronomy.dejouha.net/>
> De: murveit at gmail.com <mailto:murveit at gmail.com>
> Envoyé: 7 décembre 2020 21:04
> À: mutlaqja at ikarustech.com <mailto:mutlaqja at ikarustech.com>
> Répondre à: hy at murveit.com <mailto:hy at murveit.com>
> Cc: hy at murveit.com <mailto:hy at murveit.com>; sterne-jaeger at t-online.de <mailto:sterne-jaeger at t-online.de>; eric.dejouhanet at gmail.com <mailto:eric.dejouhanet at gmail.com>
> Objet: Re: scheduler issue
>
> It was indeed after a meridian flip.
> Jo also sent the .analyze file to me (attached) and here's a zoom'ed in screen shot from the time of the issue.
>
>
>
> Hy
>
> On Mon, Dec 7, 2020 at 11:43 AM Jasem Mutlaq <mutlaqja at ikarustech.com <mailto:mutlaqja at ikarustech.com>> wrote:
> Hello Hy,
>
> Do you know why it was calibrating? this wasn't after a meridian flip correct? What's happening is that scheduler handles calibration failures IF it was in the steps..i.e.
>
> Track --> Focus --> Align --> Guide --> Capture. If at "Guide" calibration fails then it handles that. Right now, after capturing, the scheduler just LOGS the guide calibration results but does not handle them. Capture module should have been aborted if calibration fails, and then that would have been handled by the scheduler... but again, what would cause calibration in the middle of capture? meridian flip?
>
> --
> Best Regards,
> Jasem Mutlaq
>
>
>
> On Sun, Dec 6, 2020 at 11:30 PM Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>> wrote:
> Eric, Jasem,
>
> Reporting a possible scheduler bug.
>
> Jo (@ElCorazon) sent me a log
> https://www.dropbox.com/s/n8icvn90fhunjfl/log_20-53-07.txt.gz?dl=0 <https://www.dropbox.com/s/n8icvn90fhunjfl/log_20-53-07.txt.gz?dl=0>
> which I analyzed and my conclusion is that star detection caused guider calibration to fail at 01:15:54 (see below)
>
> [2020-12-05T01:15:54.614 CST INFO ][ org.kde.kstars.ekos.guide <http://org.kde.kstars.ekos.guide/>] - "Lost track of the guide star. Try increasing the square size or reducing pulse duration."
> [2020-12-05T01:15:54.617 CST DEBG ][ org.kde.kstars.ekos.capture <http://org.kde.kstars.ekos.capture/>] - Guiding state changed from "Calibrating" to "Calibration error"
>
> and (ignoring that issue) the scheduler recognized, I suppose, that guider failed
>
> [2020-12-05T01:15:54.624 CST DEBG ][ org.kde.kstars.ekos.scheduler <http://org.kde.kstars.ekos.scheduler/>] - Guide State "Calibration error"
>
> but the scheduler didn't seem to restart the guiding calibration. Basically nothing happens until 1:57:56 when I assume Jo restarted things.
>
> [2020-12-05T01:57:56.852 CST INFO ][ org.kde.kstars.ekos.scheduler <http://org.kde.kstars.ekos.scheduler/>] - Scheduler is stopping...
>
> I assume the scheduler should try and restart the guider, but there are no .guide nor .scheduler messages between 1:15:54 and 1:57:56
>
> Hy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201208/40c339b2/attachment-0001.htm>
More information about the Kstars-devel
mailing list