At 10:14 26.01.01 -0700, you wrote:
>Right, I guess I wasn't clear enough about that. The single component (DLL)
>exposes 2 objects and they share the serial port.

Yes - in ASCOM we should allow several components in one DLL, but every
component must have only *one* interface (to enable scripting)...

Matthias

Bob,

----- Original Message -----
From: "Bob Denny" <rdenny@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Friday, January 26, 2001 4:33 PM
Subject: Re: [ASCOM] Possible addition to the Telescope API?


> Arne --
>
> I like the idea of the CanSetupDialog property. I've added it to the list.
>
> As for the separate ICapabilities interface, I understand your suggestion
> completely. One of my main goals for the Telescope interface is to make it
> possible to implement a driver with Windows Script Components. This means
no
> vtable binding, multi-interface components, etc. I also suggest very
strongly
> that everyone use IDispatch to talk between ASCOM components.


I was actually thinking of a separate interface in the same DLL, not a dual
interface. I should have added the coclasses in my sample IDL file to
illustrate this. Sorry that I mislead you.

>
> I am about to post a note suggesting for ASCOM in general that we not
promote
> dual interfaces, we prohibit vtable binding, and specifially allow
IDispatchEx
> and expando properties and methods for flexibility.

This would be a good thing!

>
> It's not much to add CanXXX properties for the things that "do" something.
> It's not needed for (e.g.) RightAscension. I think we've got it with
> CanSetupDialog, and if we add Mel's Tracking control, CanSetTracking.

You're right. It would probably be an overkill to have a CanXXX for every
method and property.

So, when is the Beta 3 due? :-)

>
>   -- Bob
>

Best regards,
Arne
--
Arne Danielsen
Langhussenter 15, 1405 Langhus, Norway
mailto:arne.danielsen@...
http://arnedani.home.online.no/
N59°45'14"  E10°50'38" A115m

Arne --

Thanks again for your comments!

Arne Danielsen wrote:
> I was actually thinking of a separate interface in the same DLL, not a dual
> interface. I should have added the coclasses in my sample IDL file to
> illustrate this. Sorry that I mislead you.

Ah... sorry I misunderstood.

> [dispatch only, IDispatchEx, expando, etc.] would be a good thing!

Great! I'm glad you agree.

>> So, when is the Beta 3 due? :-)

A week or two. I want to get it out for the Starry Night Pro release in a few
weeks. Starry Night will not come with the SDK, we decided that it would be
better to drive developers to the ASCOM site for the download.

   -- Bob

In the ~telescope\Source directory we can find  theSkyDriver.dll and
a corresponding test.vbs...

Set s = CreateObject("Bisque.Telescope")
Set u = CreateObject("DriverHelper.Util")
s.Connected = True
WScript.Echo u.HoursToHMS(s.RightAscension)
WScript.Echo u.DegreesToDMS(s.Declination)
' WScript.Echo s.Asynchronous
s.SlewToCoordinates u.HMSToHours("17:26:38.3"),
u.DMSToDegrees("-05:05:06.9")
WScript.Echo u.HoursToHMS(s.RightAscension)
WScript.Echo u.DegreesToDMS(s.Declination)
s.Connected = False

Q.Does this actually run standalone.. or do you need hardware connect?
If no actual hardware is required.. what software must be
present/loaded, etc?


Can this serve to front end the "rascom" dll?

Pat Browne wrote:
> In the ~telescope\Source directory we can find  theSkyDriver.dll and
> a corresponding test.vbs...
> [...]

...and the sources for this driver under Source :-) This driver connects to
the scripting interface provided by TheSky for telescope control, effectively
acting as an ASCOM-compliant "wrapper class". This enables any ASCOM-speaking
program to control any telescope that is supported by TheSky. You must first
select the desired telescope/mount type within TheSky, configure same and save
this configuration.

> Q.Does this actually run standalone.. or do you need hardware connect?

Of course, the Software Bisque components needed to operate their scripting
features must be present. They can provide definitive details on this.

