Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

ASCOM-Talk · ASCOM Initiative Discussion List

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 3684
  • Category: Astronomy
  • Founded: Nov 21, 2000
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Real people. Real stories. See how Yahoo! Groups impacts members worldwide.

Messages

Advanced
Messages Help
Messages 15636 - 15665 of 30126   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#15636 From: Chris Rowland <chris_group_mail@...>
Date: Wed Oct 1, 2008 7:34 am
Subject: Re: [ASCOM] Need Some Help with ASCOM Use
scope_sapiens
Send Email Send Email
 
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
>

#15637 From: "ben.ealing" <ben.ealing@...>
Date: Wed Oct 1, 2008 7:59 am
Subject: Re: ideas: ascom-compliant handover to 'on-board' mount controls?
ben.ealing
Send Email Send Email
 
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
>

#15638 From: "Boyer, William" <william.boyer@...>
Date: Wed Oct 1, 2008 6:46 pm
Subject: RE: [ASCOM] ideas: ascom-compliant handover to 'on-board' mount controls?
wslboyer
Send Email Send Email
 
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

#15639 From: "rcx400" <rodsrun@...>
Date: Wed Oct 1, 2008 6:52 pm
Subject: Re: [ASCOM] Need Some Help with ASCOM Use
rcx400
Send Email Send Email
 
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

#15640 From: ASCOM-Talk@yahoogroups.com
Date: Wed Oct 1, 2008 9:03 pm
Subject: New file uploaded to ASCOM-Talk
ASCOM-Talk@yahoogroups.com
Send Email Send Email
 
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@...>

#15641 From: "Hilary Jones" <hilaryyahoo3@...>
Date: Thu Oct 2, 2008 2:33 am
Subject: Re: Need Some Help with ASCOM Use
hilary15xx
Send Email Send Email
 
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
>

#15642 From: "autostaretx" <rseymour@...>
Date: Thu Oct 2, 2008 4:03 am
Subject: Re: [ASCOM] Need Some Help with ASCOM Use
autostaretx
Send Email Send Email
 
--- 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

#15643 From: "joeastroc" <joeastroc@...>
Date: Thu Oct 2, 2008 5:13 pm
Subject: Run-time error '-2147220416 (80040440)': Failed to open/create root registry key
joeastroc
Send Email Send Email
 
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

#15644 From: Bob Denny <rdenny@...>
Date: Thu Oct 2, 2008 5:43 pm
Subject: UPDATED: Vixen SS2K Driver
dc3dreamer
Send Email Send Email
 
Thanks to Laurie Yates, a new version (5.1.6b) of the Vixen SkySensor 2000 driver is now online in the Telescope Drivers section of the ASCOM site.

#15645 From: Antoine PAVLIN <antoine.pavlin@...>
Date: Thu Oct 2, 2008 9:33 pm
Subject: Re: [ASCOM] Adding stuff to ICamera?
antoine.pavlin
Send Email Send Email
 
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
>
>

#15646 From: "Robin Lauryssen-Mitchell" <robin@...>
Date: Thu Oct 2, 2008 10:06 pm
Subject: RE: [ASCOM] Adding stuff to ICamera?
robin73732
Send Email Send Email
 

Hi Tim,

 

Thanks for the hint about C# Extension Methods.  Can you short-circuit my blundering around and point me in the direction of some reasonable EM documentation?

 

Thanks

Robin

 

-----Original Message-----
From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Tim Long
Sent: 30 September 2008 19:46
To: ASCOM-Talk@yahoogroups.com
Subject: RE: [ASCOM] Adding stuff to ICamera?

 

I agree with Bob, create your own unique interface with just your additional properties and methods. Then at runtime, you can load any old standard ASCOM driver that implements ICamera, then test whether it also implements your private interface.

 

Another technique that is new in C# 3.0 (not sure if it is in VB yet) is Extension Methods. Basically, extension methods allow you to extend other people’s classes without requiring the source code or needing to recompile. It is a neat semantic trick done by the compiler and was fundamental to the way LINQ was implemented. In theory, you could write a set of extension methods that apply to the ICamera interface – but this would only be appropriate if your extensions were applicable to all Camera drivers. If your extensions are unique to one driver, the private interface is the best bet.

 

--Tim Long

 

From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Bob Denny
Sent: 30 September 2008 12:29
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] Adding stuff to ICamera?

 

Robin L-M:

Is there anyway I can add my own methods and properties to the ICamera interface? 


Don't extend a standard interface, add your one-off properties and methods to a separate interface (e.g. IRobinsCameraExtensions) that your driver also implements.

  -- Bob


