Are the applications that are communicating using an ASCOM driver?  I
suspect not.

If so then try some other application that uses ASCOM, such as the free
Cartes du Ciel. If this works then it demonstrates that the ASCOM driver
isn't the problem.

If it doesn't then try to make the serial connection directly from a
real serial port on the PC to the scope and see if that works with ASCOM.

This is trying to split the problem into smaller problems so you can
find out what is happening.

Chris

rcx400 wrote:
> Is there anything special I need to know or do when connecting MaximDL
> to my RCX400 via either the RCX400 or LX200GPS/R drivers?  I can
> connect via The Sky and AutoStar Suite V5, but I can't get MaximDL or
> MaxPoint to communicate using the exact same setup.  I've probably
> skipped an important step, or forgotten to configure something, but I
> can't seem to figure out what it is.
>
> I'd like to configure MaxPoint to talk to my Scope (preferably via
> RCX400 driver, but via LX200GPS/R driver if that's necessary), and
> then connect MaximDL to MaxPoint.  I set the Comm port in the driver,
> but there's no connection at all.  I know the assembled USB-Serial
> adapter cable plugged into the DB9-RJ11 serial cable plugged into the
> RCX base RS232 port works since it links TheSky and AutoStar Suite
> just fine.  I assume MaximDL and MaxPoint can use the same serial
> cable design?
>
> Does this sound familiar to anyone?  If so, can you give me a shove in
> the right direction?  Its annoying to have a $600 software pkg not
> function, especially when I KNOW its gotta me my error.
>
> Sorry to be asking such PITA questions, but this group can probably
> save me a lot of time scratching my head at the cost of being publicly
> embarrassed by the eventual solution. :)
>
> Rod
>
>
> ------------------------------------
>
> For more information see http://ASCOM-Standards.org/.
>
> To unsubscribe from this group, send an email FROM THE ACCOUNT YOU USED TO
SUBSCRIBE(!) to:
> ASCOM-Talk-unsubscribe@yahoogroups.com
>
> Yahoo! Groups Links
>
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.173 / Virus Database: 270.7.5/1701 - Release Date: 30/09/2008
19:08
>

Thanks, Chris.  I shall reconfigure to ensure updates.  If the mount
can't cope with that (the on-board electronics are 'unsophisticated')
then I think the only alternative is to use the Park / Unpark method
and 'On Unpark' get the new location.

Ben


--- In ASCOM-Talk@yahoogroups.com, "Chris Peterson" <cpeterson@...>
wrote:
>
> Hi Ben-
>
> It is unusual for a mount to send any information back to an
application
> except in reply to a request. That's how the ASCOM functions are
defined.
> Most applications can be configured to request the mount position
at some
> interval, typically every few seconds. If the ASCOM driver doesn't
receive a
> valid response (usually within some timeout period, depending on
the
> driver), it will raise an error the application should handle.
Given the
> very low bandwidth involved in polling the mount every few seconds,
I doubt
> you'll have any problems.
>
> There should be nothing to buffer. If the mount gets a request for
the
> position, it simply returns the current position, independent of
any
> commands involved in getting it there.
>
> Chris
> ________________________________
> Chris L Peterson
> http://www.cloudbait.com
>
>
> ----- Original Message -----
> From: "ben.ealing" <ben.ealing@...>
> To: <ASCOM-Talk@yahoogroups.com>
> Sent: Tuesday, September 30, 2008 1:36 PM
> Subject: Re: [ASCOM] ideas: ascom-compliant handover to 'on-board'
mount
> controls?
>
>
> > Chris, William, Joe, and Bob,
> >
> > Thanks very much for your responses.
> >
> > The difficulty arises here because the telescope is controlled
via a
> > bluetooth connection.  That's very nice (no wires to trip over
etc)
> > but it does mean that I cannot be confident that, for example, a
> > quick series of 'on-board' commands which alter the scope's
position
> > will all be transmitted over bluetooth back to the software.  As a
> > result, I have currently designed it so that the mount stores all
the
> > movements and then transmits a single piece of data back to the
PC.
> >
> > I think all have basically said: just ensure the mount can handle
> > commands from either source (PC or on-board control) and ensure
that
> > the data is transmitted back sufficiently frequently to ensure
> > synchronisation.  That may or may not be possible (!) depending on
> > the bluetooth connection.
> >
> > The only two alternatives, I think, are to (i) follow the earlier
> > generation nexstar approach and temporarily disable one or the
other;
> > or (ii) connect / disconnect scope - which is so cumbersome I
won't
> > do.
> >
> > Thank you very much for your input.  Very helpful to have better
> > minds considering this.  Will ponder some more....
> >
> > Ben
>

You do not need to continually monitor the mount operations and make
sure all the mount position changes get transmitted back.

