ASCOM/scope xtrol
Bill J Gray Jan 29, 2003
Hi Richard, Jeff,
Rest assured that I have no plans to junk the existing scope
drivers. Ideally, I'd be happy to do so. Words fail me in
describing how unpleasant I find writing, testing, and
maintaining scope drivers. The analogy I keep giving is to
printers and video cards in the early DOS world, where support for
any new printer required learning how its innards functioned and
writing your own code to handle it. After you do that, somebody
then would come up with a new and unsupported video card or printer.
I've spent seemingly endless hours adding code for assorted
flavors of telescopes, usually with some ugly debugging cycles.
Despite this, there are still plenty of scopes not handled and
(with the exception of LX-200 compatible scopes) the actual control
offered is limited to "point the scope at this RA/dec" and "get the
scope's current RA/dec".
However... I _have_ written that code, and it works, and it
saves most existing customers from having to deal with ASCOM if
they don't want to, and gives them a "plan B" if for some reason
ASCOM does cause them grief. So I've no good reason to cast that
code into the bin bucket.
Richard, the folks using ASCOM in their products appear to be
having (usually) decent results with it. I am assuming that I'll run
into occasional driver problems. They happen with video and printer
drivers, too, but those generally (not always!) get tested by a lot
more people and their bugs get worked out more thoroughly. Still,
I'm sure that ASCOM is not going to be a panacea. It'll just be
better than what we have now (remembering that people with scopes
not supported by Guide have _nothing_.)
Jeff wrote: "...Sorry for the verbosity..." I appreciated
your comments greatly. The whole issue of interoperability is one
where I'm ignorant, and I don't mind getting advice on it at all.
"...To provide external access to every guide menu and preference
item could easily take Bill a year or more of 100% dedicated work on
that matter alone." Probably so. But providing some access to a lot
of items might (I hope!) not be nearly so difficult. The old saw
about "20% of the job takes 80% of the work" comes to mind.
"...Com port arbitration, as we have seen, is liked by some (Bill)
and disliked by others (Richard). Frankly, I hate it..."
It is indeed not entirely reliable. Guide grabs the COM port and
releases it right away mostly because this has no ill side effects.
I don't see any advantage to grabbing the COM port and hanging on
to it. And in theory, if programs play nicely together, you could
have several of them accessing the COM port and releasing it when
done, all in a smooth manner.
In practice, I doubt many programs are built that way. My thinking
of "grab, use, release" appears to be unusual. If anyone is actually
using Guide for scope control alongside another "polite",
port-releasing program, I'd be interested to hear about it.
"(...I bet Bill could write an ASCOM DSC driver using the Platform
template much faster than he could write a DSC driver in the old Guide
manner.)" Could be. I may have a better idea after I've gotten the
drivers to work from within Guide. (I'm not exaggerating when I say
that I'm not very knowledgeable here.)
-- Bill