I’m actually writing the dome firmware and driver and I’m trying to figure out why Ron is having this problem. It may be something unique to his system as myself and another user aren’t experiencing the issue but we may also have just been lucky.
The driver has no control over slaving, doesn’t know what slaving is even. It just responds to SlewToAzimuth() commands and returns the azimuth value through the Azimuth property so it’s not immediately apparent to me how the driver could be turning off slaving when slaving is entirely within the scope of a controlling application.
My driver does not have a handy control form so it’s not a matter of non SGP originated movement commands taking the dome position out of sync with what SGP thinks should be happening. Well, unless someone opens the settings form and homes or calibrates while tracking - which would not be a driver or SGP problem. Obviously I have no control over the scope so if the handset or driver control form is issuing commands outside of SGP and that’s messing up slaving then there’s nothing I could do about that either.
The ASCOM conform tool is happy with the driver although I found out that I’d accidentally been throwing a methodnotimplemented exception on the Altitude property instead of a propertynotimplemented exception.
However, the driver may be lacking a status response or something that the application is expecting and not getting so my question is, what conditions would cause SGP to turn off slaving by itself?