scheduler issue
Jasem Mutlaq
mutlaqja at ikarustech.com
Tue Dec 8 04:16:58 GMT 2020
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, 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> 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>
> 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 - https://astronomy.dejouha.net
>> *De:* murveit at gmail.com
>> *Envoyé:* 7 décembre 2020 21:04
>> *À:* mutlaqja at ikarustech.com
>> *Répondre à:* hy at murveit.com
>> *Cc:* hy at murveit.com; sterne-jaeger at t-online.de;
>> 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.
>>
>> [image: Screen Shot 2020-12-07 at 12.02.19 PM.png]
>>
>> Hy
>>
>> On Mon, Dec 7, 2020 at 11:43 AM Jasem Mutlaq <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> 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
>>>> 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] -
>>>> "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] -
>>>> 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] -
>>>> 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] -
>>>> 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/9a51326d/attachment.htm>
More information about the Kstars-devel
mailing list