Bug 397969

Summary: Scheduler Unpark Dome/Mount/Cap are unclear and dangerous
Product: [Applications] kstars Reporter: TallFurryMan <eric.dejouhanet>
Component: generalAssignee: Jasem Mutlaq <mutlaqja>
Status: RESOLVED MOVED    
Severity: normal    
Priority: NOR    
Version First Reported In: 2.9.8   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description TallFurryMan 2018-08-28 06:47:38 UTC 
In the Scheduler, the Unpark Dome, Unpark Mount, Unpark Cap have unclear meaning.

If the end-user checks them, Scheduler will, in order, unpark dome, then mount, then cap. This is the expected sequence, and it occurs as part of the observatory startup sequence.

If the end-user unchecks them, Scheduler will still unpark the mount when starting a job. This is also expected, and it occurs as part of the job startup sequence.

However, neither dome nor cap devices will be checked when starting a job. A major issue occurs when there is actually a cap in the setup, and it is not open when the job starts. A serious issue occurs when there is actually a dome in the setup, and it is not opened when the job starts.

One single checkbox should be used, stating that dome, mount and cap should be unparked when the observatory starts, in that order.

In the case the checkbox is not set, the state of the dome should be checked when Scheduler starts to warn the user, considering that Scheduler will be unable to open the dome. OR Scheduler should be able to control the open procedure of the dome when a job starts, like it does for the mount.

In any case, the state of the cap should be handled in the same way as the state of the mount, that is, unparked when a job starts. As stated in the forum, the cap should even be unparked after the mount finished slewing, in the case the observatory is too small to unpark the cap before that procedure.
Comment 1 Jasem Mutlaq 2018-08-28 10:28:29 UTC 
When starting a job, the startup sequence is checked for success first. So if it went fine, then all the required steps were taken. So how is it that when starting a job, the dome is not checked? It was already handled in the startup sequence.
Comment 2 TallFurryMan 2018-08-28 10:52:34 UTC 
The danger lies in the following sequence:
- start the scheduler
- scheduler starts the observatory, opens the dome
- jobs start, eventually the scheduler sleeps
- an external script or the end-user closes the dome
- scheduler wakes up and runs a job, does not proceed to open the dome

That situation is handled for the mount, there's no reason it should not be for the dome or the cap.
Comment 3 TallFurryMan 2018-08-28 10:57:35 UTC 
To clarify, the state machine of the startup sequence is not event-driven. It requests operations and considers that once they are done, they are immuable. As a result, scheduler is only looking at the state of the startup sequence from the point of view of the state machine, which may differ from the real state. 

I think the mount parking state was handled differently because of the possibility to park the mount during calibrations such as flat frames, which had to be reverted afterwards.
Comment 4 Jasem Mutlaq 2018-08-28 11:19:36 UTC 
IIRC, when the scheduler sleeps while it is active, it parks the mount only. PARK_WAIT.. if this includes parking dome, then sure when it wakes up, it would unpark dome as well.

At any rate, I don't see a problem with checking that everything is indeed in its expected state when a job is started. Unparking cap could be delayed to after slewing is complete (if job contains Light Frames).
Comment 5 TallFurryMan 2018-08-28 11:36:35 UTC 
In the original code, observatory startup and job processing are two different state machines in the same module. My guess is that we should go as far as making observatory management a separate module and tab.

If you rework the D-Bus connections extensively, I think we should envision multiple Ekos controlling the same observatory. I don't mean implement this vision right now, but keeping it in head so that asynchronous events and lock-up situations may be tackled in the architecture before they annoy us.
Comment 6 Jasem Mutlaq 2020-12-14 18:31:15 UTC 
No action was taken for this. Do you want to move it to Gitlab?
Comment 7 TallFurryMan 2020-12-14 18:45:05 UTC 
Yeah good idea, I'll open a new issue for this.