×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

"Queue" option in Scheduler

  • Posts: 1119
  • Thank you received: 182
Quick question: Since one of the recent KStars updates, there is now a Queue option in the Scheduler that handles what to do with aborted jobs. Nothing, Queue, Reschedule. I figured by selecting Queue any aborted job (e.g. when the target travels below the altitude cut-off limit) would be put back into the Schedule to be reevaluated with all other jobs by altitude.

However, when I was imaging IC 1848 (job 1) last night, it met its altitude cut-off a few exposures shy of the total programmed exposure number. The next job in the list (job 2) was the Horsehead Nebula. That was well within altitude at the time job 1 aborted, but was not initiated. Instead, the scheduler went to sleep and rescheduled execution for the next night.

In order to avoid that, I gather I can select the None version of how to handle aborted jobs, but I was wondering whether this is the way the Queue option is supposed to work. Intuitively, I would have thought that it would just put the aborted job back in line and queue it for execution at the end of the schedule, instead of putting it back in front and thus halting execution of the entire list for the rest of the night.
4 years 4 months ago #45948

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

  • Posts: 1185
  • Thank you received: 370
Hm, this behaviour is independent of the option you select for aborted jobs, since a job is set to IDLE when it hits a constraint and is not aborted. But when this happens, it will be re-evaluated again and sent to sleep until the constraint is met again. As a result, it covers all other entries below - which I guess is not the intention here.

For me the question is, whether scheduling works right when sorting by altitude is selected (which I never use). Should the scheduler jump to the first job in the list that meets its constraints or should it postpone all until the first in the row that is not complete meets its constraints (as it currently does)?

For such situations, I use a fixed order and set termination times. Interestingly, in such cases the scheduler behaves different. If the termination time of the first job has passed, the job is set to IDLE and the next in the row is scheduled.

Let's call it a bug... Yes, another strike of our spaghetti code monster (aka scheduler.cpp)

Wolfgang
The following user(s) said Thank You: Jose Corazon
4 years 4 months ago #45954

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

  • Posts: 1119
  • Thank you received: 182
Another "bug" seems to have crept back into the scheduler. Unfortunately, as I discovered last night, the logs were disabled by default in the nightly 3.3.8 Kstars version I was using last night. However, this has happened several times before, so Jasem probably knows how to fix it in a snap:

I programmed the scheduler last night, as you lined out above, using a fixed termination time for sequence 1 and a fixed start time, 5 min later, for sequence 2. That worked fine, as expected, sequence 2, i.e. Horsehead Nebula, started tracking aligning and exposing OK. Fortunately I woke up 22 exposures into that second sequence and quickly checked on progress. That's when it became clear that all 22 exposures were unusable as the guide module lost its guide star in ~ 10 s intervals. That also resulted in the image shifting out of center.



The reason most likely is that during the execution of sequence 1 a meridian flip occurred and the guide calibration was merely swapped instead of "recalibration forced upon pier side change". That swapped guide calibration was not reversed when sequence 2 started and the mount switched back to the other side of the meridian.

So, it looks to me that during one of the last updates the previously mandatory guiding recalibration upon pier side change was dropped. It would be great to have that option back in in the scheduler tab in Ekos.

It takes little time to recalibrate the guide module after a flip, but failure to do, as in this case, can easily ruin the image acquisition for the rest of the night.

Can this option be put back in, again, please?

Preferably, the 'calibration swap' routine could be taken out entirely, then this can't happen in the first place.
Last edit: 4 years 4 months ago by Jose Corazon.
4 years 4 months ago #45972
Attachments:

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

  • Posts: 1185
  • Thank you received: 370
The option "Always Reset Guide Calibration" is still present under the Scheduler options. Maybe you haven't set the option.

In addition, I would recommend setting a guiding limit in the Capture module so that at least capturing restarts when guiding fails.

HTH
Wolfgang
4 years 4 months ago #46044

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

  • Posts: 1119
  • Thank you received: 182

Hi Wolfgang;

Thanks for the suggestions!

The Always Reset Guide Calibration Option is set, I can guarantee that, since I watch that like a hawk every time I start a sequence for that precise reason. Nonetheless, when the second sequence was exposing, the Swap box was ticked in the Guide module, so it seems to me that Ekos ignored the Reset command. That has only occurred again recently.

It would be great if there were an option in Ekos where one can activate calibration swap, with the Default being no calibration swap, just if someone absolutely feels like they want to save 60 s of recalibration. I always prefer to recalibrate, though, just makes guiding much more stable. Sometimes a mount is not perfectly balanced (especially with the iOptron Smart EQ Pro+ that is almost impossible to achieve, too much friction in the mount), so after a flip recalibrating helps even out these imbalances, I think.

As for the guiding limit: Restarting capturing was not the problem, in fact, all the frames were captured, they all just looked like the one I posted. If I set the guiding limit, then there will be fewer frames I have to visually sort out later, true, but in this case, I would have missed the fact that guiding was consistently using the wrong calibration data for all frames that were exposed. Looking at the individual frames I could see that with one glance, and without the need to study reams of log files.

Unfortunately, it is cloudy now for a few days, so it will take some time until I can reproduce the problem, this time with the logs turned on.

HG, Jo
Last edit: 4 years 4 months ago by Jose Corazon.
4 years 4 months ago #46046

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

  • Posts: 1185
  • Thank you received: 370
If the option was set, the meridian flip would have triggered a re-calibration. I just tested it with simulators and PHD2 and everything went as expected. After the completion of the meridian flip, PHD2 re-calibrated.

Logs available? Sorry, just saw, that logs are not available.
Last edit: 4 years 4 months ago by Wolfgang Reissenberger.
4 years 4 months ago #46047

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

  • Posts: 1119
  • Thank you received: 182
Hi Wolfgang,

I don't know whether you tested two sequential targets in the simulator. If you only tested ONE target, you would not have seen the problem.

Sequence for target 1 was processed fine, no star trails after the meridian flip. So sequence 1 completed flawlessly. Whether recalibration occurred or whether calibration swap was activated, I don't know. Swap in that case would not have produced the problem.

The problem came with sequence 2, which was started 5 min AFTER sequence 1 was terminated as scheduled in the timer (as per your earlier suggestion). When sequence 2 was activated, the mount moved BACK across the meridian (moving from the east to the west side of pier) to start imaging target 2 on the eastern side of the meridian. THAT was when I saw swap enabled and all images had star trails. In other words, moving BACK across the meridian apparently did not trigger recalibration, moving FORWARD across the meridian very well might have.

If you can simulate that sequence of events in the simulator, you may be able to find the problem.

This is a real life practical issue for the scheduler, since most of the time one wants to use that to image 2 targets in one night, with the second target coming up in the East as the first target is setting in the West. So recalibrating when the mount swings back across the meridian becomes paramount (pun fully intended).

:-)

Jo
Last edit: 4 years 4 months ago by Jose Corazon.
4 years 4 months ago #46048

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

  • Posts: 1185
  • Thank you received: 370
Let’s continue the calibration topic here
4 years 4 months ago #46092

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

Time to create page: 0.287 seconds