https://bugs.kde.org/show_bug.cgi?id=527911
Bug ID: 527911
Summary: Ekos meridian flip stalls indefinitely when mount
stops tracking before flip execution
Classification: Applications
Product: kstars
Version First git
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
SUMMARY
Ekos can remain indefinitely in the meridian-flip “ready to start” state if the
mount stops tracking before the flip command is issued.
OBSERVED BEHAVIOR
During an imaging session:
1. Capture was exposing normally.
2. Ekos planned a meridian flip while an exposure was still running.
3. Before Capture handed control to the flip state machine, the mount changed
from Tracking to Idle/stopped.
4. The exposure completed and Capture reported that the meridian flip was ready
to start.
5. Ekos then logged the equivalent of:
`No meridian flip: mount not tracking, current state: Idle`
every second.
6. The flip state did not transition to completed or error.
7. Capture did not resume, and the session remained stalled until shutdown.
The recovered log does not conclusively establish why the mount stopped. It may
have reached a controller tracking limit, or another STOP source may have
existed. This report concerns the indefinite Ekos wait after the stopped state
was already known, not the historical cause of the stop.
CODE-PATH OBSERVATION
Once Capture has accepted the flip, Ekos repeatedly calls
`MeridianFlipState::startMeridianFlip()`. When the mount is not tracking, that
function returns without advancing the flip to either execution or an error
state. Capture’s ordinary timeout is disabled while the meridian flip is
active, leaving no apparent path out of the wait.
Hans Lambermont independently analyzed the recovered log and noted that the
same logic remains in KStars master. The condition is not specific to 10Micron;
it may affect other mounts configured to stop at the meridian.
EXPECTED BEHAVIOR
Ekos must not wait indefinitely.
If the mount is already stopped when the flip becomes ready, Ekos should
either:
- enter a clearly bounded and safe recovery path; or
- transition the flip and Capture workflow to an explicit error requiring
operator action.
It should not repeatedly return once per second while leaving Capture’s timeout
disabled.
SAFETY NOTE
This report does not assume that issuing a flip while stopped is universally
safe. Failing explicitly is preferable to automatically commanding motion when
the driver cannot establish that motion is permitted.
REPRODUCTION OUTLINE
1. Begin a Scheduler/Capture job with meridian-flip handling enabled.
2. Allow Ekos to plan a flip while an exposure remains active.
3. Cause or simulate the mount transitioning from Tracking to Idle before
Capture hands control to the flip.
4. Allow the current exposure to complete.
5. Observe that Ekos declares the flip ready but repeatedly refuses to start it
because the mount is not tracking.
6. Observe that no terminal error or Capture timeout occurs.
RELATED WORK
KStars MR !1852 adds controller-authoritative planning and correlated
execution, but this stopped-at-handoff deadlock is an independent generic Ekos
defect:
https://invent.kde.org/education/kstars/-/merge_requests/1852
The originating INDI discussion and log analysis are here:
https://github.com/indilib/indi-3rdparty/pull/1404#issuecomment-6428351445
--
You are receiving this mail because:
You are watching all bug changes.
