×

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

Bi-monthly release with minor bug fixes and improvements

Scheduler not stopping for twilight constraint

  • Posts: 33
  • Thank you received: 7
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
 
2 years 5 months ago #76183

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

  • Posts: 33
  • Thank you received: 7
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
2 years 5 months ago #76222

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

  • Posts: 1208
  • Thank you received: 559
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
Last edit: 2 years 5 months ago by Hy Murveit.
2 years 5 months ago #76226

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

  • Posts: 1208
  • Thank you received: 559
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
The following user(s) said Thank You: Jasem Mutlaq
2 years 5 months ago #76230

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

  • Posts: 437
  • Thank you received: 31
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
2 years 5 months ago #76272

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

  • Posts: 437
  • Thank you received: 31
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
Last edit: 2 years 5 months ago by Paul.
2 years 5 months ago #76274
Attachments:

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

  • Posts: 1208
  • Thank you received: 559
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

 
2 years 5 months ago #76275

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

  • Posts: 437
  • Thank you received: 31
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
2 years 5 months ago #76277

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

  • Posts: 114
  • Thank you received: 5
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. 

 
Last edit: 2 years 5 months ago by Malcolm Whinfield.
2 years 5 months ago #76279
Attachments:

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

  • Posts: 437
  • Thank you received: 31
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
Last edit: 2 years 5 months ago by Paul.
2 years 5 months ago #76341

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

  • Posts: 1208
  • Thank you received: 559
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
 
2 years 5 months ago #76342

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

  • Posts: 437
  • Thank you received: 31
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;
}
}
2 years 5 months ago #76343

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

Time to create page: 1.168 seconds