AutoFocus Update Feature Request


Jared and/or Ken

I know I’ve asked for this before but is there anyway to add in a user defined delay during autofocusing so that once the focuser is done moving there is a user selected delay before the imaging camera takes the AF image? Maybe adding in something like is done in the Telescope and Filter wheel that delays any further processing until the time has expired. I use a primary mirror focuser on my SCT and most of the time the stars look almost like teardrops because the mirror has not yet settled after moving and SGPro directs the camera to take the AF image. It seems to be worse with cold weather and with smaller high sensitive imaging sensors like the QHY174… It’s not as bad with my ATIK 383 camera. Since I cannot use SGPro AF I find myself needing to pause the sequence and doing the focusing manually. I attached a typically graph of what I am getting during AF.

Please, Please, Please can this feature, user delay, be added to AF?



Mark, I am glad you spoke up. I get similar graphs on my C11 and assumed it was the focuser slipping. The focuser is a Moonlite crayford which is not suppose to slip. So it may very well be settling time… Bruce


Are you able to use a larger step size? If you can, it might help you… Try to get the ends closer to 3x the middle instead 1.5x…

Best regards,


Hi Craig,

Thanks for the feedback. With my ATIK 383L+ OSC most times I get good curves. the reason being is that the 383 camera has a mechanical shutter that needs to open. I believe it is that slight delay by the camera to allow the shutter to open helps to allow the mirror to ring out before the camera actually begins taking the image. My other cameras that do not have a mechanical shutter and have high sensitivity with very short exposures during AF and is really the biggest issue. I actually backed down my step size from starting at 250 and ended up landing on the 125 step size. larger steps created very large and blurred donuts. the 125 got me the closest. On my 383 camera I use a 200 setup size. I think the cold weather is also adding to the AF issue.

Also, if you noticed in the graph the best HFR was something like 4.5. This is mainly do to the stars looking like a teardrop or more out of focus then they actually are with some worse that others so that is why the graph is showing some saw tooth. In reality, when I do the manual focus and allow the mirror to settle my HFRs are something in the 2 ranges. This is why I believe simply giving a short delay will solve this AF issue with cameras without shutter when used with primary mirror focusers on SCT scopes



I understand the frustration, but I am not sure about this. There are a 100 instances just like this one where SGPro could attempt to account for bad behavior in drivers and gear (or worse, adding checkboxes to cover its own bugs). If we start, where do we stop before we have a mess of interface controls to help treat symptoms? There is no reason that a focuser should still be moving after it reports it is done moving and adding a setting to account for this is a slippery slope. There are only two things to be done here:

  • Identify a bug in SGPro and fix it (Meaning SGPro is starting to image before the focuser reports done). Maybe that’s what is happening?
  • Speak to the driver author about the same thing.


As far as I recall this issue was looked into intensively regarding the rigel focuser and I thought there were indications of SGP exposing while the focuser was moving.

I thought that when this was being looked into in detail - the thread just died out with no resolution.

In my case I focus with the sct primary focuser - which not only works well, but it is the only way to focus hyperstar - and SGP autofocus is fine with Atik 383L+ and ASI1600, but it does not work with SXVF-h9 - and I have no idea what the difference is. The stars are consistently elongated as if the exposure is happening either too soon - or the focuser moves before the exposure is finished.



Yes Frank is correct in that this was looked at. Back in February of this year I posted the issue here, Potential Auto Focusing Bug, I worked with Gene Nolan the ASCOM developer for the Rigel nSTEP focusers and we identified the IsMoving issue. SGP was not waiting for both cases to be true POS=reqPOS and IsMoving=False. Which would account for what I am seeing with my stars during AF. Gene was in contact with Jared but for whatever reason the issue was never explored any further by SGPro and Gene did not hear anything else from Jared. Maybe Jared was thinking the issue was fixed. I believe Gene created a ASCOM simulator to test out those timeouts and sent that to Jared.

In the meantime, I changed out my scope out from the SCT to my refractor, which does not have the issue since refractors use Crayford focusers and don’t have this moving mirror issue. It wasn’t until later this fall that I changed things back to my SCT and have been fighting with this AF issue. I am quite surprised there are not more folks having this issues with getting a good focus curves with the AF. Maybe most of the folks using SGpro are either using Crayford focusers and not focusing with the primary mirror.

I have three scopes and all three are equipped with the nSTEP Stepping motor system, HD11, C8, and ES102. Both the HD11 and C8 show the AF issue with elongated or teardrop stars and a saw tooth AF graph. More so with the HD11 then the C8. However, when using the ATIK383L+ OSC I can get reasonable AF. I attribute this to the 383 having a mechanical shutter that causes a slight delay before the image is taken and I believe allows the SCT mirror to ring out enough to allow for good AF images.

Anyway from what Gene has explained the real issue appears to be with SGPro not waiting for both cases of POS=reqPOS and IsMoving=False. Gene believes by fixing this in SGPro the issue will be fixed and Gene can implement a user delay in his ASCOM focuser driver for folks that do want to add in an additional delay for when the focuser is done moving.

Also, I am still unsure why SGPro allows for a telescope settling delay and a delay after a filter change but not for focusing moves.

Don’t get me wrong SGPro great and I could not do what I am able to do without it. I am just trying to plead my case for a fix to the AF.

Kind Regards,


I’ve had a look at the thread quoted above and I’m not convinced that the driver code does what I’d expect. It seems possible that the driver could be reporting IsMoving as false before the driver has finished moving. Logs showing the communication between SGP and the focuser driver would help to resolve this. I added a reply to that thread saying why.


Chris, I provided a simulator to Jared that would allow testing both timeouts in focus and also a varying delay for clearing isMoving after returning POS=reqPOS. Want the focus simulator so you can check for yourself what SGP is doing inside it’s log’s? There were weeks of back and forth early this year, for me it was worthless time spent then so I am not willing to put much time into this now.


I’m always suspicious of “fixes” such as a delay because they feel to me like a sticking plaster solution (what Americans would call a Band Aid). Better to fix the underlying problem than hide it.


And what do you see as the problem in this specific case?


Hmm… probably nothing was done because we do check for both of those things. For what it’s worth, I don’t think this issue has ever been reported on a focuser other than nStep (please correct me if I’m wrong).

@astrogene1000_stuff I apologize if you’ve been through this before. I have no knowledge of it and this is just my report from my research tonight.

If anyone is interested or cares, this is how we currently check for focuser movement completion:

while (!theFocuser.IsMoveComplete(true) && curPos != position)




focuser.isMoving (in a protective way)


If you look at my earlier postings on this issue you will see that I had the problem both with RoboFocus and Rigel - which amount to completely different drivers and control software paths.

I was using the same stepper motor with both controllers and would have problems with some cameras and not with others. SX and QHY174 had the problem; Atik383L+ and ASI1600 did not.

I don’t know what or where the problem is - but I hope it can be revisited. I know that Gene spent a fair amount of time on his side to make it identifiable.

And it may in fact be true that a delay wouldn’t have even fixed this in the first place. But a delay after focusing is still a good thing - as is a delay after a filter change or a delay after a mount movement. Since SGP is at the top of all this equipment and telling it what to do - I would have a delay after every action that results in physical movement. Because only the user would know if a delay is needed after a given action, and how long it should be. That isn’t a band-aid - it’s common sense - and already shows with the existing delays selectively available in SGP.



Since SGP is at the top of all this equipment and telling it what to do - I would have a delay after every action that results in physical movement. Because only the user would know if a delay is needed after a given action, and how long it should be

I second that



A simulator is available here
Extract to
C:\Program Files (x86)\Common Files\ASCOM\Focuser
C:\Program Files (x86)\Common Files\ASCOM\Focuser\gc_sim.exe /regserver
On the setup screen you can control the focus ‘speed’ and also the response time for IsMoving delay
Open the Traffic window writes a log out to
and select the various choices to Traffic log


Running the focus simulator above and also the ASCOM V2 Camera simulator,
SGP. notice the ‘Moving’ at 59:35.228
Notice the ‘complete’ at 59:47
What really happened is the last move was not done yet, IsMoving was being returned True from 59:35 through 59:47, when it went false then the previous move had completed, a new one sent and while focusing the picture was taken. Notice the frequency of polling of IsMoving in the GCSIM log snippet below

[11/21/17 18:59:35.228][DEBUG] [Camera Thread] Moving focuser to next position (2010)…
[11/21/17 18:59:35.229][DEBUG] [Focuser Move Thread] Focuser moving to 2010
[11/21/17 18:59:47.440][DEBUG] [Focuser Move Thread] Focuser move call complete
[11/21/17 18:59:48.451][DEBUG] [Focuser Move Thread] MoveFocuserAbsBlocking: Focuser position 2010 matches requested position 2010
[11/21/17 18:59:48.451][DEBUG] [Camera Thread] Focuser move complete…
[11/21/17 18:59:48.462][DEBUG] [Camera Thread] Focuser position matches requested position (2010), continuing…
[11/21/17 18:59:48.471][DEBUG] [Camera Thread] Calculating step metric…
[11/21/17 18:59:48.471][DEBUG] [Camera Thread] Taking auto focus frame(s)…
[11/21/17 18:59:48.473][DEBUG] [Camera Thread] ASCOM camera: Capturing auto focus frame…