Instead, when you are done with the hand control, have your software
check the current values of the Telescope.Altitude and Telescope.Azimuth
properties or the Telescope.Declination and Telescope.RightAscension
properties.

-William
-----Original Message-----
From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On
Behalf Of ben.ealing
Sent: Tuesday, September 30, 2008 3:36 PM
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] ideas: ascom-compliant handover to 'on-board' mount
controls?

Chris, William, Joe, and Bob,

Thanks very much for your responses.

The difficulty arises here because the telescope is controlled via a
bluetooth connection.  That's very nice (no wires to trip over etc) but
it does mean that I cannot be confident that, for example, a quick
series of 'on-board' commands which alter the scope's position will all
be transmitted over bluetooth back to the software.  As a result, I have
currently designed it so that the mount stores all the movements and
then transmits a single piece of data back to the PC.

I think all have basically said: just ensure the mount can handle
commands from either source (PC or on-board control) and ensure that the
data is transmitted back sufficiently frequently to ensure
synchronisation.  That may or may not be possible (!) depending on the
bluetooth connection.

The only two alternatives, I think, are to (i) follow the earlier
generation nexstar approach and temporarily disable one or the other; or
(ii) connect / disconnect scope - which is so cumbersome I won't do.

Thank you very much for your input.  Very helpful to have better minds
considering this.  Will ponder some more....

Ben




--- In ASCOM-Talk@yahoogroups.com, "Chris Peterson" <cpeterson@...>
wrote:
>
> Hi Joe-
>
> Yeah, I'm not surprised there's something like that out there. But
it
> certainly isn't common, and if Ben does have control over the mount
design,
> it would be excellent to avoid such a mode of operation.
>
> Of course, if the two must be mutually exclusive, I don't see much
option
> except to disconnect the driver during manual operation. Simple, if
a bit
> cumbersome.
>
> Chris
>
> *****************************************
> Chris L Peterson
> Cloudbait Observatory
> http://www.cloudbait.com
>
>
> ----- Original Message -----
> From: "Joe Shuster" <jshuster42@...>
> To: <ASCOM-Talk@yahoogroups.com>
> Sent: Tuesday, September 30, 2008 8:51 AM
> Subject: RE: [ASCOM] ideas: ascom-compliant handover to 'on-board'
mount
> controls?
>
>
> > Chris,
> >
> > FYI: I have a couple of first generation NexStar mounts. That
firmware
> > forced the user to switch to "RS232 mode" to allow computer
connection.
> > That
> > rendered the handcontroller idle until the user cancelled that
mode. (I
> > suspect that style of user abuse was abandoned by Celestron in
future
> > implementations of the NexStar mounts.)
> >
> > Joe
>



------------------------------------

For more information see http://ASCOM-Standards.org/.

To unsubscribe from this group, send an email FROM THE ACCOUNT YOU USED
TO SUBSCRIBE(!) to:
ASCOM-Talk-unsubscribe@yahoogroups.com

Yahoo! Groups Links

The laptop has no serial port, so I can't test direct.  And you're
right, the apps that work don't run through ASCOM drivers.

I wasn't so much looking for a troubleshooting strategy as hoping
maybe there was an undocumented configuration tip or error that when
taken into account makes the connection work.  Too many others already
use these pieces of software successfully for me to believe I got
corrupted copies or a buggy CD.

Because I run under Vista I keep wondering if there is a permissions
problem with drivers or software.  I've set the executeables to run as
Administrator, but maybe there's something else that needs doing?

Thanks for your input, tho, Chris... every little bit helps!
Rod

--- In ASCOM-Talk@yahoogroups.com, Chris Rowland
<chris_group_mail@...> wrote:
>
> Are the applications that are communicating using an ASCOM driver?  I
> suspect not.
>
> If so then try some other application that uses ASCOM, such as the free
> Cartes du Ciel. If this works then it demonstrates that the ASCOM
driver
> isn't the problem.
>
> If it doesn't then try to make the serial connection directly from a
> real serial port on the PC to the scope and see if that works with
ASCOM.
>
> This is trying to split the problem into smaller problems so you can
> find out what is happening.
>
> Chris
>
> rcx400 wrote:
> > Is there anything special I need to know or do when connecting MaximDL
> > to my RCX400 via either the RCX400 or LX200GPS/R drivers?  I can
> > connect via The Sky and AutoStar Suite V5, but I can't get MaximDL or
> > MaxPoint to communicate using the exact same setup.  I've probably
> > skipped an important step, or forgotten to configure something, but I
> > can't seem to figure out what it is.
> >
> > I'd like to configure MaxPoint to talk to my Scope (preferably via
> > RCX400 driver, but via LX200GPS/R driver if that's necessary), and
> > then connect MaximDL to MaxPoint.  I set the Comm port in the driver,
> > but there's no connection at all.  I know the assembled USB-Serial
> > adapter cable plugged into the DB9-RJ11 serial cable plugged into the
> > RCX base RS232 port works since it links TheSky and AutoStar Suite
> > just fine.  I assume MaximDL and MaxPoint can use the same serial
> > cable design?
> >
> > Does this sound familiar to anyone?  If so, can you give me a shove in
> > the right direction?  Its annoying to have a $600 software pkg not
> > function, especially when I KNOW its gotta me my error.
> >
> > Sorry to be asking such PITA questions, but this group can probably
> > save me a lot of time scratching my head at the cost of being publicly
> > embarrassed by the eventual solution. :)
> >
> > Rod

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the ASCOM-Talk
group.

   File        : /SS2K Setup_516b.exe
   Uploaded by : laurie_yates2001 <laurie@...>
   Description : SkySensor 2000 driver installer, version 5.1.6b. Allows early
