Meridian flips are also initiated if a sequence has only one single frame captured. This resolves bug #400265
- 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.
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.
Agreed, this is the core of the change.
Missing management of bool return code.
Test against nullptr?
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...
Missing management of return code.
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.
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.
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.
OK, I will put the wrapping #ifdef in SkyPoint.h and SkyPoint.cpp.
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:
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.
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.