#15647 From: "Robin Lauryssen-Mitchell" <robin@...>
Date: Thu Oct 2, 2008 10:22 pm
Subject: RE: [ASCOM] Adding stuff to ICamera?
robin73732
Send Email Send Email
 
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
>
>
>

#15648 From: Bob Denny <rdenny@...>
Date: Thu Oct 2, 2008 11:26 pm
Subject: Re: [ASCOM] Adding stuff to ICamera?
dc3dreamer
Send Email Send Email
 
Remember that your driver has to be usable from any language on Windows. Thus it must be usable from the Windows Objects, or COM, system, not just native .NET. COM doesn't support "extension methods". So you'll save yourself a lot of pain by just exposing a second interface.

  -- Bob


#15649 From: Bob Denny <rdenny@...>
Date: Fri Oct 3, 2008 12:21 am
Subject: [ANN] Rotator Simulator Update for 64-bit systems
dc3dreamer
Send Email Send Email
 
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


#15650 From: "Robin Lauryssen-Mitchell" <robin@...>
Date: Fri Oct 3, 2008 12:20 am
Subject: RE: [ASCOM] Adding stuff to ICamera?
robin73732
Send Email Send Email
 

Only if the driver is intended to be ASCOM compliant – and it isn’t going to be.  It’s a personal self-educational highly experimental heap of junk that probably won’t work anyway J.

 

Having fun (as usual)

Robin

P.S. Would love to see an MS netCobol app use ASCOM <VBG>

P.P.S. If I can get my grubby mitts on a copy I’ll try it!

 

-----Original Message-----
From:
ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Bob Denny
Sent: 03 October 2008 01:26
To:
ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] Adding stuff to ICamera?

 

Remember that your driver has to be usable from any language on Windows. Thus it must be usable from the Windows Objects, or COM, system, not just native .NET. COM doesn't support "extension methods". So you'll save yourself a lot of pain by just exposing a second interface.

  -- Bob


#15651 From: Bob Denny <rdenny@...>
Date: Fri Oct 3, 2008 3:02 am
Subject: Re: [ASCOM] Adding stuff to ICamera?
dc3dreamer
Send Email Send Email
 
Would love to see an MS netCobol app use ASCOM

Go for it!

#15652 From: "Tim Cole" <TimCole@...>
Date: Sat Oct 4, 2008 7:31 am
Subject: Uninstall error messages
tim_cole2004
Send Email Send Email
 
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

#15653 From: "Hilary Jones" <hilaryyahoo3@...>
Date: Sat Oct 4, 2008 6:33 pm
Subject: [ASCOM] Re: Maybe Old Problem with RCX Setup Dialog
hilary15xx
Send Email Send Email
 
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
>

#15654 From: "Craig Stark" <craig@...>
Date: Sun Oct 5, 2008 12:03 am
Subject: Re: [ASCOM] Adding stuff to ICamera?
celstark
Send Email Send Email
 
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
> >
> >
>

#15655 From: "Robin Lauryssen-Mitchell" <robin@...>
Date: Sun Oct 5, 2008 8:11 am
Subject: RE: [ASCOM] Adding stuff to ICamera?
robin73732
Send Email Send Email
 
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
>
>
>

#15656 From: Matt Thomas <matt_e_thomas@...>
Date: Sun Oct 5, 2008 4:58 pm
Subject: Re: [ASCOM] [ANN] Rotator Simulator Update for 64-bit systems
matt_e_thomas
Send Email Send Email
 
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

#15657 From: "David Challis" <challis@...>
Date: Sun Oct 5, 2008 5:52 pm
Subject: RE: [ASCOM] Adding stuff to ICamera?
dchallis949
Send Email Send Email
 

The QSI ICamera driver implementation is in C++.  We implement a number of interfaces for the driver using dual interfaces.  First we implement the ICamera and the IFilterWheel interfaces (we have an embedded filter wheel in the camera) as defined in the ASCOM typelib.  Note: you need to make sure the IID’s are the ones specified in the ASCOM typelib and the methods are in the exact order specified typlib.  This will allow early ICamera binders to work with the driver.  We then implement an ICameraEx interface that inherits from ICamera that contains the QSI specific extensions and also implements IDispatch for late binders. 

 

Doing all this allows pure ASCOM users to early or late bind to ICamera and receive the proper interface.  Users wishing to use the QSI extensions just have to bind to ICameraEx instead and they get the whole enchilada.

 

One request for the group:  Once a COM interface has been published, it should not change.  If changes are required, a new interface should be defined.  I hope we all agree that the ICamera interface is “published” and is immutable from here on out.  Let’s not have “upgrades to the interface” break early binders.

 

Hope this helps.

 

Dave Challis

QSI

 