binding

You can access this file at the URL:
http://groups.yahoo.com/group/ASCOM-Talk/files/SS2K%20Setup_516b.exe

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

laurie_yates2001 <laurie@...>

Hi Rod,

I would stay away from the RCX400 driver if I were you.  If you pick
the wrong COM port or there is a communication error, the driver will
take two or three minutes to find out.  In the mean time, MaxIm DL
will be completely unresponsive.  I haven't ever needed any of the
features that the RCX400 driver provides.  Moreover it is totally
unsupported.  On the other hand, the LX200GPS/R driver works fine
with the RCX400.

Hilary

--- In ASCOM-Talk@yahoogroups.com, "rcx400" <rodsrun@...> wrote:
>
> Is there anything special I need to know or do when connecting
MaximDL
> to my RCX400 via either the RCX400 or LX200GPS/R drivers?  I can
> connect via The Sky and AutoStar Suite V5, but I can't get MaximDL
or
> MaxPoint to communicate using the exact same setup.  I've probably
> skipped an important step, or forgotten to configure something, but
I
> can't seem to figure out what it is.
>
> I'd like to configure MaxPoint to talk to my Scope (preferably via
> RCX400 driver, but via LX200GPS/R driver if that's necessary), and
> then connect MaximDL to MaxPoint.  I set the Comm port in the
driver,
> but there's no connection at all.  I know the assembled USB-Serial
> adapter cable plugged into the DB9-RJ11 serial cable plugged into
the
> RCX base RS232 port works since it links TheSky and AutoStar Suite
> just fine.  I assume MaximDL and MaxPoint can use the same serial
> cable design?
>
> Does this sound familiar to anyone?  If so, can you give me a shove
in
> the right direction?  Its annoying to have a $600 software pkg not
> function, especially when I KNOW its gotta me my error.
>
> Sorry to be asking such PITA questions, but this group can probably
> save me a lot of time scratching my head at the cost of being
publicly
> embarrassed by the eventual solution. :)
>
> Rod
>

--- In ASCOM-Talk@yahoogroups.com, "rcx400" <rodsrun@...> wrote:
>
> The laptop has no serial port, so I can't test direct.  And you're
> right, the apps that work don't run through ASCOM drivers.
>
> I wasn't so much looking for a troubleshooting strategy as hoping
> maybe there was an undocumented configuration tip or error that when
> taken into account makes the connection work.  Too many others
> already use these pieces of software successfully for me to believe
> I got corrupted copies or a buggy CD.
>
> Because I run under Vista I keep wondering if there is a permissions
> problem with drivers or software.  I've set the executeables to run
> as Administrator, but maybe there's something else that needs doing?

Try:
.. close out all the programs & right click on the shortcut icon
  & click on properties.
Go to the compatability tab & check the "run in XP compatability mode"
  & save/close.

(borrowed from a recent Mike Weasner's site posting re: AutostarSuite)

good luck
--dick

I am writing an ASCOM focuser client using the XYDispDriver from
CodeProject for COM operations (VC++).  It appears that the ASCOM
Helper app is only accessible if the program is running with
administrator privileges under windows Vista (and probably XP as
well).  When running under user privileges I get the following error
from the helper app.

Run-time error '-2147220416 (80040440)': Failed to open/create root
registry key (5)

Is there a way to get the helper and ASCOM to work without having to
run as an administrator?

Thanks,
Joe Colosi

Why not defining a class inherited from ICamera? That way all methods
and properties of the parent class are readily available, plus the ones
defined in the child class.

Antoine

Robin Lauryssen-Mitchell a écrit :
>
> To partly answer my own question (isn’t posting emails a great way to
> get ideas! J) I could always add ‘Implements ICamera’ inside my own
> class and copy over all the methods and properties. There doesn’t
> appear to be anything illegal about having two ‘Implements’ calls
> inside one class. Horrible duplication of course, but it might just be
> ‘cleaner’ than my original approach.
>
> Having fun
>
> Robin
>
> -----Original Message-----
> *From:* ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com]
> *On Behalf Of *Robin Lauryssen-Mitchell
> *Sent:* 30 September 2008 11:53
> *To:* ASCOM-Talk@yahoogroups.com
> *Subject:* [ASCOM] Adding stuff to ICamera?
>
> Hi gang,
>
> Is there anyway I can add my own methods and properties to the ICamera
> interface? Don’t fink der iz, bu fort I’d ask coz I’z dunno anefink J
>
> I have my own workaround where a new interface is sort of bolted on to
> the existing one (shares the same root ProdID string). Works for me
> but I don’t think anyone else would like it.
>
> Regards
>
> Robin
>
> Sent from my Type 150CB Mk.234 telephone
>
>

