The Dome Interface seems complex and confusing. Help me.

The Dome interface is designed to handle any type of enclosure including classic domes with a slit having a single shutter, split shutter, clamshells, rotatable clamshells, rolloffs, split rolloffs, well really anything. The concept is that the Dome must provide an “aperture to the sky” and a way to open and close the aperture.

The dome controller can optionally receive both azimuth and altitude commands from the application. For example, a clamshell controller that gets both azimuth and altiude could optimize the position of the leaves, minimizing exposure to wind. This could be even better if the clamshell rotates. The Dome Interface allows a driver to advertise this by returning True for both CanSetAzimuth and CanSetAltitude.

[Q] How do I provide for a roll-off roof?

[A] Return CanSetAzimuth = False and CanSetAltitude() = False. This tells the client that there is no way to adjust the opening to the sky at all. The only functions available will be those related to opening and closing the roof or clamshell to provide access to the entire sky (or not).

[Q] How do I provide for a rotating dome with a simple shutter?

[A] Return CanSetAltitude = False if you have a common dome with a rotatable opening (e.g., a slit). The client can use SlewToAzimuth() to position the slit, and of course OpenShutter() and CloseShutter().

[Q] What are the exact meanings of Azimuth and Altitude?

[A] The specified azimuth and altitude (referenced to the dome center/equator) give the position on the sky that the observer wishes to observe. It is up to the device to determine how best to locate the dome aperture in order to expose that part of the sky to the telescope.This means that the mechanical position to which the Dome moves may not correspond exactly to requested observing azimuth and altitude because the device must coordinate multiple shutters, clamshell segments or roof mechanisms to provide the required aperture on the sky.

[Q] How can I adjust the location of the opening (slit, port, clamshell leaves) to account for the geometry and offset of the optics?

[A] The Dome interface does not provide for this, as it requires current pointing information from the mount/telescope, as well as mount configuration and measurements. This is a composite task requiring information about two devices, and is thus out of scope for a Dome device by itself.

Normally this must be done by an application which connects to a Telescope and a Dome, stores relevant geometric info about both, then calculates the dome slit azimuth (and maybe altitude) for slews, as well as periodically adjusting the dome’s azimuth (“slaving”) as the telescope tracks across the sky.

[Q] OK, where can I find info on the calculations?

[A] The most general and easy to understand paper is Dome Calculation by Nicolas de Hilster. It includes provisions for side-by-side muliple OTAs. Included is a live workbench which you can use to test your calculations for a mount with side-by-side multiple OTAs. There is a discussion of this on the ASCOM Developers Forum.

[Q] I see that the Dome interface has CanSlave and Slaved properties. Why are they present if a dome controller can’t slave?

[A] There are a few integrated/combined telescope/mount/dome control systems (COMSOFT PC/TCS, DFM TCS, for example) which expose both Telescope and Dome interfaces. The slaving properties in the ASCOM Dome interface are provided for these types of control systems.