Hi 

I am running an AllSkyCam and have set up a very basic profile with just a camera (and a mount simulator) in order to capture a sequence of wide angle shots throughout every night.  In order to prevent daytime shots, I have set up a schedule that will repeat forever with twilight constraints and have tuned the offsets for dusk and dawn.  Previously I was hit with an issue that prevented kstars from running through the night (audio notifications causing file descriptor limits to be breached).  Now that is identified and eliminated, I have found the scheduler would not stop due to twilight constraints being passed at dawn.

In short I tracked down and changed this line of code in ekos/scheduler/scheduler.cpp: 

line 3718

to the prior (simpler) version which was changed on 7th July 2021.

The commit is detailed here .

This fixes the issue for me after some testing with large offsets to bring dawn closer - I'll post again if it does not work for me when running under normal operation.  I also added some logging showing the values of the variables involved in the prior check.  Does the function KStarsDateTime(preDawnDateTime) perform an important role in the logical check perhaps?  My log line was:

So I did not inspect the variable preDawnDateTime directly - I'm not set up for C++ development.

Kind Regards
Iain
 

Iain,

Interesting, my problem has been it starts immediately instead of waiting for twilight, it always seems to stop in the morning

Paul

Iain,

Good catch and diagnosing! 

I can't recall exactly why that change was put in, but I'll bet a better way to fix the issue would be to add the following to near the start of checkJobStage()
e.g right before this line:   invent.kde.org/education/kstars/-/blob/m.../scheduler.cpp#L3639 and revert your change.

    calculateDawnDusk();

If that continues to fix your issue, then I'll create an MR with that and send it to Jasem et al for approval.

Hy
 

Paul,

Can you recreate this with the simulator? Send me detailed instructions on how to reproduce and I'll take a shot at fixing it.

Hy

Paul,

Following up, when I try with the simulator (and with my live mount) it works fine.
Please send a screenshot of the simulator after you press play (similar to the below):
Hy
 

Hy 

It’s late here now but I will give that alternative fix a try tomorrow or on the weekend and let you know how it goes.

Cheers
Iain
 

Hy

Your fix looks good so far. I rebuilt with the change you suggested and it seems to work with the dusk and dawn offsets cranked right up so I can see the scheduler waiting to start, then shutting down after a short period. Also seems to work when dusk (plus offset) has already past on starting the scheduler. I'll let it run through the night for a few days and report back.

This seems like a great area for unit tests - there must be some already (I would have thought). I must admit I have not looked.

Thanks for the rapid response on this Hy.

@Paul are you sure each entry in your scheduler has twilight ticked? You might know but to get the twilight config to apply you have to double click (each line in your schedule I think), make the change (tick twilight) then click the tick that appeared when you first double clicked the schedule line. Then remember to save your schedule once all done! Once you have forgotten to do it a few hundred times it becomes natural. There are threads on this but I couldn't find them when looking just now.

Regards
Iain

Iain,

There is in fact a unit test just for this case, TestEkosSchedulerOps::testDawnShutdown(), see 
invent.kde.org/education/kstars/-/blob/m...heduler_ops.cpp#L617
Not sure why it didn't fail, or what, but I'll look into it.

I sent you a PM.
Hy

Iain,

I can't seem to get our Unit test to fail without the fix.
You say you have "a schedule that will repeat forever with twilight constraints and have tuned the offsets for dusk and dawn."
Can you please send me specific details, or even better, get this to fail in the simulator and send me details on how to reproduce in the simulator?

Thanks,
Hy

Hy,

I have just retested this using the simulators from a build of 28/09/2021 and it showed the issue.
It was the middle of the afternoon and started immediately.
The capture script was called test_11RGB_1m and it was set up to create images named test_b1g1T-15_1m.
I cannot see what your capture conditions are but one thing that is obviously different is that I have already connected to the devices when I started the scheduler, so all the tabs are shown. I know there is a setting that controls this bit I cannot remember where.
In case this has been resolved I will bring the build up to date and repeat the the test.

Paul

Hy,

I have the software up-to-date and the issue continues.

The attached image shows the scheduler after I have selected the play button - it immediately attaches the devices, slews to the target and starts focussing...

The time is around 16:30 so should have waited a number of hours - like it used to.

Paul

Paul

Paul,

There haven't been any fixes made to the code yet (though as we've seen, adding that line I sent you seems to fix it).
I was hoping I could reproduce your situation and understand what is causing the need for that line--it seems to wait for me.
I'd like to fix the root cause of the problem.

I tried to do what you suggested:
- create a job 
- connect ekos 
- start the scheduler
but the scheduler waits for twilight for me.

Can you send me step-by-step instructions on how to re-create using the scheduler?
For instance, what geography, what time, what scheduler file, what capture file, ...

If you don't connect to Ekos first, does it wait then?
Can you isolate what you're doing that causes the flaw to show itself?

Thanks,
Hy