That's one of the questions I want to answer by playing around with
Extension Methods :)

Robin

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On
> Behalf Of Antoine PAVLIN
> Sent: 02 October 2008 23:34
> To: ASCOM-Talk@yahoogroups.com
> Subject: Re: [ASCOM] Adding stuff to ICamera?
>
> Why not defining a class inherited from ICamera? That way all methods
> and properties of the parent class are readily available, plus the ones
> defined in the child class.
>
> Antoine
>
> Robin Lauryssen-Mitchell a écrit :
> >
> > To partly answer my own question (isn’t posting emails a great way to
> > get ideas! J) I could always add ‘Implements ICamera’ inside my own
> > class and copy over all the methods and properties. There doesn’t
> > appear to be anything illegal about having two ‘Implements’ calls
> > inside one class. Horrible duplication of course, but it might just be
> > ‘cleaner’ than my original approach.
> >
> > Having fun
> >
> > Robin
> >
> > -----Original Message-----
> > *From:* ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com]
> > *On Behalf Of *Robin Lauryssen-Mitchell
> > *Sent:* 30 September 2008 11:53
> > *To:* ASCOM-Talk@yahoogroups.com
> > *Subject:* [ASCOM] Adding stuff to ICamera?
> >
> > Hi gang,
> >
> > Is there anyway I can add my own methods and properties to the ICamera
> > interface? Don’t fink der iz, bu fort I’d ask coz I’z dunno anefink J
> >
> > I have my own workaround where a new interface is sort of bolted on to
> > the existing one (shares the same root ProdID string). Works for me
> > but I don’t think anyone else would like it.
> >
> > Regards
> >
> > Robin
> >
> > Sent from my Type 150CB Mk.234 telephone
> >
> >
>
>
> ------------------------------------
>
> For more information see http://ASCOM-Standards.org/.
>
> To unsubscribe from this group, send an email FROM THE ACCOUNT YOU USED TO
> SUBSCRIBE(!) to:
> ASCOM-Talk-unsubscribe@yahoogroups.com
>
> Yahoo! Groups Links
>
>
>

Would love to see an MS netCobol app use ASCOM

Greetings all,
While trying to clean up possible registry problems, I attempted to
uninstall ASCOM V5.0a. During the uninstall process, I got repeated
messages of the form:
"Failed to deregister xxxxxx. The application threw an exception."
This repeated for telescope hub, dome hub and so on.

What's happening here? How do I track down what's happened so I can
fix the problem?

Cheers,
Tim Cole
Ottawa ON

Hi Bob,

I'm sorry I didn't see your post until just now.  Too many irons in
the fire, I'm told!

I appreciate your detailed explanation of what the problems are and
why they happened.  And I hope I didn't sound like I was attacking
ASCOM as a whole.  I think it's a wonderful project!  My only
complaint is with windows that don't show up on top.  I think it's
appropriate to complain about that.  As for Ajai's driver, I never
use it for a variety of reasons that have nothing to do with ASCOM
perse.  I use the LX200GPS/R and POTH drivers with MaxIm DL V5.01,
and they have the window problem too.  I can't speak for other
drivers.

You are of course correct that the problem doesn't lock up the entire
system.  I shouldn't have used that term, and hope it didn't lead
anyone to think that I was being alarmist.  I tend to use the
word "system" to mean that part of the system that I am using at the
moment -- in this case, the ASCOM driver and the control program.
However, be it understood that this is not a problem with just one
specific control program, but at least three well-respected programs:
namely MaxIm DL, PHD, and Starry Night Pro.  I admit I don't know for
a fact that _all_ programs (or drivers) lock up; but that doesn't
keep me from wondering.

Again, let me say that I like ASCOM and recommend it heartily to
anyone who will listen.  But this problem of the hidden windows has
been around for several years, and it seems to me that this must
reflect badly on ASCOM, whether it's justified or not.  I make no
claims about how broad this problem is or who is responsible.  Maybe
it's just a problem with "Meade drivers", for example.  Still, there
are a few of us out here, so it does reflect on ASCOM even if it
shouldn't be that way.