From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Robin Lauryssen-Mitchell
Sent: Sunday, October 05, 2008 1:12 AM
To: ASCOM-Talk@yahoogroups.com
Subject: RE: [ASCOM] Adding stuff to ICamera?

 

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...
>


#15658 From: "Robin Lauryssen-Mitchell" <robin@...>
Date: Sun Oct 5, 2008 6:13 pm
Subject: RE: [ASCOM] Adding stuff to ICamera?
robin73732
Send Email Send Email
 

Thanks for the hints Dave.

 

What does the ASCOM group think about publishing some modified VB, VC and VS templates to light the way for others wishing to go down this path?  Would this equate to providing a standardized way of adding extension stuff, or am I missing something as usual?

 

FWIW I’m doing my messing around with C#.  Really rather starting to like it J

 

Regards

Robin

 

-----Original Message-----
From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of David Challis
Sent: 05 October 2008 19:53
To: ASCOM-Talk@yahoogroups.com
Subject: RE: [ASCOM] Adding stuff to ICamera?

 

The QSI ICamera driver implementation is in C++.  We implement a number of interfaces for the driver using dual interfaces.  First we implement the ICamera and the IFilterWheel interfaces (we have an embedded filter wheel in the camera) as defined in the ASCOM typelib.  Note: you need to make sure the IID’s are the ones specified in the ASCOM typelib and the methods are in the exact order specified typlib.  This will allow early ICamera binders to work with the driver.  We then implement an ICameraEx interface that inherits from ICamera that contains the QSI specific extensions and also implements IDispatch for late binders. 

 

Doing all this allows pure ASCOM users to early or late bind to ICamera and receive the proper interface.  Users wishing to use the QSI extensions just have to bind to ICameraEx instead and they get the whole enchilada.

 

One request for the group:  Once a COM interface has been published, it should not change.  If changes are required, a new interface should be defined.  I hope we all agree that the ICamera interface is “published” and is immutable from here on out.  Let’s not have “upgrades to the interface” break early binders.

 

Hope this helps.

 

Dave Challis

QSI

 


#15659 From: "Tim Long" <Tim@...>
Date: Mon Oct 6, 2008 12:10 am
Subject: RE: [ASCOM] Adding stuff to ICamera?
t_p_long
Send Email Send Email
 

Right. Extension methods are great when your extensions apply equally well to any instance of the class you are extending. So if you do use this technique, then the extension methods would need to be carefully crafted so as not to make any device-specific assumptions. The MSDN library contains all the gory details, starting here:

http://msdn.microsoft.com/en-us/library/bb383977.aspx

 

Here is how you define them... I’m going to define a null camera driver (i.e. it doesn’t do anything other than compile) called TiGraCam. Then I’ll define an extension method called SetBinning that sets both X and Y binning in one swell foop, then I’ll show that the extension method works for any camera driver by using it on both my null driver and the simulator. So my solution has three separate projects:

 

TiGraCam was created with the ASCOM Camera C# template. The TiGra.ICameraExtensions project is the interesting one, this is where I define my extension method. The Application project is my extremely minimalist ASCOM application that applies my extension methods to some ASCOM drivers.

 

OK, here’s the extension method code from TiGra.ICameraExtensions:

 

using ASCOM.Interface;

namespace TiGra.Extensions

      {

      public static class ICamera_Extensions

            {

            /// <summary>

            /// An extension method for ICamera that sets binning in both axes simultaneously.

            /// </summary>

            /// <param name="cam">An instance of ASCOM.Interface.ICamera.</param>

            /// <param name="binX">The X binning mode.</param>

            /// <param name="binY">The Y binning mode.</param>

            public static void SetBinning(this ICamera cam, short binX, short binY)

                  {

                  cam.BinX = binX;

                  cam.BinY = binY;

                  }

            }

      }

 

Notice that both the extension method itself and its containing class are declared public static. The key thing with an extension method is the first parameter, which must have the keyword this and defines the type that the extension method will operate on.

 

            public static void SetBinning(this ICamera cam, short binX, short binY) ...

 

That declaration means that this extension method applies to any instance of ICamera and takes two parameters, binX and binY.                                                                                                             

 

Now in the application, you can access the extension method like this:

Notice that as soon as the dot is typed after theCam, the Intellisense popup includes my new SetBinning method just as if it had been defined by ICamera. You can now use this method with any ICamera instance, provided you have added the appropriate using... directive. Here’s the full source of my trivial application:

 

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using ASCOM.Interface;

using ASCOM.TiGraCam;

using TiGra.Extensions;

 

