I get occasional Auto Focus failures, roughly 1 in 5 at a guess. It fails to capture an image when this happens. I assume this is a bug?

I had the same problem last night with auto focus failing resulting in loss of imaging time once again!!

I have attached the log file and the analyse file. Last night I had extra debugging turned on.
I can see a bug where autoguiding attempts to capture a 5 second exposure with the ZWO ASI 120 mini camera. I refer to this as a bug as the exposure time was set to 2 seconds and all previous guiding images were captured with 2 second exposures! So what changed this to 5 seconds? Following this autoguiding aborts failing to capture an image and then Capture aborts. Game over for the evening.
I am using 2 ZWO cameras ASI 2600MM as the imager and ASI 120 mini as the guider.
My profile just has a ZWO CCD driver the CCD and nothing set for the guider. I have set the guider to ZWO CCD as well in the past but I think at some point it changed back to '--' . I have read somewhere not to use ZWO Camera 1 and 2 as they are experimental (despite being selectable in the released software). With just CCD set for the imager works anyway and I have read a single driver supports multiple cameras even though the Profile Editor is misleading allowing different driver combinations to be selected. Maybe with one driver there are times when it gets the two cameras muddled?

Auto focussing can be initiated by filter change, 2 conditions in capture and EKOS settings so its possible there will be times when Auto focussing is started simultaneously by 2 or more conditions. I guess this is handled correctly?

Is there an EKOS log viewer which supports filtering of messages and tracing of capture, guiding and focussing events to help with debugging?

Hi David,

I had a quick look at the log...
Starting focus with Detection: "SEP" Algorithm: "Linear 1 Pass" Box size: 64 Subframe: no Autostar: yes Full frame: yes [ 5 %, 60 %] Step Size: 50 Threshold: 150 Gaussian Sigma: 1.5 Gaussian Kernel size: 5 Multi row average: 3 Tolerance: 1 Frames: 1 Maximum Travel: 200 Curve Fit: "Parabola" Use Weights: no R2 Limit: 0

A couple of things jump out at me.
1. Max Travel set to 200. Why is this so low? You are constraining the autofocus run. I would set it to 2000 (unless that gives you other issues). If the run is constrained then you won't get a proper curve. I also see log failures due to this.
2. Use weights = no. I would recommend setting this to yes.

If you send me a couple of focus frames (1 in focus, 1 as far out of focus as the autorun takes things) then I'll take a look at these. Be good if you can screenshot the SEP profile options you are using as well.

Best,
John.

Hi John,
It is set low because I find the star detection algorithm fails when stars get too far out of focus. With short glimpses when watching auto focus I can see It identifies what is one large star as several smaller stars and returns too low a HFR value for that focus position which throws a wobbly in the best fit parabola estimate. When nearer to focus but star image more of an irregular disk I see a poor HFR estimate. Close to actual focus the star image is good and looks like a fuzzy blob as you would expect and HFR value is OK.
I have tried weights which didn't help. I have tried different combinations of step size and, max travel and multiple out step sizes. The log I sent is just one iteration of different settings I have tried. I will do more testing and I agree with your sound advice of widening the focus motion, I just need to sort out the issue with HFR values being inconsistent. There is almost a pattern that the second point is always too high. Now I you have confirmed how to save the focus images for examination later I can do better testing. I will send you my results when I have had chance after a clear night.
I also need to check out the mechanics of my focuser and optics alignment. I have spent sometime on this already and thought it was good. The focuser is a very solid one and I have 3D printed two brackets to fit the ZWO EAF accurately with no flexure to either the fine or course focus. Currently I am testing on fine focus. I have had the focuser on the bench and there is little backlash which is hard to measure. Backlash is about 40 steps with course and hardly anything with fine. Axial alignment of the focuser and collimation will be checked again as this will contribute to poor star image and then poor HFR estimate.

