Meridian flips are also initiated if a sequence has only one single frame captured. This resolves bug #400265
Details
- Create a sequence with one single light frame and select "Meridian flip if HA > xx".
- Create a schedule with a target close before meridian using the sequence above that repeats the sequence endlessly.
- Start the schedule.
Expected result: as soon as the meridian is passed, a meridian flip is executed. After a successful meridian flip, capturing is continued.
Diff Detail
- Branch
- EKOS/meridian_flip
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 5399 Build 5417: arc lint + arc unit
kstars/ekos/capture/capture.cpp | ||
---|---|---|
3010 | Is there any action that needs to be taken here? Shouldn't this abort capture? I understand the decision is pushed to caller, but the management code is missing. | |
4048 | Agreed, this is the core of the change. | |
4189–4190 | Missing management of bool return code. | |
4686 | Test against nullptr? | |
kstars/ekos/mount/mount.cpp | ||
835 ↗ | (On Diff #46222) | I'm not sure this is correct : hours are reduced to [0,24[, so you need proper sign management to handle rising/setting limit. But I didn't redo the maths. Took some hair in D16429... |
840 ↗ | (On Diff #46222) | Missing management of return code. |
kstars/ekos/capture/capture.cpp | ||
---|---|---|
3010 | I tend to simply reply "false" in case of a DBus error, i.e. meridian flip has not been executed. This is not super elegant, I know, but from a DBus error I guess there is no option of recovery. And simply issuing a shutdown seems too harsh to me. | |
kstars/ekos/mount/mount.cpp | ||
835 ↗ | (On Diff #46222) | Well, maybe, but this is the original code. At least now it is more or less properly encapsulated. I tend to leave it as is. |
kstars/ekos/capture/capture.cpp | ||
---|---|---|
3010 | If you're not aborting, what are the consequences? Either mount is lost, and we'd better stop the procedure, or mount will continue tracking. In that situation we'd better tell the caller, be it end-user of scheduler, that something cannot be done. Scheduler is able to restart the mount connection by itself now. |
kstars/ekos/mount/mount.h | ||
---|---|---|
45 ↗ | (On Diff #46285) | currentTargetPosition? |
kstars/ekos/capture/capture.cpp | ||
---|---|---|
2997 | There was one commit missing in the diff |
Tested and it worked great. Few changes required.
kstars/ekos/capture/capture.cpp | ||
---|---|---|
66 | Why are you initializing it here and then again in registerNewModule? | |
kstars/skyobjects/skypoint.cpp | ||
940 ↗ | (On Diff #48311) | ditto |
kstars/skyobjects/skypoint.h | ||
26 ↗ | (On Diff #48311) | DBus is not used on KStars Lite, so #ifdef should be used |
653 ↗ | (On Diff #48311) | ditto |
OK, I will put the wrapping #ifdef in SkyPoint.h and SkyPoint.cpp.
kstars/ekos/capture/capture.cpp | ||
---|---|---|
66 | I am not sure what happens, if the interface is created before the mount module has registered at the DBus. Therefore I capture both situations with this construct:
|
kstars/ekos/capture/capture.cpp | ||
---|---|---|
66 | Ok, not sure if in this instance using delete(mountInterface) in registerNewModule is required to free memory? The class is a child of "this" but not sure what happens when another "new" is used without deleting the first one. |
- Memory handling for mountInterface corrected
- Code cleanup, D-Bus method name harmonized
Just found today that this doesn't cover the case where Slew is initiated from from the sky map or elsewhere outside Mount
Ah, good point, that makes sense. Nevertheless, the current implementation relies on the fact that captures take place.
I am already working on a solution that covers all cases where the mount tracks an object and crosses the meridian.