Ascom drivers

ASCOM driver - standards for Astronomy

The ASCOM Initiative is a loosely-knit group of developers and astronomical instrument makers that work together to bring vendor-independent
and language-independent plug-and play compatibility between astronomy software and astronomical instruments on Windows computers.
ASCOM stands for the Astronomy Common Object Model.

ASCOM Initiative Mission Statement

1: Establish a set of vendor-independent and language-independent interface standards for drivers that provide plug-and-play control of
astronomical instruments and related devices.

2: Provide general requirements and guidance for quality and behavior of drivers.

3: Promote the use of these standard drivers from any astronomy-related software.

4: Ensure that drivers are usable from the widest possible variety of programs and languages, including Windows Active Script languages
and Automation based tools.

5: Promote (but not absolutely require) open-source implementations of the drivers.

6: Promote scriptability of astronomy software without standardizing application level interfaces (which would inhibit innovation).

7: Provide general requirements for quality and behavior of application scripting interfaces, aimed at making astronomy application writers'
experiences consistent and robust.

Why are Drivers Important?

Well, step back from astronomy for a minute. When you go out and buy a new printer, you can be virtually certain that it will work with all of the programs on your computer. Likewise, when you install a new program on your computer, you can be virtually certain that it can print to your existing printer, even if it's no longer in production. We take this for granted. Printers come with a disk that installs the driver for the printer.
The driver takes care of all of the details for that particular printer, leaving all of your Windows programs with a common printer-agnostic way to
send pages to paper.

OK, back to astronomy. Until ASCOM, each astronomy program that needed to control telescopes, focusers, and so forth had to include its own code for all of the different instrument types out there. Keeping up with new instruments, supporting old ones, and dealing with firmware revisions
is a tremendous burden. Every astronomy software developer is faced with (re)writing code for every device he intends to support. Furthermore, astronomy device manufacturers are faced with having to beg an array of astronomy software vendors to support their device in the future,
delaying adoption of their new devices.

Driver API

A driver, then, is a COM object. Its API consists of a set of standard properties and methods ("members"), as defined in the relevant ASCOM
interface specification. A driver's ASCOM standard API appears within all Windows languages with the same member names and calling parameters (for methods). Permitted data types have been constrained to permit compatibility with all Windows languages.

So how does an astronomy software program ("application", or "app" ) use a driver? Let's use a simple example, a focuser, specifically a (hypothetical) MicroGlide Focuser. The MicroGlide connects to the computer via a serial port, and uses a simple ASCII command set. But the app doesn't need to know anything about the connection or the ASCII commands! It uses the ASCOM Standard Focuser API, which it sees looking into any focuser driver, including the one for the MicroGlide.

Why Use COM?

COM is built into Windows. Any language can use COM like it can display on the screen or write to a disk file. COM isn't an I/O service though, it is a Component Object service (hence the name which stands for Component Object Model). Components are a special type of object. Within any
Object Oriented Programming language, one can define and create objects, then use their members while treating the object as a black box.
But Components are different. They exist apart from the app's code, and are served by the operating system . Once loaded, though, they can be used exactly like objects created in the native language. The cool thing, though, is that one Component can be used by any program in any language. This makes Components a natural choice for drivers, which after all are things that must be usable by any program in any language!

When an app asks the OS for a Component, it uses the ID of the component. IDs are system-wide. The location on disk of the Component is not important to the application. The OS has an object broker that uses the ID to locate the Component's code and activate it. Once the Component is activated, its constructor is called. Thereafter it is ready for use by the app. Multiple instances of a Component can be used by different apps simultaneously. The OS call that activates the Component returns a reference to the activated component.

Who Owns ASCOM? - Licensing

The entire ASCOM Platform (as opposed to drivers and programs that use it) is open source, owned by the ASCOM Initiative, and licensed under
the Creative Commons Attribution-ShareAlike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

As described in A Brief History of ASCOM, the Platform was originally funded and licensed by SPACE.com. For this reason, you may see in old
Platform (and in some old driver) sources a copyright by SPACE.com. This has since been vacated, and all of the sources are now open and licensed as described above.

Download here the ASCOM Driver