I hope I've been specific enough this time without being overly
broad.  If I have failed at that, then I'm sorry!  I know this
message is critical, but I think it needs to be that way to get the
problem fixed.  So I am truly sorry that I can't be more positive.

Take care,
Hilary

--- In ASCOM-Talk@yahoogroups.com, Bob Denny <rdenny@...> wrote:
>
> Hilary --
>
> > I have come to believe that there is some problem inherent in all
ASCOM
> > software that allows windows to pop up behind other windows and
lock up the
> > system.
>
> Window positioning is the responsibility of the applications and/or
drivers that
> display the windows. The ASCOM Chooser does force itself to the
top, and that's
> the only window that "ASCOM" displays. The RCX driver would be
responsible for
> displaying ITS setup dialog on top, in response to some astronomy
software
> (MaxPoinnt in this case) trying to use it. Most often, drivers'
setup windows
> are "modal", that is they appear in response to the
Chooser's "Properties..."
> button, and disappear when OK or Cancel is clicked. Modal windows
appear on top
> by default, so most drivers' setup windows appear on top.
>
> In the case of Ajai's drivers, though, a window appears that is
more or less
> like a "control center" for that scope and remains there as long as
some
> application has a reference to that driver. I've seen cases where
that window
> gets under others. The problem is that it doesn't appear to have a
taskbar proxy
> so you can't find or select it.
>
> And an inaccessible window is not the same as "locked up". The
system is NOT
> "locked up". The mouse moves, you can start other programs, etc.
MaxPoint
> appears "locked up" because it's waiting for an OK in a window that
it displayed
> and which appeared BEHIND it, invisible and inaccessible. That is a
problem, and
> we should address it somehow... and I am confident (though not
certain) that the
> fix needs to be in the driver.
>
> That's not a fault of "all ASCOM programs", so let's try to remain
with the
> facts and not generate bad spin for ASCOM. If "ASCOM" has some
deficiencies,
> let's be specific what they are and let us fix them.
>
> I don't personally agree with the philosophy of making a driver
into a "pseudo
> control program". My ACP users mostly find it disconcerting to see
a window for
> the telescope appear, loaded with exotic doodads, and seemingly
part of MY
> software. I regularly have to explain that it's NOT part of my
software and
> please don't' fiddle with those knobs and dials while ACP is using
the
> telescope. Tempting but not good.
>
>   -- Bob
>

FWIW, the QSI driver has an ICameraEx to do just this and that inherits from
ICamera...

Craig


--- In ASCOM-Talk@yahoogroups.com, Antoine PAVLIN <antoine.pavlin@...> wrote:
>
> Why not defining a class inherited from ICamera? That way all methods
> and properties of the parent class are readily available, plus the ones
> defined in the child class.
>
> Antoine
>
> Robin Lauryssen-Mitchell a écrit :
> >
> > To partly answer my own question (isn't posting emails a great way to
> > get ideas! J) I could always add `Implements ICamera' inside my own
> > class and copy over all the methods and properties. There doesn't
> > appear to be anything illegal about having two `Implements' calls
> > inside one class. Horrible duplication of course, but it might just be
> > `cleaner' than my original approach.
> >
> > Having fun
> >
> > Robin
> >
> > -----Original Message-----
> > *From:* ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com]
> > *On Behalf Of *Robin Lauryssen-Mitchell
> > *Sent:* 30 September 2008 11:53
> > *To:* ASCOM-Talk@yahoogroups.com
> > *Subject:* [ASCOM] Adding stuff to ICamera?
> >
> > Hi gang,
> >
> > Is there anyway I can add my own methods and properties to the ICamera
> > interface? Don't fink der iz, bu fort I'd ask coz I'z dunno anefink J
> >
> > I have my own workaround where a new interface is sort of bolted on to
> > the existing one (shares the same root ProdID string). Works for me
> > but I don't think anyone else would like it.
> >
> > Regards
> >
> > Robin
> >
> > Sent from my Type 150CB Mk.234 telephone
> >
> >
>

Hi Craig,

Any implementation advice to share?  I'm struggling a bit with this but
think I'll have it cracked in the next couple of days or so (or decades!!!).
Doesn't help having my parents visiting at the moment! <g>

Regards
Robin

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On
> Behalf Of Craig Stark
> Sent: 05 October 2008 02:03
> To: ASCOM-Talk@yahoogroups.com
> Subject: Re: [ASCOM] Adding stuff to ICamera?
>
> FWIW, the QSI driver has an ICameraEx to do just this and that inherits
> from ICamera...
>
> Craig
>
>
> --- In ASCOM-Talk@yahoogroups.com, Antoine PAVLIN <antoine.pavlin@...>
> wrote:
> >
> > Why not defining a class inherited from ICamera? That way all methods
> > and properties of the parent class are readily available, plus the ones
> > defined in the child class.
> >
> > Antoine
> >
> > Robin Lauryssen-Mitchell a écrit :
> > >
> > > To partly answer my own question (isn't posting emails a great way to
> > > get ideas! J) I could always add `Implements ICamera' inside my own
> > > class and copy over all the methods and properties. There doesn't
> > > appear to be anything illegal about having two `Implements' calls
> > > inside one class. Horrible duplication of course, but it might just be
> > > `cleaner' than my original approach.
> > >
> > > Having fun
> > >
> > > Robin
> > >
> > > -----Original Message-----
> > > *From:* ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com]
> > > *On Behalf Of *Robin Lauryssen-Mitchell
> > > *Sent:* 30 September 2008 11:53
> > > *To:* ASCOM-Talk@yahoogroups.com
> > > *Subject:* [ASCOM] Adding stuff to ICamera?
> > >
> > > Hi gang,
> > >
> > > Is there anyway I can add my own methods and properties to the ICamera
> > > interface? Don't fink der iz, bu fort I'd ask coz I'z dunno anefink J
> > >
> > > I have my own workaround where a new interface is sort of bolted on to
> > > the existing one (shares the same root ProdID string). Works for me
> > > but I don't think anyone else would like it.
> > >
> > > Regards
> > >
> > > Robin
> > >
> > > Sent from my Type 150CB Mk.234 telephone
> > >
> > >
> >
>
>
>
>
> ------------------------------------
>
> For more information see http://ASCOM-Standards.org/.
>
> To unsubscribe from this group, send an email FROM THE ACCOUNT YOU USED TO
> SUBSCRIBE(!) to:
> ASCOM-Talk-unsubscribe@yahoogroups.com
>
> Yahoo! Groups Links
>
>
>