When you set the ASCOM driver's Telescope.Connected property to True, the
driver calls TheSky's Telescope.Connect() method. In order for this to
succeed, a real telescope must be connected.

One thing to note: It appears that the TheSky CD-ROM must be online in the CD
drive in order for the scripting interfaces to be successfully created. I
found that if the CD is not online, you get an error "could not create server"
or something like that when you try to create the RASCOM.Telescope object.
CAUTION: This may be an old-wives' tale -- I just found it to be true here, it
may not be true in general.

> If no actual hardware is required.. what software must be
> present/loaded, etc?

If you want to test software designed to talk to the ASCOM Telescope Interface
standard, you can use the supplied telescope simulator. For example, you can
run the test script you found in the TheSky Driver directory without TheSky or
a real telescope by changing the "Bisque.Telescope" to "ScopeSim.Telescope"
(use the cscript command in a command window). The goal of the interface
standardizaton is to make this possible with no other changes to the script.

> Can this serve to front end the "rascom" dll?

The RASCOM DLL is a front-end to the Software Bisque suite of observatory
software, providing Automation style scripting. The Bisque.Telescope class
provided with the ASCOM SDK is a wrapper for the Bisque Telescope object which
is implemented within RASCOM.DLL. So, yes, it is a front end. It is
effectively an interface converter. The overhead is low. Have a look at the
sources :-)))

   -- Bob

Well, it's about time for one more cut at the Telescope SDK. The simulator has
been upgraded to have some capabilities checkboxes so developers can test
their client's resilience to telescopes with varying capabilities. A new
driver, LXP, has been added -- it supports a "generic" or least common
denominator LX200 protocol.

No one objected to Mel Bartels' suggestion for an additional property to turn
tracking on and off, so I'm going to add it.

   Property:    Tracking           Boolean: True  = tracking on
                                            False = tracking off

                CanSetTracking     Boolean: True  = Can turn tracking on/off
                                            False = Only read state of tracking

Presumably, on mounts for which CanSetTracking is False, the Tracking property
would always be true. Of course you could implement a physical tracking switch
on the controller and reflect its setting in the Tracking property.

If there are no objections within the next day, I'll implement this for a new
release this week.

   -- Bob

As a post-script to the addition of Tracking & CanSetTracking, the current
spec says that RightAscensionRate can be used to turn tracking on and off, and
by inference to tell whether tracking is enabled. I forgot about this, and
even though it was my idea originally I don't like it now and will remove that
wording. Mel's suggestion wins. Also RightAscensionRate will be described as
an *offset* from sidereal rate.

   -- Bob

Hello all

this is my first mail on this group.

I am amateur astronomer by passion, and my daytime job is software
developer/analyst. I am currently working on a robotic observatory
control software project (remote operation of telescopes, CCDs, and
other hardware).

What you are trying to achieve is in my view very important for the
community, and for the future of amateur astronomy. I have to say I am
impressed.

I have one regret though : I could not really enjoy the benefits of your
work, because my software will need to run on Linux, not on windows.

If I am wrong, and if there is a possibility to use ASCOM compliant
objects on Linux, can you please let me know ? If I am right, can you
please indicate whether there is a chance of having the scope of your
project extended to cover the Linux platform as well in the near future
?

Thanks a lot/best regards

PJ Pallez

At 15:19 07.02.01 +0100, you wrote:
>I have one regret though : I could not really enjoy the benefits of your
>work, because my software will need to run on Linux, not on windows.

You are right.

>If I am right, can you
>please indicate whether there is a chance of having the scope of your
>project extended to cover the Linux platform as well in the near future ?

I've just attended the Microsoft developer conference "MSDN Technical
Summit .NET" here in Germany (with bill Gates... :)
http://www.microsoft.com/germany/msdn/technicalsummit/
and heard that COM is dead. Yes, please read again - COM is dead.
And that's by far not all: MFC is dead, ATL is dead, C++ is half dead...

