Autofocus intermittent with Celestron Focus Motor (3.1 Beta)

I’ve had a considerable amount of headache trying to get my Celestron Focus Motor to work consistently. Sometimes it works great, other times the focus window pops up and it just sits there frozen. If I disable autofocus in my settings, everything works great. Other times the whole SGP app crashes. Any ideas as to how to start debugging that? I do use TheSkyX for TPoint and Protrack (shooting unguided), so I could use @focus3, which tells to be pretty reliable, if there was a handy way to trigger it from within SGP. (Scope is an 8" EdgeHD SCT)


Managed to get autofocus to work relatively well during latest builds but it got a bit hazy at about 2:30am last night and the sequence aborted with “Auto focus failed! Error in auto focus! Focuser failed to move to the requested position (21919). Focuser reports it is at 21889.”

As I was writing this I noticed there is a new .353 build that appears to solve this very issue. Not sure though since I have seen this interactively when attempting to manually move the focuser - it seems like no matter what I do that focuser becomes unresponsive and I can’t interact with it until I disconnect and reconnect my imaging train (zwo 1600 mm pro, atik efw2, celestron focus motor).

Will test it out again tonight if the skies permit and confirm if I was finally able to get a whole night without something aborting the sequence.


If you’d like us to take a look at something, please send logs and we’ll be able to help you a lot faster. Here is some info:

Ah definitely, here ya go:

Issue occurred at 2:47am

Let me know if any other info would be useful! I enabled focus packs to be saved for tonight but not sure if they are helpful in the case that the focuser is unresponsive.



Unfortunately, we can’t be of much help here. The only thing SGPro knows is that we ask the focuser to move and then check on it so when we know when it’s done. At this point, at the time you specified, SGPro maybe seems to be doing something that the driver does not like (but we aren’t doing anything abnormal). The driver starts returning this to SGPro and once it starts, it does it consistently… like it got into a bad state:

[11/09/19 02:47:05.212][DEBUG] [Focuser Backlash Thread] ASCOM Focuser: Error in IsMoving wrapper. : Failed to receive response
at ASCOM.CelestronUsbMotorFocuser.Focuser.get_IsMoving()
at sc.get_IsMoving()
at r5.b4(Boolean A_0)
[11/09/19 02:47:05.903][DEBUG] [CP Update Thread] ASCOM Focuser: Error in GetCurrentPosition. : Failed to receive response
at ASCOM.CelestronUsbMotorFocuser.Focuser.get_Position()
at sc.get_Position()
at r5.h0(Boolean A_0)

Thanks Ken, I did run into it again a few times tonight. The odd thing is that disconnecting and reconnecting didn’t seem to solve the issue, I had to restart SGP completely. I threw the logs in the same link above in case it’s useful. Seems to be this index out of range error that triggers it:

[11/09/19 19:33:18.332][DEBUG] [CP Update Thread] ASCOM Focuser: Error in GetCurrentPosition. : Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
at System.Collections.Generic.List1.RemoveAt(Int32 index) at System.Collections.Generic.List1.Remove(T item)
at ASCOM.CelestronUsbMotorFocuser.Celestron.AuxBus.Send(AuxPacket tx, AuxPacket& rx, TimeSpan timeout)
at ASCOM.CelestronUsbMotorFocuser.Focuser.get_Position()
at sd.get_Position()

Wondering if it has something to do with the backlash removal, a race condition or something. I do have that set pretty high, 500 steps. May try dropping that to 200 and see if it minimizes the issue. Otherwise may have to get in touch with Celestron - I don’t think their driver/focus tool has changed since the release and I can’t use the ASCOM driver on the ASCOM site since it requires a Celestron mount.

Thanks for taking a look though!

It’s not surprising. SGPro “owns” those processes so disconnecting and connecting may not necessarily reset the driver’s state (it’s up to the driver author what happens there).

If you do end up communicating with the driver author and need more info, let us know.

A quick update - ended up using the beta (v1.5) version of the driver available via and haven’t had any issues for a few sessions now. Considering this solved, thanks for the help!