Hi Sergio,
actions overlapping with focusing might lead to problems. I had a similar one where the scheduler changed the target while a re-focus was running. I'll have to take a closer look what happened there.

One thing that suprises me is that guiding seems to restart before slewing has finished. It could explain why this happens:
You do not need to create a bug report. One of my hobbies is the meridian flip handling I'll take a closer look and come back.

Thanks for reporting it.
Wolfgang

Thanks so much, Wolfgang! These border cases seem difficult to catch, good to know that the MF expert is here!

Hi Sergio,
it took me a while to drill it down, but now I have a test case that shows the problem. When a meridian flip happens while focusing, focusing is aborted - that's fine. But then, the problem begins. An aborted re-focus triggers capture to abort - this at least is wrong if the aborted focusing was triggered by a meridian flip.

So after the meridian flip has completed, capture does not continue. If the scheduler is running and error recovery is selected, the scheduler will restart the capture sequence. If not, capture remains terminated after the meridian flip.

In your case it is even more difficult, since it looks like the scheduler tries to the restart the job while the meridian flip is still running.

Wolfgang

Thanks Wolfgang!
The code is overwhelming to me but I had a look at it. Capture triggers refocus (after expiring the configuring time limit), which first check focus, then suspends guiding (as configured), and then initiates the focuser motion. But why focusing fails? Is it because it cannot find stars in the captured image (this would be incoordination between the modules, as the mount is slewing) or because the flipping operation somehow signals focus module to abort (I can't find something like this in the code) ?

The capture module indirectly triggers the focuser to abort. The connection is via the event meridianFlipStarted() in Capture that triggers Focuser::abort(). The connection is configured inside the manager, that translates the capture event into a focuser signal.

Thanks! I completely missed that...

Any thoughts for the solution?

I understand that delaying the focusing operation after the flip is desirable, but doing so by 'aborting and retrying' after the flip seems difficult to manage by the state machine as it should distinguish it from a true focusing failure.

Maybe don't initiate the focusing if it will overlap with a flip? Not trivial as we don't know how long focusing will take, also not sure how difficult is to implement this 'look ahead'.

Or maybe just don't accept the flip while focusing is running? This deviates from the ideal, but maybe its easier to implement?

Thanks so much for your involvement, Wolfgang!

I'm already working on a merge request  !MR371  to fix this. The current approach is to interrupt focusing when a meridian flip is necessary - a MF should have priority since if it comes too late the scope might hit the pole. As soon as the flip is completed, focusing should be restarted similar as we do it for guiding etc. I'm slightly optimistic that this is already the case.

The current problem is that a flip aborts focusing (OK) and this leads to capture abort (not OK).

If the scheduler is running, it becomes even more complicated, since an aborted capture might immediately lead to restarting alignment and guiding, which could itself interfere with the meridian flip.

I'm currently working on test cases to reliably reproducing the situation and then try to fix it.

Thanks so much for the detailed explanation. Hope you can fix it without too much work

I've also experienced the issue in my setup. Just an idea... but when there is an issue with auto focusing, rather than aborting capture... why don't you just return to the original focus setting and continue as before?

Thanks!

Ron

That's exactly the idea I'm working on. Aborting focus should move the focuser to the last known focus position. And capture will be modified such that an abort event of the focuser will not abort capturing if itself triggered a re-focus.

I had the same problem. Focus aborted by the meridian flip, which in turn then aborted the capture sequence.
In addition to just ABORTING the focus, couldn't the meridian flip schedule a re-focus after the flip is finished?

I'm afraid, just resuming the old focus position will not be sufficient in my case, as driving to absolute positions is very unreliable for me. It would be perfect, if auto-focus would just start after the flip. And even in that case, It would really depend on the current focus position being not too far off (after the aborted focus attempt).

Steffen

Good news, my test cases could reproduce the behavior that Sergio reported here. The explanation is the following:

If focusing is running when a meridian flip is ready to take place, the meridian flip starts and aborts focusing - that's how we expect it. Next, capturing aborts due to an aborted focusing - that might be right in other situations, in the case of a meridian flip that's wrong.

Subsequently, the scheduler obtains a capture failure and - depending on the error strategy, will react. Keep in mind, the meridian flip is still running. If the scheduler is configured to restart an aborted job, the first step is to slew to the target - which creates the error message that the meridian flip has failed.

The solution is quite easy: do not abort capture when focusing fails during a running meridian flip. It's already present in the merge request and needs to be tested thoroughly, but I'm quite confident that we could solve this case quite soon.

Cheers
Wolfgang