**GCSIM log, **see the ‘3’, that is how many counts till the fake timer will allow IsMoving to return True
Fake IsMoving timer fired: 4 18:59:46
g_iDidMove2= 18:59:47.4747 3 200>
Fake IsMoving timer fired: 3 18:59:47
g_iDidMove2= 18:59:47.4747 2 200>
Fake IsMoving timer fired: 2 18:59:47
g_iDidMove2= 18:59:47.4747 1 200>
Fake IsMoving timer fired: 1 18:59:47
g_iDidMove2= 18:59:47.4747 0 200>
IsMoving1d: False 18:59:47.4747

Move2b: 2010 18:59:47

StepTime: 1

Move2c: 2010 18:59:47

delta: -10
g_iDidMove2= 18:59:47.4747 198 200>
Fake IsMoving timer fired: 198 18:59:47.4747


I have made a couple modifications in hopes that it corrects the observed issue. I am still not certain how to recreate the issue so I am not sure if it will fix it, but I’ll release this in the 3.0 beta shortly.


Ken, download the GCSIM linked above, Connect to it with SGP, in Setup, set Focuser Speed to 1 and IsMoving Delay to 200.
Open the GCSIM Traffic window and check all the boxes.
Connect to the ASCOM Camera V2 simulator and do an autofocus run for a V curve

GCSIM logs are in the
folder on W10



Thanks Gene. Are you saying this reliably reproduces the issue folks are seeing?


Yes :slight_smile: I supplied this last Feb but nothing happened with it
Here is more info from the run above

SGP start of autofocus run
[11/21/17 18:59:02.525][DEBUG] [Camera Thread] SGM_FOCUSER_AUTO_FOCUS message received…
[11/21/17 18:59:02.530][DEBUG] [Camera Thread] Checking for auto focus…
[11/21/17 18:59:02.530][DEBUG] [Camera Thread] Auto focus required (focus before first frame)…
[11/21/17 18:59:02.541][DEBUG] [Camera Thread] Auto focus: setting filter None
[11/21/17 18:59:02.549][DEBUG] [Camera Thread] Auto focus running…
[11/21/17 18:59:02.556][DEBUG] [Camera Thread] Turning temp comp off…
[11/21/17 18:59:02.578][DEBUG] [Camera Thread] ASCOM Focuser: Temp comp is avaialble, setting to False
[11/21/17 18:59:02.626][DEBUG] [Camera Thread] Performing Sequence Generator auto focus using Half Flux Radius. AFID: 0
[11/21/17 18:59:02.686][DEBUG] [AfChartThread] Showing AF chart dialog…
[11/21/17 18:59:02.716][DEBUG] [Camera Thread] Auto focus data
[11/21/17 18:59:02.716][DEBUG] [Camera Thread] - Data Points: 7
[11/21/17 18:59:02.716][DEBUG] [Camera Thread] - Step Size: 10
[11/21/17 18:59:02.716][DEBUG] [Camera Thread] - Current Position: 2000
[11/21/17 18:59:02.716][DEBUG] [Camera Thread] - Initial Move Position: 2030
[11/21/17 18:59:02.741][DEBUG] [Camera Thread] AF Darks exception: The path is not of a legal form.
[11/21/17 18:59:02.742][DEBUG] [Camera Thread] Moving focuser to next position (2030)…
[11/21/17 18:59:02.745][DEBUG] [Focuser Move Thread] Focuser moving to 2030
[11/21/17 18:59:02.767][DEBUG] [Focuser Move Thread] Focuser move call complete
[11/21/17 18:59:03.776][DEBUG] [Focuser Move Thread] MoveFocuserAbsBlocking: Focuser position 2030 matches requested position 2030
[11/21/17 18:59:03.776][DEBUG] [Camera Thread] Focuser move complete…
[11/21/17 18:59:03.786][DEBUG] [Camera Thread] Focuser position matches requested position (2030), continuing…
[11/21/17 18:59:03.797][DEBUG] [Camera Thread] Calculating step metric…
[11/21/17 18:59:03.801][DEBUG] [Camera Thread] Taking auto focus frame(s)…

Here we see a check of IsMoving and gets a False. a Move Commanded, IsMoving returned True,
Position polled a few times then IsMoving polled again and gets a True.
The bolded numbers are how much ‘time counts’ (unitless) before IsMoving is returned False

IsMoving1d: False 18:59:02
Move2b: 2030 18:59:02
StepTime: 1
Move2c: 2030 18:59:02
delta: 30
g_iDidMove2= 18:59:03.033 197 200>
Fake IsMoving timer fired: 197 18:59:03
Position: 2030 18:59:03
Position: 2030 18:59:03
MaxStep: 8000
Position: 2030 18:59:03
Position: 2030 18:59:03
Position: 2030 18:59:03
Temperature: 68
g_iDidMove2= 18:59:04.044 187 200>
Fake IsMoving timer fired: 187 18:59:04