<table><tr><td style="">wreissenberger created this revision.<br />wreissenberger added reviewers: mutlaqja, TallFurryMan.<br />Herald added a project: KDE Edu.<br />Herald added a subscriber: kde-edu.<br />wreissenberger requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D22446">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>Currently, the Scheduler is not very robust against temporary problems during an imaging session. Passing clouds might create situations, where either the Scheduler terminates or the different modules get out of sync with there state. As a result, some passing clouds can destroy an entire session.</p>

<p>This patch adds the option to control, how the Scheduler should handle aborted jobs:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">Try to restart them directly after a configurable delay.</li>
<li class="remarkup-list-item">Continue with the other scheduled jobs. As soon as no jobs are scheduled, try to restart the aborted jobs (current behaviour, but with the additional option of a configurable delay).</li>
<li class="remarkup-list-item">Do not restart aborted jobs at all.</li>
</ul>

<p>Additionally, there is an option to handle errors like aborted jobs and try to restart them. Whether selecting this option depends on the individual technical setup. In my case, I experience from time to time errors when slewing to a target. Restarting it does not create any problem at all. But it might be the case, that with other setups its dangerous to ignore an error and expose the equipment to the same error situation again and again. That's why I added this as an option.</p>

<p>Third thing that I changed is re-sorting error jobs at the end of the schedule. This only makes sense if we do not want to restart them. Otherwise, re-sorting them disturbs the intentionally set order of jobs. Therefore, I disabled this feature.</p>

<p>Last thing: there were some guiding and focusing problems that led to an error state. I changed their result to the aborted state.</p></div></div><br /><div><strong>TEST PLAN</strong><div><p>Create a schedule with several jobs and try to provoque aborts and errors:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">Aborts with guiding might be created by sending a small move signal or by setting the imaging time of the guider to a very small time.</li>
<li class="remarkup-list-item">Errors are more tricky. One option is using the debugger, setting a break point for example in setMountStatus() and jumping to a line where an error is handled.</li>
</ul></div></div><br /><div><strong>REPOSITORY</strong><div><div>R321 KStars</div></div></div><br /><div><strong>BRANCH</strong><div><div>scheduler_error_handling_01</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D22446">https://phabricator.kde.org/D22446</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>kstars/ekos/capture/capture.cpp<br />
kstars/ekos/scheduler/scheduler.cpp<br />
kstars/ekos/scheduler/scheduler.h<br />
kstars/ekos/scheduler/scheduler.ui<br />
kstars/kstars.kcfg</div></div></div><br /><div><strong>To: </strong>wreissenberger, mutlaqja, TallFurryMan<br /><strong>Cc: </strong>kde-edu, narvaez, apol<br /></div>