Bob,

I know you wanted someone else to test this, but since you didn't get
any takers...

I installed a fresh Vista64 system and installed ASCOM v5a then the
new Rotator update.

Unfortunately the update doesn't work 100%. It installs the new
version, but fails to update the registry. With the new version
installed I had to run:
ASCOM.RotatorSimulator.exe /unregserver
ASCOM.RotatorSimulator.exe /regserver

to get it to work.

Now when I uninstall ASCOM and reinstall everything works. So, I'm not
sure if both the unregserver and regserver were necessary or just the
regserver. If you need more testing, I can start from scratch again.

-Matt Thomas
http://www.astromatt.com/
CCD Commander: multi-target unattended imaging
http://www.ccdcommander.com/

Thursday, October 2, 2008, 5:21:12 PM, Bob wrote:

> I have put an updater for the Rotator Simulator (1.0.2) into the
> Platform Updates section of the ASCOM site. It corrects the build so
> that it will run on 64-bit systems. No bug fixes or new features. I
> don't have a 64-bit system here, so I'd appreciate a report back from
> someone who hasn't installed it (i.e. not Matt Thomas :-)) to see if
> this does the trick. If you are on a 64-bit system, run the updater,
> then try to start the Rotator Simulator (Windows Start Menu, ASCOM
> Platform, Simulators).

>   -- Bob

I wouldn't necessarily say it is _unusual_ for devices to generate
spontaneous, unsolicited output, but most drivers are written that way.
All of the Technical Innovations devices do it, for example, as does the
AWR system that I am working on at the moment. The idea that devices
only generate output in response to commands is a very simplistic view
of what are, essentially, real time systems and if you dig into it I
suspect you can find examples for most devices that would cause them to
generate output that is not a direct response to a command. Fortunately,
it is possible (and not too difficult) to write a driver that handles
input and output on different threads. Such a driver can then deal with
asynchronous events in the receive thread. When commands need a
response, a ManualResetEvent signal can be used to synchronise the two
threads. It sounds complicated, but it's not as bad as it seems. I would
be prepared to share my technique off-list with anyone who needs to do
that.

