×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Potential bug in the Scheduler: mount doesn't get parked when guiding aborted

  • Posts: 1957
  • Thank you received: 420
Last night I set up one of my imaging setups and started a long job (with different filters) on M 27. Yes it is full moon but that doesn't stop me from testing my gear. Anyway, at some point M 27 disappeared behind my home and the guide cam failed to acquire a star to guide on. This aborted the Scheduler job (and basically meant I got 0 images with one of the five filters but that was to be expected). When I got up this morning I noticed that the mount had not been parked despite the condition for it (dawn had started) already passed.

I'll check the logs tonight when I get home from work but I wanted to open this post here in case anyone else has encountered a similar situation.


Wouter
4 years 9 months ago #41030

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
Here are the logs. At 06:17:09 the Scheduler reports that the guider state is "Idle". However, it must be something else. The scheduled jobs were support to end around 05:00 but they didn't... Around 04:27 the scheduler is aborting the last job and then it doesn't park the mount. See the attached log and esq files.
The following user(s) said Thank You: Derek
4 years 9 months ago #41052
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
Taking a closer look into the logs explains what happens:
[2019-07-15T04:27:02.108 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Only aborted jobs left in the scheduler queue, rescheduling those."
...
[2019-07-15T04:27:01.043 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'M 27' is now approaching astronomical twilight rise limit at Mon Jul 15 04:27:00 2019 (30 minutes safety margin), marking aborted."
[2019-07-15T04:27:03.044 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Sleeping until observation job M 27 is ready at Mon Jul 15 23:45:00 2019..."
[2019-07-15T04:27:03.052 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Warning: Job 'M 27' is 19h 17m 57s away from now, you may want to enable Preemptive Shutdown."
Briefly: enable "Preemptive Shutdown" in the EKOS/Scheduler options.

This is exactly a situation that Eric ( @TallFurryMan ) and I are discussing in this enhancement I am working on. From my perspective, setting a job that hits its limits to state "aborted" is not optimal. But there are good arguments to do it, if you want to implement multi-day schedules.

What happens? As soon as all jobs are completed or aborted, the Sceduler re-schedules all aborted jobs. In your case, the M27 job is sent to sleep until next evening.

- Wolfgang
The following user(s) said Thank You: Eric
4 years 9 months ago #41097

Please Log in or Create an account to join the conversation.

Shouldn't such jobs trigger PARK-WAIT stage and park the mount? That was how it was intended, so why is park wait skipped now?
4 years 9 months ago #41098

Please Log in or Create an account to join the conversation.

  • Posts: 456
  • Thank you received: 76
I would prefer the old behavior where if dawn approached then it initiates the shutdown
4 years 9 months ago #41104

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
As the log shows, the Preemptive Shutdown option is not selected.

@Wouter: Please select the option, then you will have the desired behavior.
The following user(s) said Thank You: Derek, Wouter van Reeven
4 years 9 months ago #41105

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
OK I didn't expect that that was necessary since I did check the Park Mount option in the Scheduler. I guess this means that the Park Mount option only is executed once all jobs have finished which seems counter-intuitive to me. But I'll make sure that that option is also checked next time. Thanks!
4 years 9 months ago #41118

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
Scheduler will try (hopefully) hard to image your targets, even if that means scheduling observations over multiple nights. So yes, preemptive shutdown is the solution. Do you think it is a misnomer and we should fix that? There's also a warning in the scheduler, but that warning does only appear when the sleep situation occurs, so not very helpful.

-Eric
The following user(s) said Thank You: Wouter van Reeven
4 years 9 months ago #41167

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
Also I think we should enforce the completion time of scheduled jobs. If a job gets late, it should be allowed to continue for some time, but at some point we should abort it. That indeed poses the question of when to resume it, and that is one of the points in the exchange mentioned.

-Eric
4 years 9 months ago #41168

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420

No, I don't think it's a misnomer. Despite my extensive use of Ekos I still get confused when certain configuration options are in the screen itself, some are in the KStars preferences and some are hidden away in a popup that can be accessed by going to the corresponding tab in Ekos and clicking on an Options button. Perhaps the Ekos configuration options in the KStars preferences should be taken away from there and merged into Ekos, either by adding popup accessible via an Options button or modifying an existing popup. Then at least all configuration options are directly accessible from within Ekos.

Anyway, if I encounter an unexpected situation again then I will go over all configuration settings (including the ones in the KStars preferences) to see if any may solve the situation.


Wouter
The following user(s) said Thank You: Eric
4 years 9 months ago #41170

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
Thanks, your report is helpful.

-Eric
The following user(s) said Thank You: Wouter van Reeven
4 years 9 months ago #41196

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
And thank all of you for your continuing efforts to improve this already very fine piece of software!


Wouter
The following user(s) said Thank You: Jasem Mutlaq
4 years 9 months ago #41198

Please Log in or Create an account to join the conversation.

Time to create page: 0.371 seconds