Hy,

I don't have any issue causing this, in fact it always happens.
The workaround I use is to specify a start time instead of checking twilight.
I assume it must be a setting that is the cause, but what things would have an effect on this that I can provide you with?

Paul

I am getting the same issue, I have updated all software to the latest that I am aware of. Mine is not waiting for Twilight.

Below is a test I was doing for Mosaic. Can be seen that I started with constraint and is running prior to the time. This has been a problem for about 1 to 2 months but I have been applying direct start time instead of Twilight constraint. 

 

Hy,

Can I ask at what time of the day you are doing your testing?

Forget what I asked i can see from your screen dump.

I have tested this by adjusting every setting I can find and I have not seen it work.

Paul

I run my telescope, usually starting at 8pm or so (California time) with the target rising over obstructions around 10pm), but I was testing your issue on the simulator, so I can set any time and any geography. Also, the unit test is free to pick times and geo. 

This is the kind of thing that should be replicatable using the simulator. I suppose there could be some kind of setting that causing this discrepancy. Can you try playing with the simulator, and turning on/off various settings (e.g. altitude limits, artificial horizon limits etc)?

Also, please double check that the constraint is in your scheduler file. In fact, please send me your scheduler file so I can see if for myself. It's easy to make that mistake (e.g. having the twilight restriction checked but not part of your sequence). E.g. double click on your first job in your scheduler sequence, does the twilight restriction check go away?

It would be great to get instructions on how to replicate. I know for you, it's just "start it and it fails". But for me, it works all the time.

Hy
 

Hy,

I have updated the twilight setting and saved the settings in various states numerous times and will send you the current file after I start up the Raspberry Pi with the configuration.

I have a further question about the code below - how does it know whether the mount or dome are parked when it hasn't connected to the devices?// #4 Check if we're not at dawn - dawn is still next event before dusk, and early dawn is past
if (currentJob->getEnforceTwilight() && ((Dawn < Dusk && preDawnDateTime < now) || (Dusk < Dawn)))
{
// If either mount or dome are not parked, we shutdown if we approach dawn
if (isMountParked() == false || (parkDomeCheck->isEnabled() && isDomeParked() == false))
{
// Minute is a DOUBLE value, do not use i18np
appendLogText(i18n(
"Job '%3' is now approaching astronomical twilight rise limit at %1 (%2 minutes safety margin), marking idle.",
preDawnDateTime.toString(), abs(Options::preDawnTime()), currentJob->getName()));
currentJob->setState(SchedulerJob::JOB_IDLE);
stopCurrentJobAction();
findNextJob();
return;
}
}

You're referring to this (easier to see with links--this forum seems to mangle code displays):
invent.kde.org/education/kstars/-/blob/m.../scheduler.cpp#L3717

This is inside checkJobStage() which is called every second to check on the active job (when there is an active job).
So, the mount would be connected at that point. This isn't what would run before jobs are started.

When jobs are being evaluated (and are not running) then evaluateJobs is called:
invent.kde.org/education/kstars/-/blob/m.../scheduler.cpp#L1974

so the code you're talking about is more about checking if dawn is approaching and the job should be aborted.

Hy

Hy,

I have made some progress and have found that the scheduler correctly waits if I set my location to Los Angeles, with the appropriate times zones etc.

I normally have my location set to Maribyrnong but you should try Melbourne, Australia and I believe you will then see the issue.

Paul

Very good Paul,

I too changed to Hawaii and tested it worked fine. I also changed to Singapore it worked fine as well. I made sure that both the Raspberry Pi time was changed as well. Seems to only affect Australia. May affect other countries but not tried any more.

As I created my own location data for where I live and my Associations Dark Sky location I made sure I tried Adelaide and Melbourne as they are set in default Ekos settings. Para Hills and Stockport in SA are not and I inputted them as well.
 

Paul,

Thanks very much for find this!

Indeed I was able to replicate that the scheduler started up right away in the afternoon Melbourne time, despite having a twilight restriction.
I will discuss the issue with the kstars developers.

Hy

Thanks a lot for spotting this!

Please force the timespec of the midnight date to local time in calculateDawnDusk in the Scheduler. It appears addDays switches it back to UTC.

That will fix the calculation of the next dusk and avoid the twilight restriction problem.

Thanks for the fix, Eric!
I added your code to my MR, and it's ready for review and submission.
Hy

The fix is now submitted into KStars' codebase.
If you built from the latest source, the fix should be there, or whenever a nightly build finishes
using this software (in a day or two) you can get nightly binaries that way.