User:Arlen22/Ascom/ITelescope

This document describes the interface used by low-level telescope "driver" components as part of the Astronomy Common Object Model (ASCOM). Components that implement this interface can provide a way for programs to control various telescopes via a standard set of properties and methods.

This specification covers a simple, low-level telescope control interface for reading and writing coordinates, slewing, synchronizing and access to common controller functions. It does not provide for accessories such as focusers, flip mirrors, etc. Those sorts of things will have their own interfaces. The characteristics of this interface comply with the ASCOM Quality Guidelines, assuring consistent behavior and compatibility with the widest possible variety of Windows Automation clients.

In addition to containing features, the 2.0 specification has been clarified in numerous areas. These changes appear with this background color when they apply to existing V1 properties and methods. New properties and methods in V2.0 are not marked with the change color. For a summary of the changes and additions since the previous standard (Telescope 1.4), please refer to the Release Notes.

Remarks
Use this interface to perform basic operations on a robotic telescope. It is designed to be used by client applications that wish to provide telescope control capabilities which are device-independent. By using this interface, your application will be freed from dealing with the details of serial port control and low-level protocols in use by various telescopes.

Discovery API
Not all of the features in this interface are required to be supported by all drivers and telescopes. This permits support for a wide range of telescope types without the evils of least-common-denominator designs. Telescope includes properties that permit discovery of supported features and supported ranges of motion rates.

Many optional properties can be discovered by simply trying to read or set them. If a property is not supported, trying to read or set it will raise an exception, which you can trap.

On the other hand, some features must be discovered by reading one of the Can___ properties, all of which must be supported. These are used to discover support for features (such as slewing capabilities) which would alter the state of the telescope if called directly for discovery.

These Can___ properties are intended to declare only that the telescope supports the particular capability. They are not intended to reflect the current state of the telescope/mount. Furthermore, connecting to the telescope may be required in order to determine the capabilities to reflect in the Can___ properties (an error will be raised if a Can___ property is not available). Once connected, however, the Can___ properties must not change.

Finally, the MoveAxis method supports rate discovery. To discover the supported rates for this feature, a collection of Rate objects is provided. Each Rate object contains a maximum and minimum rate value. They may be equal, in which case the Rate object specifies a single discrete supported rate. The collections may contain more than one Rate object. Each specifies a range of rates or a single discrete rate.

Concurrency
This interface does not provide for concurrency control. In the interest of keeping things simple at this level, the architecture assumes that client applications will refrain from performing conflicting operations.

Properties
-

The (symbolic) values for AlignmentModes are: