Wolfgang Reissenberger replied to the topic 'Re:Autofocuss failure stops meridian flip' in the forum. 7 hours 40 minutes ago

James, please be so kind and post the logspost the logs . Currently, I cannot explain why this happens.

Read More...

Wolfgang Reissenberger replied to the topic 'Re:Autofocuss failure stops meridian flip' in the forum. 16 hours 12 minutes ago

Currently, re-focussing is part of imaging. That‘s why this case slipped through. But you will get the option enabling a forced meridian flip. In your case I would recommend not selecting it.

Read More...

Wolfgang Reissenberger replied to the topic 'Re:Autofocuss failure stops meridian flip' in the forum. 21 hours 20 minutes ago

I am in favour of the last option you mentioned. I would add a configurable timeout to the mount tab and an option to enforce a meridian flip after a certain delay. With this we leave it to the user whether a meridian flip might be executed even at the price of lost images.

Read More...

Wolfgang Reissenberger replied to the topic 'Autofocuss failure stops meridian flip' in the forum. yesterday

Could you please post the logs?

Read More...

As the log shows, the Preemptive Shutdown option is not selected.

@Wouter: Please select the option, then you will have the desired behavior.

Read More...

Taking a closer look into the logs explains what happens:

[2019-07-15T04:27:02.108 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Only aborted jobs left in the scheduler queue, rescheduling those."
...
[2019-07-15T04:27:01.043 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'M 27' is now approaching astronomical twilight rise limit at Mon Jul 15 04:27:00 2019 (30 minutes safety margin), marking aborted."
[2019-07-15T04:27:03.044 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Sleeping until observation job M 27 is ready at Mon Jul 15 23:45:00 2019..."
[2019-07-15T04:27:03.052 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Warning: Job 'M 27' is 19h 17m 57s away from now, you may want to enable Preemptive Shutdown."
Briefly: enable "Preemptive Shutdown" in the EKOS/Scheduler options.

This is exactly a situation that Eric ( @TallFurryMan ) and I are discussing in this enhancement I am working on. From my perspective, setting a job that hits its limits to state "aborted" is not optimal. But there are good arguments to do it, if you want to implement multi-day schedules.

What happens? As soon as all jobs are completed or aborted, the Sceduler re-schedules all aborted jobs. In your case, the M27 job is sent to sleep until next evening.

- Wolfgang

Read More...

Wolfgang Reissenberger replied to the topic 'Default Parking Time' in the forum. 2 days ago

What about selecting the parking option of the Scheduler? As soon as your scheduler jobs are through, the mount will park.

Read More...

Wolfgang Reissenberger replied to the topic 'Re:Blocking pop-ups for darks and flats' in the forum. 2 days ago

I would opt for a timeout - maybe configurable somewhere - for all popups. We work intensively in making KStars a tool for observatory automation. In an automated world, popups requiring manual interaction do not make sense.

- Wolfgang

Read More...

Wolfgang Reissenberger replied to the topic 'Job sequencer / auto guide problems' in the forum. 4 days ago

Feel free to submit a patch - helping hands always appreciated.

Read More...

Wolfgang Reissenberger replied to the topic 'Job sequencer / auto guide problems' in the forum. 4 days ago

Is PHD2 configured to abort when the mount moves? This needs to be configured, kstars does not abort guiding when slewing. If you are not using pulse guiding, it might be the case that you need to set your mount as aux mount in PHD2 so that it recognizes slewing.

Wolfgang

Read More...

Wolfgang Reissenberger replied to the topic 'New Scheduler Iteration' in the forum. 4 days ago

Many thanks Eric for bringing the Scheduler ahead!

Each Ekos module should receive serialization support for its settings. ... With these serialized settings, Ekos modules should communicate with a simplified d-bus interface.

Very good point! We need to find a balance what is controlled by the Scheduler and what remains under control of other modules. We would end up in a configuration hell if we reflect all single controls of other modules in the Scheduler.

Supported by the settings presented in the previous section, Scheduler should improve its control facilities and provide an interface summarizing the entire configuration of the observation session. The full observation plan would be a list of target observations, themselves a list of steps to execute, embedding the serialized settings of the Ekos modules.

Much appreciated! The current list based view has reached its limits. With a tree based view we could show more details without losing the overview.

We should also discuss the possibility of integrating new features to Ekos using runtime flags. A special option pane would be used to enable or disable in-development features, in order for willing users to try them out before they are integrated to the application workflow. The new interface of Scheduler would be a good candidate, as it would force the development to proceed in non-breaking iterations.

YES! The current approach with one master and nightly builds is great for adding small increments. But redesigns like this one simply need time to reach their maturity.


As already offered: happy to participate!

Wolfgang

Read More...