Any good news on this topic ?.

I did add something several weeks ago
invent.kde.org/education/kstars/-/merge_requests/221
just after 3.5.2 was completed (i.e. will be released in 3.5.3) which should make the guider a little more robust to losing the guide star.
This is something along the lines of what I described above.
Still, if a cloud comes by and obscures the image for several guiding cycles, guiding will fail.
In that scenario, the scheduler needs to come to the rescue, and I trust Wolfgang and Eric's wisdom on those issues.

Hy

Maybe add option that if there was no guiding for 5-10 min trigger align?

My temporary solution is to use CCDciel instead of Ekos.

What if we just run plate solver on each exposed frame and queue realign on next frame if we drift too much from target?

This thread is still in the pipe for Scheduler changes, but unfortunately don't expect a quick update to the code here. We still have things to fix in CI prior to this.

-Eric

So far, the Capture module has satisfied my needs, so I'm a total noob with the scheduler. We are apparently in store for a few passing bands of clouds tonight, so I'd like to give this a go.

Let's say I want to capture a single target for the whole night. I set a capture sequence of 45x60", and put it on "Repeat until terminated" or "until time" and set time for a bit after dawn twilight. In order to get recovery if guiding is lost from clouds, does it make sense to use "Re-schedule errors" with a wait of something like 5 minutes?
When it tries to restart, will it re-focus, then align, then restart guiding or does that full process only happen if it has completed the full 45 exposures?

Definitely, that's exactly the intention behind this feature. I have it set to 2 minutes.There are two types of restarts. If guiding fails, the scheduler tries to restart a couple of times. Only if this fails, it aborts the job. Now the restart feature steps in. If an aborted schedule job is restarted, the starting procedure with focus, align, etc is executed.

I personally do not use initial focusing but use the "refocus after ..." feature of the capture module. When there are problems with clouds etc., it could happen that a job is restarted and focusing fails. Then it could happen that the focus is so off limits that the next focus attempt will fail. For me it seems a robuster strategy focusing after a certain period of time and not at the beginning. At the beginning of a night, I start focusing manually.

HTH
Wolfgang

Thanks, Wolfgang. That makes sense (assuming the "focus-after" timer does not get reset to 0 when the scheduler restarts the job).

No, the scheduler doesn't reset the counter, this is a focuser attribute. And btw, there is also an option to re-align before each job start. This is helpful for those situations where you have a job with the repeat n times or repeat until options set. In this case, for each job repetition, an alignment is triggered first.

Thanks. That is very "Ekos" - a parameter housed in the Focus module, set in the Capture module, and has a sort-of equivalent in the Scheduler module

I did set Align in the 'Steps' section, as losing guiding would result in the target wandering a bit. In the end last night guiding never failed completely - I woke up at 3:00 and PHD2 was hanging on to one last star, trying its best to maintain some semblance of guiding. It looked like clouds from then on, rather than just some passing, so I shut down.

We all in IT business love the explanation of "this has historical reasons"  We already have ideas in mind for a better orchestration, but refactoring is not that easy. But good point though ...