How ASCOM Works

If you haven't yet read Why are Drivers Important?, now is the time to do so. Before you can understand how ASCOM works, you need to understand why ASCOM is what it is. If you are unfamiliar with Object-Oriented Programming in general, the following probably won't make much sense. Also, this description applies to the ASCOM of the last 20 years, which is based on Windows COM as an inter-process communication method. As of 2019, the ASCOM Alpaca extension provides these same capabilities but using REST API technology and internet connections between clients and devices (and their drivers). The principles here still apply.


The main goal of ASCOM is to provide a driver-client layer to separate astronomy device-specifics from the application software that uses those devices. It is also a goal to make the drivers usable from all programming languages (that matter), leaving astronomy software developers the freedom to use the development tools and language(s) of their choice. One driver must be usable from any language. But each language has its own libraries, so how can one avoid needing to write the driver for some astro device multiple times, once for each language?

Without going through the evolution of the ASCOM driver architecture, the answer is to use a service built into the Windows OS called COM. Virtually all languages on Windows already come with features that provide access to Windows OS services, including COM. Thus, a driver that is a COM object is accessible from any language without needing any extra/special libraries for that language.

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.

How Drivers Work

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.

Step 1: Choosing and Configuring the Driver (one-time setup)

Since all focusers look the same to the app, it first has to give the user a chance to select the MicroGlide as the type of focuser he's using. To do this, the app uses a component that comes with the ASCOM Platform called the Chooser. Omitting the details, the app displays the Chooser and the user selects the type of focuser, MicroGlide, from a list. Once chosen, the user then clicks a Properties button. This loads the MicroGlide driver into the Chooser and asks the driver to show its configuration window. There, the user sets the COM port that the focuser is connected to, as well as anything else the MicroGlide needs for one-time configuration. The Chooser looks exactly the same regardless of which language the app is written in or which type of driver is being chosen. When the user finishes, he closes the config window and the Chooser. At this point, the MicroGlide driver saves the settings entered by the user then disappears from the system. Thus, the user's settings are remembered and need not be entered again unless something changes.

Step 2: Loading the Driver

When the user closes the Chooser, it returns the ID of the MicroGlide driver to the app. At this point the app can load the driver by making a Windows function call that loads the driver and returns a reference to the loaded driver. For example:

string ID = Helper.Choose();            # Select the driver, return its ID
ASCOM.Focuser F = CreateObject(ID);     # Load the driver, return reference
Step 3: Using the Driver

At this point, the app has a reference to the driver and using it, the app can reference any of the members of the ASCOM Standard Focuser interface. For example:

F.Link = true;                          # Connect to the focuser unit
Print F.Position;                       # Display the focuser's position
F.Move(21432);                          # Move the focuser's position
while(F.IsMoving) wait;                 # Wait until it stops moving  

Note that at no time is the app's code aware of the COM port number (or even that a COM port is being used) or the ASCII protocol that the MicroGlide uses. Thus the app is completely independent of all of the specifics of the MicroGlide. It only needs to know about the ASCOM Standard Focuser API.

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!

How COM Works

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. The Component reference is kept in a variable and used just like a reference to an object created in the app's native language. Thus the app's code see the Component as identical to one of it's own objects and uses it identically. Perhaps you can now see how powerful the Component concept is, and why it was a natural choice for ASCOM drivers.

What About the Mac and Linux?

For this, in 2019, we brought out the ASCOM Alpaca technology. You can read all about it here in the Developer section of this web site.