Mount Does Not Slew to Target


Attached with DropBox are the following files
A) NGC772_CEM120…… Sequence File
B) sg_logfile_20221213182830
C) sg_logfile_20221218171126
D) sg_logfile_20221218171949
E) sg_logfile_20221218173146

Item B is a successful night of imaging NGC772 including pier flip on 12/13/22.
Item C, D and E were done on 12/18/22, are very short, and all failed to move the scope/mount.

I tried the Control panel Telescope Nudge Control in item C. The north arrow moved the scope, but the rest (S, E, W) failed to slew, and then the N would not slew. Once I Ran Sequence, all functions responded except for the mount. It would not slew to target. And an error message stated the failure to go to target.

Item D was done with the least interference from me. I either connected the camera and Ran Sequence, or just Ran Sequence. All appeared to work except for the scope slew.

Item E is much the same as items C and D. Prior to executing, I changed the old Belkin RS232 to USB adapter for a new one. The adapter has a 6’ USB2 cable from the computer and an iOptron supplied RS232 cable to the mount.
Same results as Items C and D.

I can move the mount using its “Commander” software that is actuated when SGP connects. I can also move the mount with the handset.
I believe that at the times when the automation fails to get the mount to slew, the handset also becomes “jammed up”, and clears once shut down.

I’m looking for suggestions as what further I can do with procedure, software and hardware.


12" LX200 Classic SCT OTA, 2182mm (f/7.16)
iOptron CEM120 Mount
QHY294MM mono CMOS camera, Atik EFW2 filter wheel
SX Lodestar guide camera, 1091mm (f/3.58)
Mitsuboshi OAG5
Starizona MicroTouch for FT focuser
Starizona SCT corrector
SGP v3.2.0.660 Automation
Lesvedome Dome Automation
Link to Logs

Useful Info

OS: Win 10

Looks like your links didn’t make it into the post

Thanks Ken,
I can see them in the “Useful Info” heading.

But here they are again.


Ah, you are right, I thought that the text at the top was supposed to be a set of links and I missed the link at the bottom.

I wish we had more insight to give here. I looked through the logs and it seems like a critical error in the ASCOM driver. Unfortunately all failures carry the description ASCOM.InvalidOperationException which isn’t super helpful. Our visibility beyond the ASCOM boundary is very limited. This issue may require input from iOptron…

In a generic sense:

  • In the 5 days that elapsed between success and failure, is there anything at all that changed in your rig? Anything from a Windows update to an ASCOM platform update to a driver updates are all fair game. Even the smallest thing… Part of me wonders if that “initial” manual nudge in C may have inadvertently caused some type of driver corruption that persisted into sessions D and E.
  • Because the commander app works as expected, it seems that you are in the clear with the USB adapter or things like that being the culprit. That commander app does not use ASCOM to control the mount so it doesn’t do much for us there, but it does decrease the likelihood that it is a hardware failure.
  • Have you tried updating the iOptron driver? If you were already using the latest version, it may be worthwhile to completely uninstall it and re-install it again in case dependencies or registry entries have been corrupted.
  • Lastly… you may want to try the same thing with the entire ASCOM platform for the same reasons (full uninstall and re-install… not a re-install or repair)

Thanks Ken,
I’ll take up your suggestions and report back.


Ken, your instincts were correct.
I replaced/redid the ASCOM Platform, Commander driver and iOptron firmware.
All worked well last night.


1 Like