Re: AP1200 operation via ASCOM drivers


Bob Denny
 

I can't pass this opportunity by... so please understand that plain
passion for progress and rightness is motivating my comments, which
follow:

First, step back from astronomy and consider the completely analogous
issue of programs needing to print (instead of slewing, syncing, and
finding out where a telescope is pointed). Many years ago, the
solution was to write code to control the few printers out there right
into every program. There were few printers, and there was a war
between printer vendors as to whose wire protocol would win. Guess
what? No one's protocol won. That was a stupid war. The same sort of
wars were fought on the battlefields of video cards, disk drives,
networking, external device connections... you name it. The OS
developers eventually beat everyone into submission with an elegant
and (in retrospect) obvious solution.

The elegant solution was to add a layer of software that decouples
client programs from devices -- drivers. Conceptually simple solution,
enormous benefit. Without layering, the internet would not exist, nor
would the display systems we now take for granted, and yes, the
printing we all require!

Take a few minutes and consider that you are a printer vendor. How can
you get people to buy your printers? Well, for one thing, they should
be usable from a wide variety of programs, right? Without that, you're
limiting your audience before you leave the gate! Forget the coolio
features you have that no one else has, without being usable from lots
of programs, you're cooked.

Now shift your focus to being a software developer. you've just
finished your masterpiece, and the boss walks in and says "But you
have to be able to print those beautiful pages, Buster. What printers
does your masterpiece support?" ... dead silence... OOPS! There are
maybe thousands of printers out there. Old ones that you can't buy any
more. And printers that are going to be released in the future. You'd
need a HUGE warehouse full of printers, infinite time to develop
control code for each one, and even then you'd have to re-release your
software every month or two to support the new printers that came out.

IMPOSSIBLE!!!!!! The problem was solved in computer ancient history.
Drivers.

Each printer vendor ships a driver with their printer. Their customers
install the driver and it magically appears in the printer chooser.
The driver is responsible for taking pages in a standard format and
turning them into ink on paper using THAT printer's control codes,
connection type, etc. Period.

In my opinion, people who make astronomy devices that purport to be
controllable by computers are in exactly the same position as printer,
disk drive, display, etc. vendors. A telescope, focuser, dome, imager,
rotator, etc. is just another peripheral as far as the software on the
computer is concerned. And the USERS see everything from the
perspective of the software they run if they are controlling these
things with their computer, right?

I understand that many of the people who supply astronomical
instruments started out catering to visual observers who operate
hands-on. Their focus was on mechanical precision and reliability.
Because the market was small and thus the production volumes were
small, they had to charge lots of money to make it as a business.

But the world has changed. People use computers and programs to
control these things now. And to make it in this business it is
essential (not optional in my opinion) to provide for computer
control. If an instrument vendor depends on every programmer to
(re)write code to support their device in all of their progrms, it's a
loser. There are special purpose applications (PE management comes to
mind) where this is essential now. But just slewing a telescope
around, syncing, parking, starting up, reading the position...these
things are common to SO MANY applications...

In a perfect world, a customer paying thousands of dollars for an
instrument that purports to be computer controllable would expect the
vendor to provide everything needed to make it possible for a variety
of programs to use that device. Not so today for astronomical instruments.

We have a situation where the makers of the mechanical stuff (the
"real" products) farm out the development and maintenance of the
microcontrollers used to -enable- (not provide!) computer control. So
they have limited control (and limited responsibility) for that part.
And now we're discussing whether or not drivers should be part of the
product, since again it purports to be computer controllable. With a
driver, the maker of the mechanical stuff has TWO semi-disinterested
parties to manage: one doing the microcontroller firmware and one
doing the driver. And maybe a third - the one who designs the
circuitry that hosts the microcontroller and provices the
communications link to the computer. So maybe THREE external people.
Do all three or four parties work in conjunction with each other, or
are they all operating separately with a loose set of objectives?

Back to the customers... they pay many thousands of dollars with the
promise that the thang iscontrollable by compuer programs. Should they
have to ask WHICH ONES? Do you ask that when buying a printer? That
would belike having to ask if the car you're thinking of buying has
the brake pedal to the left of the accelerator. But people buying
astronomical instruments seem to accept that sort of limitations.

Right now, most drivers are being developed for FREE by people how
have nointernal kn owledge of the controller operation. Can you
imagine how difficult that must be??? Yes, there are documents
describing (to some level) how the controller is SUPPOSED to work, but
due to the disconnect between the mechanical guys and the
microcontroller guys, there are quirks. The mechanical guys don't get
it, the microcontroller guys get no customer feedback to speak of,
etc. Enter the driver writer who is not affiliated at all... a VERY
DIFFICULT situation.

Now finally to the point made that making the wire protocol PRIVATE
and supplying a driver. The benefits to the device vendors are great.
They can change, improve, rework, and otherwise modify their
microcontroller, change their control codes, add new connection types
(e.g. ethernet, bluetooth, you name it!) and neither software
developers nor users need be concerned, they both just BENEFIT!

So DRIVERS BENEFIT EVERYONE: USERS, SOFTWARE DEVELOPERS, AND DEVICE
MAKERS (because the appeal of their devices is broadened and their
flexibility to innovate and improve is increased)!

So I ask that you all cut Ajai a LOT of slack. And I ask Ajai NOT do
pull the driver just because people are on your ass for stuff that
they actually paid someone else for!

My dream is to see many astronomical devices that purport to be
computer controllable be like printers. They ship with a driver, the
user installs the driver, and all of their astronomy softwre can
immediately use the new device. And device makers can make new stuff
without worrying about which programs will support it because with a
driver they all will on the day their new model ships!

-- Bob

Join main@ap-gto.groups.io to automatically receive all group messages.