They're in the process of shipping a new Java-like platform, ".NET".
That means that there is one single framework (classes) for all
languages (VB, C++, the new language C# and so on). The Common Language
Runtime CLR reads the precompiled (and language as well as machine
independent) "intermediate language" and executes it.

I also see the advantages of such a common framework - you have to learn
it just once and that's it ! Then you can program in the language of your
choice. And it's *fully* object oriented - every integer is an object !!

But I don't know if developers will accept such a major change...

What does that have to do with Linux ? Yes - maybe there will be a
"Common Language Runtime" for Linux in the future ! Just imagine: you
could take your windows app and run it on Linux *whithout changes*.
Just like Java.

I think we could easily transfer ASCOM to .NET because ASCOM is just
interface definitions.

Let's see what the future brings...   :)

The best resource to get informed about .NET and to stay up to date
is: http://www.microsoft.com/net/

Matthias

>>I have one regret though : I could not really enjoy the benefits of your
>>work, because my software will need to run on Linux, not on windows.

>You are right.

Correct me if I am wrong, but I thought that COM was supported on several
UX-like platforms. Of course AFAIK none of the ASCOM partners is
programming COM for those platforms, so that's somewhat academic.

>I've just attended the Microsoft developer conference "MSDN Technical
>Summit .NET" here in Germany (with bill Gates... :)

I'm glad you've been able to get something (apparently) concrete about the
dotnet initiative, which has proven to be an amorphous and undefined blob
to us vertical analysis and infrastructure people. I've had five or six
people at Microsoft completely unable to tell me what dotnet actually is.
I'll read the URL's you've sent, they look promising.

>Yes, please read again - COM is dead.

I'm sure they'd like to think that. I suspect it won't *really* be dead yet
for another three to five years (MS will, I think, still ship COM
components until then), and I guarantee that I will be supporting COM in
deployment for the next ten or more. Of course any additional
interoperability that dotnet provides will be very welcome indeed.


--
Jeff Medkeff
Hereford, Arizona

Matthias --

>Yes, please read again - COM is dead.

Typical Microsoft-talk -- But .NET is a really nice idea, and it looks
promising. They are betting the farm on it too. They got aced out of the
"co-opt and corrupt" (embrace and extend) Java plan, that took 3 years to die
finally. Yes, we can transfer our (by then well formed) ideas and experience
to .NET. I think Jeff has it about right -- if it succeeds, it will be
commonplace in 3 -5 years. for now, we should stick to Automation and enjoy
the benefits of integration with today's technology.

> Let's see what the future brings...   :)

Indeed! I think we should definitely stay tuned in. If Microsoft does what Sun
didn't, namely provide excellent UI implementation tools, they may have a
winner on their hands.

   -- Bob

matthias.busch@... wrote:

> and heard that COM is dead. Yes, please read again - COM is dead.
> And that's by far not all: MFC is dead, ATL is dead, C++ is half dead...

Yes, and OLE is already dead.  Microsoft always provides backwards compatibility
with new technologies, and then gradually makes the old stuff fade away over
many years.  They aren't going to kill COM support any time soon.

Doug

--
Doug George

=============================================================
      Diffraction Limited                Cyanogen Division
      Industrial Products                Astronomy Products
http://www.diffractionlimited.com     http://www.cyanogen.com
  dgeorge@...        dgeorge@...
     Phone:  (613) 225-9852            Sales:  (613) 225-2732
      Fax:  (613) 225-9688              Fax:  (613) 225-9688
=============================================================

Hello all --

The ASCOM Telescope Driver SDK Beta 4 is now available at:

   http://ASCOM-Standards.org/downloads.html

This build incorporates Mel Bartels' tracking control suggestion, and has
additional usability improvements to the scope simulator. Please give it a
workout. If it looks good, in a couple of weeks we'll vote on the interface
and if it passes we'll have our first real ASCOM standard!

   -- Bob

P.S. - The new download provider uses HTTP instead of FTP, and does not have
the reverse DNS requirement. We apologize in advance for the problems you may
have had in the past with downloading. The new site has experienced
intermittent problems in the last couple of days and I messed up the new DNS
settings when we switched over :-((( but that is fixed now. If you have
problems with downloading, come back in 10 minutes or so.

At 19:24 07.02.01 -0500, you wrote:
>I've had five or six
>people at Microsoft completely unable to tell me what dotnet actually is.

The same with me before the conference, I couldn't tell you, too...
But that event cleared things up for me. It was rather technical,
they often showed code and the new development environment.

>>Yes, please read again - COM is dead.
>
>I'm sure they'd like to think that. I suspect it won't *really* be dead yet
>for another three to five years (MS will, I think, still ship COM
>components until then), and I guarantee that I will be supporting COM in
>deployment for the next ten or more.

That's what I think, too. I didn't mean that they won't support COM
any longer, but .NET will completely *replace* COM...
Everything is simpler, e.g. you no longer need the registry, just
copy the component files to the hard disk and that's it !

I was very impressed of the new things, namely the underlying
framework. But on the other hand I think of my daytime job (software
industry) - will we change everything (COM, MFC) ? Also my own
software "EasySky" - everything pure MFC...

Matthias

I would just like to give you an update on the progress of my Vixen
SkySensor 2000-PC telescope driver.
Last weekend I updated the driver to comply with the beta 4 release of the
Telescope interface. I also finished unit testing the driver and everything
looks very promising!

I will be away for a few days, but will hopefully be able to start
integration testing with Starry Night Pro this Sunday

Best regards,
Arne
--
Arne Danielsen
mailto:arne.danielsen@...
http://arnedani.home.online.no/
N59°45'14"  E10°50'38" A115m

Arne --

Very exciting!! And good job getting things sync'ed with beta 4. I know te
pace of changes is rather fast, but we need to get this right.

I have forwarded the latest Starry Night ASCOM plugin to you in a private
email, to make sure you do have the latest.

   -- Bob

Thanks Bob!

Sorry about the late reply! I have been away for a couple of days.

Last Sunday I did some preliminary testing of my SS2K driver using Starry
Night Pro and the plugin you supplied me. Everything looked very good and I
experienced no crashes or odd behaviours. I will be away for a couple of
days (again), but will hopefully be able to do a more thorough test this
Sunday. After that I will send you the updated driver to be included in the
SDK.

Best regards,
Arne
--
Arne Danielsen
Langhussenter 15, 1405 Langhus, Norway
mailto:arne.danielsen@...
http://arnedani.home.online.no/
N59°45'14"  E10°50'38" A115m
----- Original Message -----
From: "Bob Denny" <rdenny@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Friday, February 16, 2001 3:10 PM
Subject: Re: [ASCOM] ASCOM Telescope driver for Vixen SkySensor 2000-PC


> Arne --
>
> Very exciting!! And good job getting things sync'ed with beta 4. I know te
> pace of changes is rather fast, but we need to get this right.
>
> I have forwarded the latest Starry Night ASCOM plugin to you in a private
> email, to make sure you do have the latest.
>
>   -- Bob
>
>
> To unsubscribe from this group, send an email to:
> ASCOM-Talk-unsubscribe@egroups.com
>
>
>
>

Arne --

Great news! Thanks for doing this, and thanks for the feedback on the Starry
Night plug-in.

   -- Bob

Greetings!

I have released the Kepler Ephemeris Engine 1.0 for general use. A few people
have been successfully using the 0.2 alpha version for 9 months, and I re-ran
my tests with fresh data from the MPC. I also updated the HTML Help
documentation. All looks well.

Kepler plugs into NOVAS-COM V2 to provide the ephemeris engine needed to get
precise positions for major and minor planets. To get positions for minor
planets, you must supply the orbital elements. Major planet ephemerides are
built in. Kepler does not integrate orbits from one epoch to another, so for
the highest accuracy, you must integrate the orbit prior to setting the
orbital elements properties of Kepler.

Kepler 1.0 is available at the ASCOM web site, in the Downloads section.

   http://ASCOM-Standards.org/Downloads.html

The next release of PinPoint (2.1) will contain an enhanced AcquireImages
script that accepts MPC 1-line orbital elements and computes the position of
the minor planet at the time of exposure.

If you're interested in using Kepler, have a look at the MPCEphem.js script
that is included with it. It generates an MPC style ephemeris from a list of
target designations. It includes code to fetch orbital elements from the MPC
via its web interface.

   -- Bob

Bob,

There must be some problem with the Kepler Orbit download link. Take a look.

Regards,

Cristovao Jacques

Bob,

The Kepler link appears to be broken.

Ajai.

   ----- Original Message -----
   From: Bob Denny
   To: ASCOM Talk
   Sent: Saturday, March 03, 2001 01:49
   Subject: [ASCOM] ANN: Kepler 1.0 Released


   Greetings!

   I have released the Kepler Ephemeris Engine 1.0 for general use. A few people
   have been successfully using the 0.2 alpha version for 9 months, and I re-ran
   my tests with fresh data from the MPC. I also updated the HTML Help
   documentation. All looks well.

   Kepler plugs into NOVAS-COM V2 to provide the ephemeris engine needed to get
   precise positions for major and minor planets. To get positions for minor
   planets, you must supply the orbital elements. Major planet ephemerides are
   built in. Kepler does not integrate orbits from one epoch to another, so for
   the highest accuracy, you must integrate the orbit prior to setting the
   orbital elements properties of Kepler.

   Kepler 1.0 is available at the ASCOM web site, in the Downloads section.

     http://ASCOM-Standards.org/Downloads.html

   The next release of PinPoint (2.1) will contain an enhanced AcquireImages
   script that accepts MPC 1-line orbital elements and computes the position of
   the minor planet at the time of exposure.

   If you're interested in using Kepler, have a look at the MPCEphem.js script
   that is included with it. It generates an MPC style ephemeris from a list of
   target designations. It includes code to fetch orbital elements from the MPC
   via its web interface.

     -- Bob

         Yahoo! Groups Sponsor

                  The Perfect StormThe PatriotU571Erin BrockovichAmerican
BeautyThe MatrixMore Movies...



   To unsubscribe from this group, send an email to:
   ASCOM-Talk-unsubscribe@egroups.com



   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]

OOPS! The link is fixed. Sorry, that was in the wee hours of the morning :-)

   -- Bob

Cristovao Jacques wrote:
> There must be some problem with the Kepler Orbit download link.
> Take a look.

Ajai Sehgal wrote:
> The Kepler link appears to be broken.

Hi,

We're trying to put the pieces together, now that we have a Digital
Domeworks Homedome
delivered.

Question: Given we have an ASCOM compliant TheSky driver (from ACP), and
assuming the
homedome can be driven directly from theSky, does this mean we can use the
ACP ASCOM compliant driver to talk to the homedome?

If the ASCOM interface is incomplete - what kind of effort is required to
complete this?


[Non-text portions of this message have been removed]

If I understand your question -- the "ASCOM compliant driver" is a telescope
control driver. It exposes an inteface ("Telescope") that is meant for
telescope control. The TheSky teelscope driver exposes Telescope while
connecting to the scripting interface in TheSky and using their flavor
telescope commands.

There is no defined "Dome" interface for ASCOM -- yet. Personally, I'm not
thrilled with the dome control interface exposed by TheSky. The most annoying
part is the need to call a method (GetAzEl) before accessing the dAz and dEl
properties. Also, the property names are counter to one of the ASCOM
requirements (no "programmer talk", in this case the polish notation). To me,
Dome.Azimuth and Dome.Elevation properties would be more in line with what a
non-technoid would expect. We're shooting for people who are comfortable in
VBA, like an Excel macro writer.

Anyway, someone needs to define the ASCOM "DOME" object. The interface needs
to be in line with the ASCOM guidelines. Then someone needs to write a
reference implementation. That could take the form of a VB-based wrapper for
the TheSky dome interface ("Bisque.Dome"), similar to the Bisque.Telescope
driver that I think you are referring to.

I hope this makes some sense.

   -- Bob

THis makes a lot of sense.
I don't know if we(smartsoftees) have the savy to produce a reference
implementation for an ASCOM wrapper; your comments about the same are pretty
much what I expected.

It means that for our smartscope project, we will have to talk to the dome
directly,
but use ACP for everything else.
On the other hand, I think there is some slaving mode off the telescope -
  where theSky writes a file that ddw reads.. we'll have to see..


-----Original Message-----
From: Bob Denny [mailto:rdenny@...]
Sent: Tuesday, March 06, 2001 1:41 AM
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] - ascom homedome?


If I understand your question -- the "ASCOM compliant driver" is a telescope
control driver. It exposes an inteface ("Telescope") that is meant for
telescope control. The TheSky teelscope driver exposes Telescope while
connecting to the scripting interface in TheSky and using their flavor
telescope commands.

There is no defined "Dome" interface for ASCOM -- yet. Personally, I'm not
thrilled with the dome control interface exposed by TheSky. The most
annoying
part is the need to call a method (GetAzEl) before accessing the dAz and dEl
properties. Also, the property names are counter to one of the ASCOM
requirements (no "programmer talk", in this case the polish notation). To
me,
Dome.Azimuth and Dome.Elevation properties would be more in line with what a
non-technoid would expect. We're shooting for people who are comfortable in
VBA, like an Excel macro writer.

Anyway, someone needs to define the ASCOM "DOME" object. The interface needs
to be in line with the ASCOM guidelines. Then someone needs to write a
reference implementation. That could take the form of a VB-based wrapper for
the TheSky dome interface ("Bisque.Dome"), similar to the Bisque.Telescope
driver that I think you are referring to.

I hope this makes some sense.

   -- Bob

To unsubscribe from this group, send an email to:
ASCOM-Talk-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




[Non-text portions of this message have been removed]

At 11:40 PM 3/5/2001 -0700, you wrote:


>(no "programmer talk", in this case the
>polish notation).

I've added a few non-astronomical software-hardware widgets that use the
Component Object Model to our mix at 701 over the last few months, and this
sort of thing is not uncommon. Although I thought it was called Hungarian
notation, its ubiquitous - properties that are fsTm (the time, as a
formatted string), x35Tm (the time, as an ActiveX date/time in a machine
locale format indicated by the "35" which is referenced to a lookup table
in the product's help file), and vaPTSols (variant array Possible Tick
Solutions, which picks the array element based on a couple properties that
are settable separately) are among the doozies that I remember. This is
with a GPS based time reporting unit.

I suppose when it comes to the US Military contract that birthed this
device, its fine to leave the properties and methods in a formal notation
system that the systems analysts will understand. When it comes to getting
astronomers to use this kind of technology, it is an indication that the
programmer just doesn't get it.

>To me, Dome.Azimuth and Dome.Elevation properties
>would be more in line with what a non-technoid would
>expect.

As r/w doubles this would be a good start. (I.e., by reading them you could
see where the dome is now, by writing to them you can tell the dome to go
there.) I would suggest a minimum implementation would also have to include:

Dome.DomeInMotion   (read only, t-f)
Dome.Slit           (r/w, open or closed)
Dome.SlitInMotion   (read only, t-f)
Dome.Flap           (r/w, up or down)
Dome.FlapInMotion   (read only, t-f)
Dome.EmergencyStop  (r/w, t-f)

Alternatively, or congruent to the above, we might find Dome.Ready (read
only, t-f, set to True when the dome is done with whatever it was last
doing whether that involved the rotator, flap, or slit) to be useful, as
something like (with ACP in mind):

Do While Not Dome.Ready
   Util.WaitForMilliseconds 1000
Loop

would be a very common programmatic task.

These method names are just suggestions, of course; its the functionality
that I'm interested in. We may also want to be able to look at and possibly
set the direction of dome motion with a property.

This topic has been on my mind recently, in light of 701's recent purchase
of a 32" R-C (wisely, in my opinion, the idea of C-14's on precision German
mounts was chucked). Although the system will have first-order control
through PC-TCS, which provides excellent dome integration, alternatives are
always good.

>Anyway, someone needs to define the ASCOM "DOME"
>object. The interface needs to be in line with
>the ASCOM guidelines.

I'll offer the above as a start on this. Probably a developer should handle
the reference implementation, but I'd volunteer to work with whoever is
interested once 701's dome is raised.



--
Jeff Medkeff
Sierra Vista, Arizona
(or somewhere.)

Bob,

>>Personally, I'm not
>>thrilled with the dome control
>>interface exposed by TheSky

TheSky does not expose any dome control.  Software Bisque's dome control is
handled through Automadome.

>>The most annoying part is the need to
>>call a method (GetAzEl) before accessing the dAz and dEl
>>properties.
This way, a single method latches *both* azimuth and elevation.

>>Also, the property names are
>>counter to one of the ASCOM
>>requirements

Software Bisque named its methods and properties long before the ASCOM
requirements were even around.  Never-the-less, I might still argue that the
Automadome's method and property names meet the requirement "4. Property and
method names must be user friendly..."

Matthew L. Bisque


-----Original Message-----
From: Bob Denny [mailto:rdenny@...]
Sent: Monday, March 05, 2001 11:41 PM
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] - ascom homedome?


If I understand your question -- the "ASCOM compliant driver" is a telescope
control driver. It exposes an inteface ("Telescope") that is meant for
telescope control. The TheSky teelscope driver exposes Telescope while
connecting to the scripting interface in TheSky and using their flavor
telescope commands.