namespace Application

      {

      class Program

            {

            static void Main(string[] args)

                  {

                  ICamera theCam = new ASCOM.TiGraCam.Camera();

                  theCam.Connected = true;

                  // Use the SetBinning extension method. Note that we don't supply the implied first parameter.

                  theCam.SetBinning(2, 2);

                  // The extension method works for any instance of ICamera, including ones we don't have source code for.

                  ICamera simulator = new CCDSimulator.CameraClass();

                  simulator.SetBinning(2, 2);

                  }

            }

      }

 

 

Regards,

Tim Long

 

                                                                                                                                                                  

From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Robin Lauryssen-Mitchell
Sent: 02 October 2008 23:06
To: ASCOM-Talk@yahoogroups.com
Subject: RE: [ASCOM] Adding stuff to ICamera?

 

Hi Tim,

 

Thanks for the hint about C# Extension Methods.  Can you short-circuit my blundering around and point me in the direction of some reasonable EM documentation?

 

Thanks

Robin

 

-----Original Message-----
From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Tim Long
Sent: 30 September 2008 19:46
To: ASCOM-Talk@yahoogroups.com
Subject: RE: [ASCOM] Adding stuff to ICamera?

 

I agree with Bob, create your own unique interface with just your additional properties and methods. Then at runtime, you can load any old standard ASCOM driver that implements ICamera, then test whether it also implements your private interface.

 

Another technique that is new in C# 3.0 (not sure if it is in VB yet) is Extension Methods. Basically, extension methods allow you to extend other people’s classes without requiring the source code or needing to recompile. It is a neat semantic trick done by the compiler and was fundamental to the way LINQ was implemented. In theory, you could write a set of extension methods that apply to the ICamera interface – but this would only be appropriate if your extensions were applicable to all Camera drivers. If your extensions are unique to one driver, the private interface is the best bet.

 

--Tim Long

 

From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Bob Denny
Sent: 30 September 2008 12:29
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] Adding stuff to ICamera?

 

Robin L-M:

Is there anyway I can add my own methods and properties to the ICamera interface? 


Don't extend a standard interface, add your one-off properties and methods to a separate interface (e.g. IRobinsCameraExtensions) that your driver also implements.

  -- Bob


#15660 From: "Tim Long" <Tim@...>
Date: Mon Oct 6, 2008 12:25 am
Subject: RE: [ASCOM] ideas: ascom-compliant handover to 'on-board' mount controls?
t_p_long
Send Email Send Email
 
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
>
>
>

#15661 From: "Tim Long" <Tim@...>
Date: Mon Oct 6, 2008 12:33 am
Subject: RE: [ASCOM] Adding stuff to ICamera?
t_p_long
Send Email Send Email
 

You’ve misunderstood the concept of extension methods. It doesn’t have to be supported by COM, the extension methods are only in scope in the application that defines them. Extension methods do not in any way alter or affect the underlying interface. They are nothing more than syntactic sugar. As long as the application (which I think we have already established is in C#) is using the ICamera interface, then the extension methods will apply to any instance of ICamera, even if the underlying driver is a legacy COM driver. See the example I just posted.

 

--Tim

 

From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Bob Denny
Sent: 03 October 2008 00:26
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] Adding stuff to ICamera?

 

Remember that your driver has to be usable from any language on Windows. Thus it must be usable from the Windows Objects, or COM, system, not just native .NET. COM doesn't support "extension methods". So you'll save yourself a lot of pain by just exposing a second interface.

  -- Bob


#15662 From: "Chris Peterson" <cpeterson@...>
Date: Mon Oct 6, 2008 12:39 am
Subject: Re: [ASCOM] ideas: ascom-compliant handover to 'on-board' mount controls?
cloudbait
Send Email Send Email
 
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

#15663 From: "Tim Long" <Tim@...>
Date: Mon Oct 6, 2008 12:51 am
Subject: RE: [ASCOM] Adding stuff to ICamera?
t_p_long
Send Email Send Email
 
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
>
>
>

#15664 From: "Tim Long" <Tim@...>
Date: Mon Oct 6, 2008 1:18 am
Subject: RE: [ASCOM] ideas: ascom-compliant handover to 'on-board' mount controls?
t_p_long
Send Email Send Email
 
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
>
>
>

#15665 From: Bob Denny <rdenny@...>
Date: Mon Oct 6, 2008 2:01 am
Subject: Re: [ASCOM] Adding stuff to ICamera?
dc3dreamer
Send Email Send Email
 
Tim Long:
Plus, you don't force applications to implement your mega-interface if they only need the raw ASCOM interface.

Exactly. And I'd call it the "standard ASCOM interface" as opposed to "raw". But let's take this a step further: What if we have 100 different  ICameraPlusMyStuff interfaces that inherit from ICamera? How would an application deal with that? Unless those drivers also expose ICamera, what's an app developer to do?

  -- Bob


Messages 15636 - 15665 of 30126   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help