The other more serious problem is failure in the auto focussing that happens from time to time. (its unpredictable but maybe every 6 to 10 auto focus operations). Auto focussing fails because it fails to capture an image. It looks like a ZWO driver issue to me. This can be seen in the log file around line 176513. Here is the relevant part:
[2022-09-19T02:06:25.614 GMT Summer Time DEBG ][ org.kde.kstars.ekos.focus] - "Focus position reached at 27350, starting capture in 1 seconds."
[2022-09-19T02:06:25.615 GMT Summer Time INFO ][ org.kde.kstars.indi] - ASI EAF : "[INFO] Focuser reached requested position. "
[2022-09-19T02:06:26.615 GMT Summer Time INFO ][ org.kde.kstars.ekos.focus] - "Capturing image..."
[2022-09-19T02:06:26.663 GMT Summer Time DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI120MM Mini : "[DEBUG] StartExposure->setexp : 5.000s "
[2022-09-19T02:06:26.664 GMT Summer Time INFO ][ org.kde.kstars.indi] - ZWO CCD ASI120MM Mini : "[INFO] Taking a 5 seconds frame... "
[2022-09-19T02:06:29.088 GMT Summer Time INFO ][ org.kde.kstars.ekos.guide] - "Exposure timeout. Aborting Autoguide."
[2022-09-19T02:06:29.102 GMT Summer Time DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Guiding" to "Aborted"
[2022-09-19T02:06:29.103 GMT Summer Time INFO ][ org.kde.kstars.ekos.capture] - "Autoguiding stopped. Aborting..."
[2022-09-19T02:06:29.109 GMT Summer Time INFO ][ org.kde.kstars.ekos.capture] - "CCD capture aborted"
[2022-09-19T02:06:29.115 GMT Summer Time DEBG ][ org.kde.kstars.ekos.guide] - Reset non guiding dithering position
[2022-09-19T02:06:29.116 GMT Summer Time DEBG ][ org.kde.kstars.ekos.focus] - Stopping Focus
[2022-09-19T02:06:29.117 GMT Summer Time DEBG ][ org.kde.kstars.ekos.focus] - State: "Aborted"
[2022-09-19T02:06:29.118 GMT Summer Time DEBG ][ org.kde.kstars.ekos.capture] - Focus State changed from "In Progress" to "Aborted"
[2022-09-19T02:06:29.118 GMT Summer Time INFO ][ org.kde.kstars.ekos.focus] - "Autofocus aborted."
[2022-09-19T02:06:29.129 GMT Summer Time DEBG ][ org.kde.kstars.ekos.capture] - setMeridianFlipStage: "MF_READY"
[2022-09-19T02:06:29.130 GMT Summer Time INFO ][ org.kde.kstars.ekos.guide] - "Autoguiding aborted."
[2022-09-19T02:06:29.132 GMT Summer Time DEBG ][ org.kde.kstars.ekos.guide] - Aborting "Guiding"

The odd thing is that I am using 2 sec exposures for autoguiding and 5 second exposures for auto focus on different cameras of course. At this time it has been running for a couple of hours autoguiding at 2 second exposures then here it changes to 5 seconds! Auto guiding Aborts followed by Auto focussing.

I don't know how developers work and co-ordinate efforts but I see Jasem is often mentioned. Anyway as I say, I have created another forum topic on this particular issue and I can only hope someone picks this up.


P.S.
A minor question. If for simplicity, I set backlash to zero then initial step size to 100, out step multiple to four and Max travel to 200 what happens? Surely Max travel must be >= 4*100.

A thought. If the focus position isn't close to the current position when auto focus starts the resultant parabola is asymmetric, with more points one side of the focus than the other and this adds to the problem of poor HFR values for me. Of course we can't know where the focus position is otherwise no point in auto focus but if computed focus position is near one end of the curve would it be a good idea to do another pass with what is hopefully a computed focus near the centre for improved accuracy?

So the Max Travel is there to protect the focuser from moving beyond its bounds and damaging itself. So I would set it high enough that it doesn't get "in the way" of an autofocus run otherwise you'll get compromised (=poor) results. Focus will persevere and try to do its best but the constraint is just unnecessary. As a guide set it to at least 2 * number steps * initial step size. Personally, I set mine way above this so I know it won't compromise the autofocus run.

I would always start focusing from near to focus. You can do this quite easily manually or get close enough and do an autofocus run and then that's the start point for the night.

As far as the 5s guide exposure I don't know what's going on there. Sounds strange. I was messaging Jasem earlier and he confirmed that setting ZWO CCD driver in the Indi profile would handle both cameras (which is what I do BTW). Have you got the latest version of the driver?

Happy to take a look at your focus pictures when you next try things. I'm guessing you have a scope with a central obstruction, hence the tricky situation with out of focus stars.

Hi John. ... a further question, how does auto focussing handle backlash? The one pass linear algorithm winds the focuser in one direction when capturing images so no reverse in direction and backlash doesn't come into play, so at the start moving out to initial start position and when winding back to computed focus position is when backlash is important.

The ASI EAF manual describes how to estimate the backlash and this gets saved to the EAF. The Indi driver confirms this as it has the setting I set up using the ASI software on my laptop.

Now there is a backlash value on the mechanics tab and first time it is the same as the indi driver. If I change it here I believe it changes it on the Indi tab which updates the value saved on the EAF. Is this correct please?

Now my knowledge gets muddy. If the EAF is commanded to move to a set position which requires a reverse in direction it will internally adjust for backlash. This means the step count doesn't need to be adjusted by the auto focuser otherwise this will double handle the backlash. However examining the log file auto focussing routine does adjust count for backlash.

If I have got this right (probably haven't) I dont think auto focus should compensate for backlash with a ZWO EAF and I wonder why the backlash is even there on the mechanics tab.

Could you clarify what I have got wrong.

Thanks
David

The software handles the backlash compensation. The exposure of backlash on the Mechanics tab is a convenience to avoid having to use the indi tab (both are kept in sync).

For L1P it works as follows:

Backlash: All mechanical devices with gears suffer from backlash. In a typical focuser there will be a dead zone where changing direction (e.g. from “in” to “out”) results in movement of the focuser by a few ticks, but no actual movement of the optical train.

The Linear 1 Pass algorithm (like the Linear algorithm) provides backlash compensation in the 2 places during an auto focus run when the focuser moves outwards:

The initial outward movement of Initial Step Size * Out Step Multiple at the start of the run.

When the inward pass is complete and Ekos has determined the best focus position and moves outward to it.

Linear 1 Pass will extend (by x ticks) the outward movement, and then, as a separate movement it will move inward by x ticks. So it always approaches the desired position in an inward direction.

There are 2 schemes that can be used:

Set Backlash to 0. Ekos will use a value of 5 * Initial Step Size.

Set Backlash > 0. EKOS will use this value in its backlash calculations. There will probably be instructions with your focuser for determining the value of Backlash. It is not necessary to set an exact value for either Linear or Linear 1 Pass to work correctly; all that is required is that the value set in Backlash is >= the actual backlash value. For example, if you measure backlash and get a value around 100, any value >=100 will work equally well. For example, set Backlash = 200.

Thanks for explanation on backlash. I understand now. Just need to remember to put it back to its measured value when using the focuser manually. With Fine focus its a small amount about 5 and course 40. I will use a value of 50 to cover all eventualities.
Thanks for explanation of Max Travel. The hint says 'Maximum travel in steps before the autofocus process aborts'. We said it was +/- this value before so I was reading this as a relative value and not absolute. For the ZWO EAF the home position is 0 and max value is 65,000. I guess code wont attempt to move to a negative value so that end is protected and I will set the max value to 65,000 or less if there is insufficient movement in the focuser?
The direction of the focuser can be reversed so zero can be closest in or furthest out. When auto focuser describes motion as motion in it could actually be going out. I notice focusing moves decreasing the count. As telescope is expected to be pointing above the horizontal then its probably best to drive the camera towards the scope (in) to keep slack out of the gears. If that sounds sensible, then I need to set EAF direction so zero is closest towards the scope? With course EAF motor fits on opposite end of shaft and direction is reversed then I need to reverse the reverse to keep zero closest in!

indi-asi 2.2 is installed.

Yes the 12" RC telescope I have has a large secondary.

Oh, nice. That should be great! I'm really interested to see some focus images. I can run them through star extraction. I have been doing some research to try to improve star detection with SEP so if this turns out to be a problem then I might be able to help a bit.

Hi John, I did some tests back in July where I captured some images at various step positions from way out of focus to near focus. I didn't use auto focus, just used capture changing the step position between frames.
Below are screen grabs from Fits viewer of about 1/3 of the frame. The HFR values are those as given in the fits viewer and seem to me much what I would expect so good results I thought at the time. I plan to do repeat this test to ensure focuser and optics are good and then on same night run auto focus tests to see how they perform. I have messaged you to see how I can send you these images, 18 in number, about 140 mb zipped
Step=10000 HFR= -1
Step=14200 HFR=12.652
Step=14400 HFR=8.452
Step=14550 HFR=4.743
Step=14570 HFR=4.491
Step=14600 HFR=4.233

Yeah you don't want autofocus get beyond HFR 8 as stars starts form circles with dark center. That can confuse star detection and cause fail so set initial step size to 30-40.