Regards,
Tim Long

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com]
On
> Behalf Of Chris Peterson
> Sent: 01 October 2008 02:34
> To: ASCOM-Talk@yahoogroups.com
> Subject: Re: [ASCOM] ideas: ascom-compliant handover to 'on-board'
> mount controls?
>
> Hi Ben-
>
> It is unusual for a mount to send any information back to an
> application
> except in reply to a request. That's how the ASCOM functions are
> defined.
> Most applications can be configured to request the mount position at
> some
> interval, typically every few seconds. If the ASCOM driver doesn't
> receive a
> valid response (usually within some timeout period, depending on the
> driver), it will raise an error the application should handle. Given
> the
> very low bandwidth involved in polling the mount every few seconds, I
> doubt
> you'll have any problems.
>
> There should be nothing to buffer. If the mount gets a request for the
> position, it simply returns the current position, independent of any
> commands involved in getting it there.
>
> Chris
> ________________________________
> Chris L Peterson
> http://www.cloudbait.com
>
>
> ----- Original Message -----
> From: "ben.ealing" <ben.ealing@...>
> To: <ASCOM-Talk@yahoogroups.com>
> Sent: Tuesday, September 30, 2008 1:36 PM
> Subject: Re: [ASCOM] ideas: ascom-compliant handover to 'on-board'
> mount
> controls?
>
>
> > Chris, William, Joe, and Bob,
> >
> > Thanks very much for your responses.
> >
> > The difficulty arises here because the telescope is controlled via a
> > bluetooth connection.  That's very nice (no wires to trip over etc)
> > but it does mean that I cannot be confident that, for example, a
> > quick series of 'on-board' commands which alter the scope's position
> > will all be transmitted over bluetooth back to the software.  As a
> > result, I have currently designed it so that the mount stores all
the
> > movements and then transmits a single piece of data back to the PC.
> >
> > I think all have basically said: just ensure the mount can handle
> > commands from either source (PC or on-board control) and ensure that
> > the data is transmitted back sufficiently frequently to ensure
> > synchronisation.  That may or may not be possible (!) depending on
> > the bluetooth connection.
> >
> > The only two alternatives, I think, are to (i) follow the earlier
> > generation nexstar approach and temporarily disable one or the
other;
> > or (ii) connect / disconnect scope - which is so cumbersome I won't
> > do.
> >
> > Thank you very much for your input.  Very helpful to have better
> > minds considering this.  Will ponder some more....
> >
> > Ben
>
>
> ------------------------------------
>
> For more information see http://ASCOM-Standards.org/.
>
> To unsubscribe from this group, send an email FROM THE ACCOUNT YOU
USED
> TO SUBSCRIBE(!) to:
> ASCOM-Talk-unsubscribe@yahoogroups.com
>
> Yahoo! Groups Links
>
>
>

Hi Tim-

I was specifically addressing mounts. I'm not aware of any that just spew
out their coordinates without being asked, but that's not to say there might
not be some. But I do think- with respect to mounts- that sending data
without a request is unusual. And from the standpoint of an application
attaching through an ASCOM driver (which is the subject of this thread), I
don't think a mount _can_ send unsolicited data. If it does, the driver
would be required to handle it internally and only provide it to the
application on request. There is no mechanism for an ASCOM telescope driver
to send information to the connected application without such a request.

Chris

*****************************************
Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com


----- Original Message -----
From: "Tim Long" <Tim@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Sunday, October 05, 2008 6:25 PM
Subject: RE: [ASCOM] ideas: ascom-compliant handover to 'on-board' mount
controls?


>I wouldn't necessarily say it is _unusual_ for devices to generate
> spontaneous, unsolicited output, but most drivers are written that way.
> All of the Technical Innovations devices do it, for example, as does the
> AWR system that I am working on at the moment. The idea that devices
> only generate output in response to commands is a very simplistic view
> of what are, essentially, real time systems and if you dig into it I
> suspect you can find examples for most devices that would cause them to
> generate output that is not a direct response to a command. Fortunately,
> it is possible (and not too difficult) to write a driver that handles
> input and output on different threads. Such a driver can then deal with
> asynchronous events in the receive thread. When commands need a
> response, a ManualResetEvent signal can be used to synchronise the two
> threads. It sounds complicated, but it's not as bad as it seems. I would
> be prepared to share my technique off-list with anyone who needs to do
> that.
>
> Regards,
> Tim Long

Interface inheritance is certainly possible but in practice I think it works out
better to just publish separate interfaces. It is a bit more obvious what is
going on then. Plus, you don't force applications to implement your
mega-interface if they only need the raw ASCOM interface.

