I have been out of circulation for a while, whilst building a dome and writing a driver for it. I have just read Ron Kramer’s message in which it mentions dome slaving. I have seen slaving in the ASCOM documentation, but as I understand it, it is not necessary to implement the ‘slaved’ method in order to have a working ASCOM Dome driver.
As I will be continuing to use SGP, my question is twofold - what does slaving do (ASCOM documentation does not describe it as far as I could see), and does SGP need slaving to be implemented?
I have performed some initial testing of my driver with POTH and it works fine. Not tested with SGP yet.
There is no requirement that your dome be able to slave. However, the Slaved property must not throw a PropertyNotImplementedException on Read. It CAN throw one when an attempt to write is made.
Simply set CanSlave to False, always return False for Slaved, and return a PropertyNotImplementedException for any attempt to write to Slaved, in case something ignores CanSlave.
It’s really quite useful!
It “connects” the mount and dome. Meaning, if the dome is slaved to the mount, then it will 'follow" the mount. As the mount slews, the dome will change its azimuth/altitude as necessary to keep the shutter opening in front of the scope. It will also park the dome when the mount parks.
It’s also useful for a roll off roof implemented with the Dome driver, since SGP will recognize the difference (once told it’s a ROR) and will automatically close the roof when the mount parks, giving you the option to close the roof first, or park the mount first.
SGP does not use the CanSlave or Slaved options within the ASCOM Dome Implementation. SGP expects to be directly connected to the telescope and dome and to control them both via the slave settings which were setup inside of SGP. Using a 3rd party dome slaving utility will actually remove some control from SGP. At which point SGP would really only be controlling your telescope and not your dome.
Interesting! I just figured it did, and managed those two properties appropriately in my driver. When testing showed SGP correctly opening and closing my roof with mount park/unpark, I figured I got it right and went on!
Gee. thanks, Jared…I’ve probably had broken slaving code for a year…now I have to go check. lol
Well probably not. It just depends on if you were expecting to do the slaving and all associated math or if you had planned on leaving that up to SGP. If you had an active connection to the telescope in your dome driver, then yes, it might be broken. But if your dome driver just controls your dome then you’re likely good.
I’m sure there are dome drivers or dome hardware that directly controls or gets controlled by the telescope, but this seems to be pretty rare.
Nah…I just allow Slaved to be written, and return True for CanSlave and Slaved if it is. I just figured SGP was actually using those, and then still doing the open/close stuff. Just didn’t know SGP didn’t even bother with them.
Turns out we discussed this back in my dome attempt days…and I then promptly forgot about it when writing the driver for the ROR, and implemented those properties anyway. lol
