Been using the scheduler a lot recently and think it's robust - thanks! I nearly had a flawless imaging session last night across the entire astro dark time with the Scheduler managing two jobs, one with a priority and contraint - worked really good! I was especially impressed with the Artificial Horizon feature. My priority job target needed to clear the artificial horizon so the secondary job ran until the primary target was ready. Once primary target was in view, it stopped working on secondary job, ran the primary job to completion, and then went back and finished what it could on the secondary job until dawn - beautiful! ALMOST flawless - I've ran into a couple of issues and questions:

• Incorporation of Flats
What's the suggest method of incorporating flats in the Scheduler? I've been including them in the capture sequence and this appears to work fine in a single sequence, managing the FlipFlat cover and light. The issue arises when a job finishes with a sequence of flats and then the Scheduler initiates the next job. The mount will slew to the new target and initiate an autofocus - which fails because the cover is still closed and flat light is on. Scheduler continues to try to focus with no stars detected over and over until I wake up and correct it manually. I could add a script to OPEN the cover (which also turns off the light) to the last flat job in the sequence, but this seems odd. Is there a way for the Focus and Align modules to check status of the cap and open it before an exposure - similar to they way that the CCD Module does when it performs this check for a Light frame or a Flat frame? Focus and Align exposures always need the cap open.


• Flats and Guiding
I use the external PHD2 guiding in my profile - works great! There's an option to suspend guiding during a focus routine. I think we need the same logic for a flats job/sequence because the cover is closed and the light is on (hopefully) and PHD2 complains about it and makes noise. I don't care if the mount is tracking during flats, but there's no reason to attempt to guide. Does the internal guider know not to try to guide when generating flats?


• Manual Edits
Sometimes (like the scenario above!) I need to stop the greedy (!) Scheduler to make a correction to the sequence or maybe the job itself. If I'm just running a normal sequence without the Scheduler, I simply hit the STOP button for the sequence, make my edits, and hit the PLAY button - works great. This becomes a real challenge when the Scheduler's Aborted Job Management continually restarts things! Sometimes I'm able to click the "None" radio button there and it will allow me to quickly abort the capture and make changes and go back to "Queue" or "Immediate", but other times I have to stop or pause the Scheduler entirely. Also, unless I save off the changes to the original capture sequence file, the Scheduler loads up the old one with the mistake on restart of the job anyway. Two questions: What's the easiest way to make changes to the Scheduler job or capture sequence when the Scheduler is running, and secondly, what's the difference between STOPPING and PAUSING the Scheduler?

I run KStars/Ekos on an onboard Ubuntu mini computer and it really works great for me. As mentioned, nearly flawless last night - keep up the great work!

Another question regarding the Scheduler and profiles with PHD2. Do I need to have the PHD2 application up and running and connected to devices? Or, will the Scheduler's Observatory Startup Procedure handle all of that? Some of that?

Shooting flats is best when you do it as last job. This way you avoid the problems you describe with opening the cover. Alternatively, you could add a script to the flats job that opens the cover as last step.

Editing files while running the scheduler isn’t a good idea. If something needs to be changed, stop the scheduler (not capture), edit and restart.

PHD2 needs to be started separately. If it is running when you connect KStars/EKOS to the devices, PHD2 will automatically connect to the selected profile as well.

The reason I include flats in the capture sequence is to pick up the last focus position of each filter and because I have a rotator. This is important when the scheduler has multiple targets. It need to capture the flats with the same PA as the target. Seems easier for the focus and align modules to check for cap/light like the capture module does.

I have scripts to manage the cap/light and they work well. The problem with that solution is that I don't know when/where the Scheduler is going to suspend the job and move to the next highest priority job. If it does it in the middle of the second flat sequence (shooting NB), the script at the end of the three flat captures won't fire.

OK, understood.

Then the question is how to avoid that the greedy scheduler gives another job the preference before flat capturing has been completed. This could only be the case if the flats job has constraints that are no longer met. If you select a circumpolar position for the flats and no other limits, it will be always executable.

Does that make sense?

Otherwise you could use the newly added option to disable greediness of the scheduler (see scheduler options). If you uncheck this option, the scheduler will strictly follow the sequence of jobs you have configured. But use this with caution, it could happen that not the entire night is used for capturing.

HTH
Wolfgang

I'm using Stable 3.6.7 and don't see the "disable greediness" option. Will that work it's way into the Stable version soon?

Also, I was looking into using the Scheduler's "Group" feature and two jobs - one for the Light frames and another for the Flats - but mark them in the same group. I don't think this will solve it though, because the greedy scheduler could punch out of either job in the group at any time.

I think I have to have the non-greedy Scheduler to just run the jobs sequentially for now and request a feature to add the cap/light check into the focus and align modules.

The scheduler option is brand new and is part of 3.6.8 - so either wait or take a nightly build.

The group feature won't solve it. Grouping means that the group will be iterated as group and not sequentially.

Any estimate on 3.6.8 Stable?

around 01.12.23

I see Jasem has the v3.6.8 Stable committed and built. When should I expect to see 3.6.8 show up in an apt-get update?
**EDIT** Nevermind, I see it's out now.