--Tim

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On
> Behalf Of Craig Stark
> Sent: 05 October 2008 01:03
> To: ASCOM-Talk@yahoogroups.com
> Subject: Re: [ASCOM] Adding stuff to ICamera?
>
> FWIW, the QSI driver has an ICameraEx to do just this and that inherits
> from ICamera...
>
> Craig
>
>
> --- In ASCOM-Talk@yahoogroups.com, Antoine PAVLIN <antoine.pavlin@...>
> wrote:
> >
> > Why not defining a class inherited from ICamera? That way all methods
> > and properties of the parent class are readily available, plus the
> ones
> > defined in the child class.
> >
> > Antoine
> >
> > Robin Lauryssen-Mitchell a écrit :
> > >
> > > To partly answer my own question (isn't posting emails a great way
> to
> > > get ideas! J) I could always add `Implements ICamera' inside my own
> > > class and copy over all the methods and properties. There doesn't
> > > appear to be anything illegal about having two `Implements' calls
> > > inside one class. Horrible duplication of course, but it might just
> be
> > > `cleaner' than my original approach.
> > >
> > > Having fun
> > >
> > > Robin
> > >
> > > -----Original Message-----
> > > *From:* ASCOM-Talk@yahoogroups.com [mailto:ASCOM-
> Talk@yahoogroups.com]
> > > *On Behalf Of *Robin Lauryssen-Mitchell
> > > *Sent:* 30 September 2008 11:53
> > > *To:* ASCOM-Talk@yahoogroups.com
> > > *Subject:* [ASCOM] Adding stuff to ICamera?
> > >
> > > Hi gang,
> > >
> > > Is there anyway I can add my own methods and properties to the
> ICamera
> > > interface? Don't fink der iz, bu fort I'd ask coz I'z dunno anefink
> J
> > >
> > > I have my own workaround where a new interface is sort of bolted on
> to
> > > the existing one (shares the same root ProdID string). Works for me
> > > but I don't think anyone else would like it.
> > >
> > > Regards
> > >
> > > Robin
> > >
> > > Sent from my Type 150CB Mk.234 telephone
> > >
> > >
> >
>
>
>
>
> ------------------------------------
>
> For more information see http://ASCOM-Standards.org/.
>
> To unsubscribe from this group, send an email FROM THE ACCOUNT YOU USED
> TO SUBSCRIBE(!) to:
> ASCOM-Talk-unsubscribe@yahoogroups.com
>
> Yahoo! Groups Links
>
>
>

That's all true. The mounts I've seen - the AWR system that I am working
on is a good example - generates status messages whenever it feels like
it. These can signal a change in axis state (stopped/tracking/slewing),
a change in the state of some user outputs, activation of a safety
interlock, index pulses and a few other things. None of them directly
affect the coordinates, though.

The DDW dome driver, though, has to handle azimuth updates in real time.
All the while the dome is rotating, it spits out encoder pulses on the
serial port, which the driver must use to keep track of the azimuth
value. While this is happening, the application can read the updated
azimuth value, but I can't send a query command to the dome controller
because it would interpret that as an emergency stop. I'm not allowed to
talk to the controller until it has finished moving. I had no choice
therefore, but to split send and receive onto separate threads and put a
lot of intelligence into the receive thread. The driver keeps a private
copy of the azimuth that is updated on the receive thread. When the
application requests azimuth, it just receives the cached copy. One
up-side to that approach is that the application can poll
hell-for-leather and generate no serial traffic at all.

--T.

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com]
On
> Behalf Of Chris Peterson
> Sent: 06 October 2008 01:39
> To: ASCOM-Talk@yahoogroups.com
> Subject: Re: [ASCOM] ideas: ascom-compliant handover to 'on-board'
> mount controls?
>
> Hi Tim-
>
> I was specifically addressing mounts. I'm not aware of any that just
> spew
> out their coordinates without being asked, but that's not to say there
> might
> not be some. But I do think- with respect to mounts- that sending data
> without a request is unusual. And from the standpoint of an
application
> attaching through an ASCOM driver (which is the subject of this
> thread), I
> don't think a mount _can_ send unsolicited data. If it does, the
driver
> would be required to handle it internally and only provide it to the
> application on request. There is no mechanism for an ASCOM telescope
> driver
> to send information to the connected application without such a
> request.
>
> Chris
>
> *****************************************
> Chris L Peterson
> Cloudbait Observatory
> http://www.cloudbait.com
>
>
> ----- Original Message -----
> From: "Tim Long" <Tim@...>
> To: <ASCOM-Talk@yahoogroups.com>
> Sent: Sunday, October 05, 2008 6:25 PM
> Subject: RE: [ASCOM] ideas: ascom-compliant handover to 'on-board'
> mount
> controls?
>
>
> >I wouldn't necessarily say it is _unusual_ for devices to generate
> > spontaneous, unsolicited output, but most drivers are written that
> way.
> > All of the Technical Innovations devices do it, for example, as does
> the
> > AWR system that I am working on at the moment. The idea that devices
> > only generate output in response to commands is a very simplistic
> view
> > of what are, essentially, real time systems and if you dig into it I
> > suspect you can find examples for most devices that would cause them
> to
> > generate output that is not a direct response to a command.
> Fortunately,
> > it is possible (and not too difficult) to write a driver that
handles
> > input and output on different threads. Such a driver can then deal
> with
> > asynchronous events in the receive thread. When commands need a
> > response, a ManualResetEvent signal can be used to synchronise the
> two
> > threads. It sounds complicated, but it's not as bad as it seems. I
> would
> > be prepared to share my technique off-list with anyone who needs to
> do
> > that.
> >
> > Regards,
> > Tim Long
>
>
> ------------------------------------
>
> For more information see http://ASCOM-Standards.org/.
>
> To unsubscribe from this group, send an email FROM THE ACCOUNT YOU
USED
> TO SUBSCRIBE(!) to:
> ASCOM-Talk-unsubscribe@yahoogroups.com
>
> Yahoo! Groups Links
>
>
>

Plus, you don't force applications to implement your mega-interface if they only need the raw ASCOM interface.