There is no defined "Dome" interface for ASCOM -- yet. Personally, I'm not
thrilled with the dome control interface exposed by TheSky. The most
annoying
part is the need to call a method (GetAzEl) before accessing the dAz and dEl
properties. Also, the property names are counter to one of the ASCOM
requirements (no "programmer talk", in this case the polish notation). To
me,
Dome.Azimuth and Dome.Elevation properties would be more in line with what a
non-technoid would expect. We're shooting for people who are comfortable in
VBA, like an Excel macro writer.

Anyway, someone needs to define the ASCOM "DOME" object. The interface needs
to be in line with the ASCOM guidelines. Then someone needs to write a
reference implementation. That could take the form of a VB-based wrapper for
the TheSky dome interface ("Bisque.Dome"), similar to the Bisque.Telescope
driver that I think you are referring to.

I hope this makes some sense.

   -- Bob

To unsubscribe from this group, send an email to:
ASCOM-Talk-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

To those interested:

Software Bisque has posted an updated CCDSoft beta release, beta 9.

Be sure to read about and try our new @Focus technology (pronounced "at
focus") for automatically focusing your CCD camera using a mechanical
focuser. Enjoy!

CCDSoft Version 5 Web Page:
http://www.bisque.com/CCDSoftV5

Matthew L. Bisque

"Matthew L. Bisque" wrote:
> TheSky does not expose any dome control. Software Bisque's dome control is
> handled through Automadome.

Sorry about that. I got my information from the RASCOM help file, Dome Object,
Remarks:

   "The dome object contains methods and properties that access
    TheSkys (via Automadome) dome control."

This led me to believe that Automadome is a go-between, and TheSky is where
the dome control is. I was just trying to be correct in my wording.

> This way, a single method latches *both* azimuth and elevation.

Low level details that I personally don't think end users should see. If there
are optimizations to be made in reading telemetry, it should be under the
covers. For example you could keep track of the last time the telemetry was
read from the  hardware, and if x amount of time has elapsed re-read it when
either item is accessed. Otherwise, jsut  return shadow values fo the last
data that was read.

Just a suggestion. The same would go for the Telescope object, which similarly
exposes the latching.

   -- Bob

I took the liberty of posting this useful tidbit from Jeff Medkeff on the DC-3
Support list, where there are some scripting discussions. Most of the
discussions there are specific to DC-3 products, but this seemed useful in
general!

   -- Bob

[Non-text portions of this message have been removed]