Successful platesolve disorients Gemini2 on GM811

Has anyone had this situation happen where you successfully platesolve and somehow this throws off the mount from being able to actually slew to target and center?

This has started happening to me the past few nights and generally happens in this order-

  • Sync mount to star (ie. Deneb)
  • Connect in SGP, click ‘Center’ target.
  • Mount slews, PlateSolve2 solves the location (Which I visually confirm is indeed near actual target).
  • After solve, I get this message about being outside safety limits (this also happens if I instruct the mount to slew back to Deneb):

[12/11/20 21:24:50.639][DEBUG][Telescope Thread][CE;] ASCOM Telescope: Error in Slew : CheckDotNetExceptions ASCOM.GeminiTelescope.Telescope SlewToCoordinates System.Exception: Slew to outside of safety limits (See Inner Exception for details) (System.Exception: Slew to outside of safety limits)
at ASCOM.DriverAccess.MemberFactory.CheckDotNetExceptions(String memberName, Exception e) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 630
at ASCOM.DriverAccess.MemberFactory.MethodTargetInvocationExceptionHandler(String memberName, Exception e) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 678
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 487
at ASCOM.DriverAccess.Telescope.SlewToCoordinates(Double RightAscension, Double Declination) in C:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 1030
at r6.j9(TelescopeInformation A_0, String& A_1)

  • Final note- I doublechecked safety limits and set them very wide to rule that out.

Setup: Losmandy GM811 w/ Gemini2

SGP Log file:

Are you using a pointing model with the Gemini2? With plate solving there’s no need for a pointing model and after a while a pointing model can conflict with or confuse the plate solve pointing. So instead of using “warm restart” choose a “cold start” instead, slew to a star and do a solve and sync.

I usually do a cold start, slew to star, manually adjust and sync since it’s usually pretty off. Then that will give me a quicker solve once I platesolve, otherwise the first solve usually takes several minutes if I don’t.

Historically it hasn’t given me this problem until the last few days. I’m wondering if there’s something going on with Ascom drivers or something as I’ve been swapping out drivers for my QHY guide cam that I’d been having problems with.


I use a G11 with Gemini 1 and every few months when I begin to get pointing error messages, I check the mounts internal modeling (via ASCOM Gemini’s interface) and I see it is not all zeros, but numbers all over the place. I clear it up by uploading a base modeling profile (saved when the G11 Gemini was first configured) and that clears the modeling back to all zeros. I have found that over time, when I slew to a star and sync, that it slowly alters the modeling. I attributed that to possibly being something with Gemini1. Reading your post gave me the initial hunch that the internal modeling may be way off. My mount has very low parallax between the east and west side of the meridian, so the modeling was always zeros across the board.


Thanks for the reply Mike! I just got a response on the Gemini2 group about a thread of folks who found that a platesolve in SGP near RA0 completely throws off the model: