Quick question:

When writing an ASCOM driver what is 'best practice' for any non-ASCOM
properties?

For example, a driver will no doubt need additional properties (eg stepper motor
details, serial processing info) and also associated procedures.  Is it best to
add these within the ASCOM driver, or is it better to create another object
which is called when the ASCOM driver initiliases - or is there some better 3rd
way?

Also, if the answer is another object, how / where should that be called within
the ASCOM template?

Thanks in advance - apologies for any obvious errors.

Ben

Hi Ben-

The only properties you need to expose are those required for an application
to operate properly. In most cases, that should be none except the existing
ASCOM properties and methods. For instance, none of the examples you gave
involve the client application.

Most devices _do_ have device specific settings that need to be managed.
These are normally setup operations handled only occasionally (or once) by
the operator, not the client app. So the appropriate place for those things
is in the setup dialog, which is invoked by standard ASCOM methods.

Chris

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


----- Original Message -----
From: "benwatson2008" <benjamintwatson@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Wednesday, November 25, 2009 11:45 AM
Subject: [ASCOM] driver-writing: where to put additional non-ASCOM
properties


> Quick question:
>
> When writing an ASCOM driver what is 'best practice' for any non-ASCOM
> properties?
>
> For example, a driver will no doubt need additional properties (eg stepper
> motor details, serial processing info) and also associated procedures.  Is
> it best to add these within the ASCOM driver, or is it better to create
> another object which is called when the ASCOM driver initiliases - or is
> there some better 3rd way?
>
> Also, if the answer is another object, how / where should that be called
> within the ASCOM template?
>
> Thanks in advance - apologies for any obvious errors.
>
> Ben

Ben, I'm not claiming this is necessarily 'best practice' but this is how I do
it, it works for me.

First, always start from one of the supplied template projects. There is a lot
of plumbing in there that is hard to get right. After that, I structure my
driver so that it has an AscomLayer class and an DeviceLayer class.

The AscomLayer does everything necessary to implement the ASCOM interface. There
may be sequencing logic, conversion of units from ASCOM standard units
(typically S.I. units) into raw device units (e.g. encoder ticks to/from
degrees). Obviously, the AscomLayer will call into the DeviceLayer to get things
done.

The DeviceLayer handles the communications channel (typically a serial port),
manages device state and provides methods to read and write raw device
properties. I make my IOLayer class public, so that anyone who wants to write a
control panel type application can do so and get low-level access.

The first time I tried this approach, I actually made the two classes into
separate assemblies, but I found that was too clumsy and made life unnecessarily
complex. Now, I lump everything into a single assembly.

Regards,
Tim Long

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-
> Talk@yahoogroups.com] On Behalf Of benwatson2008
> Sent: Wednesday, November 25, 2009 6:46 PM
> To: ASCOM-Talk@yahoogroups.com
> Subject: [ASCOM] driver-writing: where to put additional non-ASCOM
> properties
>
> Quick question:
>
> When writing an ASCOM driver what is 'best practice' for any non-ASCOM
> properties?
>
> For example, a driver will no doubt need additional properties (eg stepper
> motor details, serial processing info) and also associated procedures.  Is it
> best to add these within the ASCOM driver, or is it better to create another
> object which is called when the ASCOM driver initiliases - or is there some
> better 3rd way?
>
> Also, if the answer is another object, how / where should that be called
> within the ASCOM template?
>
> Thanks in advance - apologies for any obvious errors.
>
> 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
>
>
>

--
ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=nAPKRgCE030246&from=tim@tigranetwo\
rks.co.uk
Complete email hygeine and business continuity solution available from
http://www.tigranetworks.co.uk

Thanks Tim,

Have thought about it a bit more (your answer very helpful).

What would you say to this:

1.  The client calls an ASCOM class (which is derived from the template).  The
ASCOM class has coded into it all the persistent ASCOM variables (can pulse
guide, can park etc).  But the remainder of the ASCOM class is getting all its
information (ra/dec etc) from a class which is more comprehensive in that it
includes all the driver's properties (which will always go beyond the ASCOM
specific properties) including, for example, the properties relevant to
communication with the mount.  Call this second class the 'scope class'.

2.  The 'scope class' could then have the full 'bells and whistles' of the
serial comms, timer, extra status info (eg dec stepper moving) etc.  But the
client only ever communicates with the ASCOM class.  (Any additional properties
to be set by a user which fall within the scope class and not the ASCOM class
are included in the setup dialog form).

Does this 'second underlying class' approach (which I think sounds as though it
is something like your device layer class) sound alright in ASCOM terms?

It sounds OK to me because the client only ever communicates with the ASCOM
class.  It all fits within one assembly.  Any 'form' or 'handcontroller' could
access the second class if it wanted to get to the 'nitty gritty' detail.

Does this sound about right?

Thanks,

Ben

PS I appreciate there are many ways to skin this cat but don't want to set off
on a route that doesn't accord with the intentions behind ASCOM (to mix a
metaphor or two).


--- In ASCOM-Talk@yahoogroups.com, "Tim Long" <Tim@...> wrote:
>
> Ben, I'm not claiming this is necessarily 'best practice' but this is how I do
it, it works for me.
>
> First, always start from one of the supplied template projects. There is a lot
of plumbing in there that is hard to get right. After that, I structure my
driver so that it has an AscomLayer class and an DeviceLayer class.
>
> The AscomLayer does everything necessary to implement the ASCOM interface.
There may be sequencing logic, conversion of units from ASCOM standard units
(typically S.I. units) into raw device units (e.g. encoder ticks to/from
degrees). Obviously, the AscomLayer will call into the DeviceLayer to get things
done.
>
> The DeviceLayer handles the communications channel (typically a serial port),
manages device state and provides methods to read and write raw device
properties. I make my IOLayer class public, so that anyone who wants to write a
control panel type application can do so and get low-level access.
>
> The first time I tried this approach, I actually made the two classes into
separate assemblies, but I found that was too clumsy and made life unnecessarily
complex. Now, I lump everything into a single assembly.
>
> Regards,
> Tim Long
>
> > -----Original Message-----
> > From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-
> > Talk@yahoogroups.com] On Behalf Of benwatson2008
> > Sent: Wednesday, November 25, 2009 6:46 PM
> > To: ASCOM-Talk@yahoogroups.com
> > Subject: [ASCOM] driver-writing: where to put additional non-ASCOM
> > properties
> >
> > Quick question:
> >
> > When writing an ASCOM driver what is 'best practice' for any non-ASCOM
> > properties?
> >
> > For example, a driver will no doubt need additional properties (eg stepper
> > motor details, serial processing info) and also associated procedures.  Is
it
> > best to add these within the ASCOM driver, or is it better to create another
> > object which is called when the ASCOM driver initiliases - or is there some
> > better 3rd way?
> >
> > Also, if the answer is another object, how / where should that be called
> > within the ASCOM template?
> >
> > Thanks in advance - apologies for any obvious errors.
> >
> > 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
> >
> >
> >
>
> --
> ExchangeDefender Message Security: Click below to verify authenticity
> http://www.exchangedefender.com/verify.asp?id=nAPKRgCE030246&from=tim@...
> Complete email hygeine and business continuity solution available from
http://www.tigranetworks.co.uk
>

I'm right in line with Chris. Make your setup dialog the place where all the
low-level things like encoder multipliers, motor speeds, sensor adjustments,
whatever... the stuff that you need to adjust in order for the mount to be
closer to perfect.

   -- Bob

> The only properties you need to expose are those required for an application
> to operate properly. In most cases, that should be none except the existing
> ASCOM properties and methods. For instance, none of the examples you gave
> involve the client application.
>
> Most devices _do_ have device specific settings that need to be managed.
> These are normally setup operations handled only occasionally (or once) by
> the operator, not the client app. So the appropriate place for those things
> is in the setup dialog, which is invoked by standard ASCOM methods.
>
> Chris
>
> *****************************************
> Chris L Peterson
> Cloudbait Observatory
> http://www.cloudbait.com

It was being hosted on a Microsoft server (a result of the meltdown caused when
Worldwide Telescope was released and thousands downloaded the Platform). I have
moved it back to its previous place on the ASCOM site (in Michigan). The link
should be OK now.

   -- Bob

You said:
> Sorry to bug y'all.  I just tried to download the V5 package, but the link to
> the file is broken.  Anyone have a V5 copy sitting somewhere?

Hi all,

I've posted an update (5.5.1) to Platform 5.5 on the ASCOM-Standards web site, you can download it here: http://ascom-standards.org/Downloads/PlatformUpdates.htm 

The update fixes are:

1. ASCOM.Utilities.Serial - Fixed unintended dependency on framework3.5 which showed up as an exception: missing method -Mutex.WaitOne(Timeout as Integer) if framework 3.5 was not installed.
2. ASCOM.Utilities.Profile - Fixed a synchronisation issue caused when two Profile instances ran concurrently for the same device.
3. Setup - Added tolerance and correction for installations where applications have overwritten Helper Platform registration and registered the Helper component as being part of the application rather than being part of the platform itself.

This update will be of interest to everyone, particularly those who experienced issues after installing 5.5 and subsequently uninstalled it. Those of you who successfully installed 5.5 should also install this update because of the Profile bug fix.

The 5.5.1 installer will automatically uninstall 5.5, if it is present, before installing 5.5.1, so you just need to run the 5.5.1 installer after downloading it.

Issue 3 had particularly bad symptoms that could result in a completely non-functional Platform if one particular application had been installed before the Platform 5.5 update.

If you experience any further issues in 5.5.1 please post a message here.

Thanks, Peter

--- In ASCOM-Talk@yahoogroups.com, "Peter Simpson" <simpsons@...> wrote:
>
> The update fixes are:
>
>     2. ASCOM.Utilities.Profile - Fixed a synchronisation issue caused
> when two Profile instances ran concurrently for the same device.

What is the fix ?  (the tracker is unavailable at the time I'm writing).


Regards,
________
Christophe

Hi, I am trying to install the Gemini for Acsom driver however once installed it
is  not coming up in the ACSOM list of telescopes at all. I have run the profile
viewer and the "gemini" is not listed in there. Seems to me the installer is not
or cannot put these values in where they need to be.

Is there a way to repair the ACSOM platform or force the install somehow?

Any help would be greatly appreciated!

Thanks,
Regards,
Grahame.

That approach is fine, if the driver is intended ONLY to ever work with an
ASCOM-compatible application, but that's a limited world view. You know guys,
ASCOM is not the only solution and it doesn’t solve every problem. The
two-layer approach that I use gives a little bit more flexibility. Exposing
low-level properties and methods makes it easier to layer a GUI (hand
paddle/control panel) on top of the driver in addition to the ASCOM interface.
Equipment makers naturally want to differentiate their product with features,
this can't be expressed through the ASCOM interface but exposing low-level
access enables that to happen. The two are complimentary, not mutually
exclusive. Given our (justified) reluctance to expose this stuff in the ASCOM
interface, it makes sense to expose low-level access routines from a separate
class (or interface).

The design pattern I use will start to make more sense in Platform 6.0 once I
have the settings designer properly integrated with the ASCOM Profile provider.
--T.

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-
> Talk@yahoogroups.com] On Behalf Of Bob Denny
> Sent: Thursday, November 26, 2009 6:14 AM
> To: ASCOM-Talk@yahoogroups.com
> Subject: Re: [ASCOM] driver-writing: where to put additional non-ASCOM
> properties
>
> I'm right in line with Chris. Make your setup dialog the place where all the
> low-level things like encoder multipliers, motor speeds, sensor
> adjustments, whatever... the stuff that you need to adjust in order for the
> mount to be closer to perfect.
>
>   -- Bob
>
> > The only properties you need to expose are those required for an
> > application to operate properly. In most cases, that should be none
> > except the existing ASCOM properties and methods. For instance, none
> > of the examples you gave involve the client application.
> >
> > Most devices _do_ have device specific settings that need to be managed.
> > These are normally setup operations handled only occasionally (or
> > once) by the operator, not the client app. So the appropriate place
> > for those things is in the setup dialog, which is invoked by standard
> ASCOM methods.
> >
> > Chris
> >
> > *****************************************
> > Chris L Peterson
> > Cloudbait Observatory
> > http://www.cloudbait.com
>
>
> ------------------------------------
>
> 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
>
>
>

--
ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=nAQFYXRg012922&from=tim@tigranetwo\
rks.co.uk
Complete email hygeine and business continuity solution available from
http://www.tigranetworks.co.uk

You can diff the two versions and see what's changed that way.
--Tim

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-
> Talk@yahoogroups.com] On Behalf Of Bec à Fuel
> Sent: Thursday, November 26, 2009 2:06 PM
> To: ASCOM-Talk@yahoogroups.com
> Subject: [ASCOM] Re: ASCOM Platform 5.5.1 Update
>
> --- In ASCOM-Talk@yahoogroups.com, "Peter Simpson" <simpsons@...>
> wrote:
> >
> > The update fixes are:
> >
> >     2. ASCOM.Utilities.Profile - Fixed a synchronisation issue caused
> > when two Profile instances ran concurrently for the same device.
>
> What is the fix ?  (the tracker is unavailable at the time I'm writing).
>
>
> Regards,
> ________
> Christophe
>
>
>
> ------------------------------------
>
> 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
>
>
>

--
ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=nAQFc7rC013171&from=tim@tigranetwo\
rks.co.uk
Complete email hygeine and business continuity solution available from
http://www.tigranetworks.co.uk

The problem with drivers having their own custom interfaces is that it will
likely require clients to recompile whenever a driver changes a custom
interface. That could become a nightmare.

What I have been doing with  PEMPro is having driver writers put in custom
commands that are interpreted in CommandString() calls. It's more difficult than
using intellisense on an interface but it is guaranteed not to trigger an
application recompile.

An example CommandString call might be:

String sSlewRate = scope.CommandString("GetSlewRate");

sSlewRate will contain the mount's slew rate as a string.

Using CommandString() to extend the driver's capabilities doesn't change the
telescope interface or require a new interface so it will never require a
recompile just because a driver adds a new command about which my application
doesn't care. It has worked well for me for years so I think this is a design
pattern that driver authors should consider. The new AP ASCOM driver has a full
set of these commands from which I hope some powerful tools will be made in the
future (I need to finish documenting them first).

-Ray Gralak

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf
Of Tim Long
> Sent: Thursday, November 26, 2009 7:35 AM
> To: ASCOM-Talk@yahoogroups.com
> Subject: RE: [ASCOM] driver-writing: where to put additional non-ASCOM
properties
>
>
>
> That approach is fine, if the driver is intended ONLY to ever work with an
ASCOM-compatible application, but that's a limited world
> view. You know guys, ASCOM is not the only solution and it doesn’t solve
every problem. The two-layer approach that I use gives a
> little bit more flexibility. Exposing low-level properties and methods makes
it easier to layer a GUI (hand paddle/control panel) on
> top of the driver in addition to the ASCOM interface. Equipment makers
naturally want to differentiate their product with features,
> this can't be expressed through the ASCOM interface but exposing low-level
access enables that to happen. The two are
> complimentary, not mutually exclusive. Given our (justified) reluctance to
expose this stuff in the ASCOM interface, it makes sense
> to expose low-level access routines from a separate class (or interface).
>
> The design pattern I use will start to make more sense in Platform 6.0 once I
have the settings designer properly integrated with the
> ASCOM Profile provider.
> --T.
>
> > -----Original Message-----
> > From: ASCOM-Talk@yahoogroups.com <mailto:ASCOM-Talk%40yahoogroups.com> 
[mailto:ASCOM-
> > Talk@yahoogroups.com <mailto:Talk%40yahoogroups.com> ] On Behalf Of Bob
Denny
> > Sent: Thursday, November 26, 2009 6:14 AM
> > To: ASCOM-Talk@yahoogroups.com <mailto:ASCOM-Talk%40yahoogroups.com>
> > Subject: Re: [ASCOM] driver-writing: where to put additional non-ASCOM
> > properties
> >
> > I'm right in line with Chris. Make your setup dialog the place where all the
> > low-level things like encoder multipliers, motor speeds, sensor
> > adjustments, whatever... the stuff that you need to adjust in order for the
> > mount to be closer to perfect.
> >
> > -- Bob
> >
> > > The only properties you need to expose are those required for an
> > > application to operate properly. In most cases, that should be none
> > > except the existing ASCOM properties and methods. For instance, none
> > > of the examples you gave involve the client application.
> > >
> > > Most devices _do_ have device specific settings that need to be managed.
> > > These are normally setup operations handled only occasionally (or
> > > once) by the operator, not the client app. So the appropriate place
> > > for those things is in the setup dialog, which is invoked by standard
> > ASCOM methods.
> > >
> > > Chris
> > >
> > > *****************************************
> > > Chris L Peterson
> > > Cloudbait Observatory
> > > http://www.cloudbait.com <http://www.cloudbait.com>
> >
> >
> > ------------------------------------
> >
> > For more information see http://ASCOM-Standards.org/.
<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
<mailto:ASCOM-Talk-unsubscribe%40yahoogroups.com>
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> --
> ExchangeDefender Message Security: Click below to verify authenticity
>
http://www.exchangedefender.com/verify.asp?id=nAQFYXRg012922&from=tim@tigranetwo\
rks.co.uk
>
<http://www.exchangedefender.com/verify.asp?id=nAQFYXRg012922&from=tim@tigranetw\
orks.co.uk>
> Complete email hygeine and business continuity solution available from
http://www.tigranetworks.co.uk
> <http://www.tigranetworks.co.uk>
>
>
>
>

Sure, but that's why I made the distinction between properties and methods
that need to be accessed by a client app, and those that don't.

There's nothing wrong with adding non-ASCOM properties, but the minute you
do that you have essentially restricted full operation of your device to a
very limited number of applications- probably just one. You've lost the
advantage of having a common API.

IMO the right way to handle this is to adjust the standard as required. I
haven't noticed a reluctance to do this whenever an actual use case can be
demonstrated.

This is the ASCOM discussion group, after all! Hardly surprising that would
be our focus. My view is that I basically don't care how a driver writer
wants to make non-ASCOM features available. All I care about is how the
ASCOM properties get handled.

Chris

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


----- Original Message -----
From: "Tim Long" <Tim@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Thursday, November 26, 2009 8:34 AM
Subject: RE: [ASCOM] driver-writing: where to put additional non-ASCOM
properties


> That approach is fine, if the driver is intended ONLY to ever work with an
> ASCOM-compatible application, but that's a limited world view. You know
> guys, ASCOM is not the only solution and it doesn’t solve every problem.
> The two-layer approach that I use gives a little bit more flexibility.
> Exposing low-level properties and methods makes it easier to layer a GUI
> (hand paddle/control panel) on top of the driver in addition to the ASCOM
> interface. Equipment makers naturally want to differentiate their product
> with features, this can't be expressed through the ASCOM interface but
> exposing low-level access enables that to happen. The two are
> complimentary, not mutually exclusive. Given our (justified) reluctance to
> expose this stuff in the ASCOM interface, it makes sense to expose
> low-level access routines from a separate class (or interface).
>
> The design pattern I use will start to make more sense in Platform 6.0
> once I have the settings designer properly integrated with the ASCOM
> Profile provider.

Hi Ray-

Actually, what will happen is that most applications simply won't utilize
the custom interfaces. Most likely, an app supplied by the equipment maker
would, but no others. That's a good reason to try and stay away from custom
interfaces.

PEMPro is an unusual case. If I were you, I would have argued a long time
ago for an updated telescope standard that includes access to PE functions.
You've certainly demonstrated the need. You are basically carrying the
burden of writing individual drivers- just what ASCOM is supposed to avoid.

Chris

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


----- Original Message -----
From: "Ray Gralak (Yahoo Groups)" <yahoo@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Thursday, November 26, 2009 9:00 AM
Subject: RE: [ASCOM] driver-writing: where to put additional non-ASCOM
properties


The problem with drivers having their own custom interfaces is that it will
likely require clients to recompile whenever a driver changes a custom
interface. That could become a nightmare.

What I have been doing with  PEMPro is having driver writers put in custom
commands that are interpreted in CommandString() calls. It's more difficult
than using intellisense on an interface but it is guaranteed not to trigger
an application recompile.

An example CommandString call might be:

String sSlewRate = scope.CommandString("GetSlewRate");

sSlewRate will contain the mount's slew rate as a string.

Using CommandString() to extend the driver's capabilities doesn't change the
telescope interface or require a new interface so it will never require a
recompile just because a driver adds a new command about which my
application doesn't care. It has worked well for me for years so I think
this is a design pattern that driver authors should consider. The new AP
ASCOM driver has a full set of these commands from which I hope some
powerful tools will be made in the future (I need to finish documenting them
first).

-Ray Gralak

Hi Chris,

> Actually, what will happen is that most applications simply won't utilize
> the custom interfaces. Most likely, an app supplied by the equipment maker
> would, but no others. That's a good reason to try and stay away from custom
> interfaces.

Perhaps, but it is my experience that there is almost always someone out there
that wants to do something special. In fact I believe there is already someone
who has used the new Astro-Physics driver's ability to set the slew rate (in a
script) depending on temperature.

So I believe if the commands are documented they will see *some* use over time.
How much, I don't know, but they are there.

-Ray Gralak

That's an interesting technique but I think it solves a different problem to
what I was advocating. I can see the merit in what your technique, but there is
also a danger, because you're using the methods for a purpose other than their
documented purpose (sending raw data to the communications channel). Data sent
with CommandXXX is, by definition, not supposed to be interpreted by the driver
but passed along directly to the communications channel.

There will never be a need to recompile an ASCOM client because of a change in
the driver assembly if the best practices are followed, because the ASCOM
interfaces will not have changed and the loading is abstracted either by COM or
by ASCOM.DriverAccess and loading is always based on the ProgID, not the
assembly name/version. In other words, ASCOM clients never bind directly to the
driver. An application that is early-bound to the 'private' interface is (by
definition) NOT an ASCOM client, I'm thinking specifically of control panel type
applications that are designed specifically for one particular piece of
hardware. It will need to be recompiled if the 'private' interface changes, but
that's expected behaviour - by definition the two are device-specific and
tightly coupled and will normally evolve together.

--Tim

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-
> Talk@yahoogroups.com] On Behalf Of Ray Gralak (Yahoo Groups)
> Sent: Thursday, November 26, 2009 4:00 PM
> To: ASCOM-Talk@yahoogroups.com
> Subject: RE: [ASCOM] driver-writing: where to put additional non-ASCOM
> properties
>
> The problem with drivers having their own custom interfaces is that it will
> likely require clients to recompile whenever a driver changes a custom
> interface. That could become a nightmare.
>
> What I have been doing with  PEMPro is having driver writers put in custom
> commands that are interpreted in CommandString() calls. It's more difficult
> than using intellisense on an interface but it is guaranteed not to trigger an
> application recompile.
>
> An example CommandString call might be:
>
> String sSlewRate = scope.CommandString("GetSlewRate");
>
> sSlewRate will contain the mount's slew rate as a string.
>
> Using CommandString() to extend the driver's capabilities doesn't change
> the telescope interface or require a new interface so it will never require a
> recompile just because a driver adds a new command about which my
> application doesn't care. It has worked well for me for years so I think this
is
> a design pattern that driver authors should consider. The new AP ASCOM
> driver has a full set of these commands from which I hope some powerful
> tools will be made in the future (I need to finish documenting them first).
>
> -Ray Gralak
>
> > -----Original Message-----
> > From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-
> Talk@yahoogroups.com]
> > On Behalf Of Tim Long
> > Sent: Thursday, November 26, 2009 7:35 AM
> > To: ASCOM-Talk@yahoogroups.com
> > Subject: RE: [ASCOM] driver-writing: where to put additional non-ASCOM
> > properties
> >
> >
> >
> > That approach is fine, if the driver is intended ONLY to ever work
> > with an ASCOM-compatible application, but that's a limited world view.
> > You know guys, ASCOM is not the only solution and it doesn’t solve
> > every problem. The two-layer approach that I use gives a little bit
> > more flexibility. Exposing low-level properties and methods makes it
> > easier to layer a GUI (hand paddle/control panel) on top of the driver
> > in addition to the ASCOM interface. Equipment makers naturally want to
> differentiate their product with features, this can't be expressed through
> the ASCOM interface but exposing low-level access enables that to happen.
> The two are complimentary, not mutually exclusive. Given our (justified)
> reluctance to expose this stuff in the ASCOM interface, it makes sense to
> expose low-level access routines from a separate class (or interface).
> >
> > The design pattern I use will start to make more sense in Platform 6.0
> > once I have the settings designer properly integrated with the ASCOM
> Profile provider.
> > --T.
> >
> > > -----Original Message-----
> > > From: ASCOM-Talk@yahoogroups.com
> > > <mailto:ASCOM-Talk%40yahoogroups.com>  [mailto:ASCOM-
> > > Talk@yahoogroups.com <mailto:Talk%40yahoogroups.com> ] On Behalf
> Of
> > > Bob Denny
> > > Sent: Thursday, November 26, 2009 6:14 AM
> > > To: ASCOM-Talk@yahoogroups.com <mailto:ASCOM-
> Talk%40yahoogroups.com>
> > > Subject: Re: [ASCOM] driver-writing: where to put additional
> > > non-ASCOM properties
> > >
> > > I'm right in line with Chris. Make your setup dialog the place where
> > > all the low-level things like encoder multipliers, motor speeds,
> > > sensor adjustments, whatever... the stuff that you need to adjust in
> > > order for the mount to be closer to perfect.
> > >
> > > -- Bob
> > >
> > > > The only properties you need to expose are those required for an
> > > > application to operate properly. In most cases, that should be
> > > > none except the existing ASCOM properties and methods. For
> > > > instance, none of the examples you gave involve the client application.
> > > >
> > > > Most devices _do_ have device specific settings that need to be
> managed.
> > > > These are normally setup operations handled only occasionally (or
> > > > once) by the operator, not the client app. So the appropriate
> > > > place for those things is in the setup dialog, which is invoked by
> > > > standard
> > > ASCOM methods.
> > > >
> > > > Chris
> > > >
> > > > *****************************************
> > > > Chris L Peterson
> > > > Cloudbait Observatory
> > > > http://www.cloudbait.com <http://www.cloudbait.com>
> > >
> > >
> > > ------------------------------------
> > >
> > > For more information see http://ASCOM-Standards.org/.
> > > <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
> > > <mailto:ASCOM-Talk-unsubscribe%40yahoogroups.com>
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> >
> > --
> > ExchangeDefender Message Security: Click below to verify authenticity
> >
> http://www.exchangedefender.com/verify.asp?id=nAQFYXRg012922&from
> =tim@
> > tigranetworks.co.uk
> >
> <http://www.exchangedefender.com/verify.asp?id=nAQFYXRg012922&fro
> m=tim
> > @tigranetworks.co.uk> Complete email hygeine and business continuity
> > solution available from http://www.tigranetworks.co.uk
> > <http://www.tigranetworks.co.uk>
> >
> >
> >
> >
>
>
>
>
> ------------------------------------
>
> 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
>
>
>

--
ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=nAQGeIZb018826&from=tim@tigranetwo\
rks.co.uk
Complete email hygeine and business continuity solution available from
http://www.tigranetworks.co.uk

Hi Tim,

> That's an interesting technique but I think it solves a different problem to
what I was advocating. I can see the merit in what your
> technique, but there is also a danger, because you're using the methods for a
purpose other than their documented purpose
> (sending raw data to the communications channel). Data sent with CommandXXX
is, by definition, not supposed to be interpreted
> by the driver but passed along directly to the communications channel.

There is no danger if the driver author selects commands that are not used by
the telescope. Actually I simplified my example to make it clearer but an actual
command for the AP driver looks something like this:

CommandString("RAW,GetSlewRate", True);

I use "RAW," as a prefix and also have the client set the Raw Boolean flag. This
makes it very easy in the driver to determine if a command must be intercepted.
The result string always starts with a "0" or a "1". If a command is not
recognized or other the string is "0,<error message>". If the command succeeds a
"1" is returned followed by an optional value if the operation was a "get". For
instance in the case of GetSlewRate if the slew rate is 600x the string returned
would be "1,600". The "1" indicates success and "600" is the value.

The *most* important points are:

1) Changing a driver never requires a recompile.
2) Changes to a custom interface never requires changing the ProgID used to
create an extended interface (which is what a driver developer should do. An
interface name should never be modified once implemented).
3) Client applications don't need to manage a set of custom interfaces with
different names for each driver.

That said, I would like to see a command that explicitly allowed for extensions
in this manner. For example:

String ExtendedCommand(String command);

'command' is the extended command passed to the driver. The return string would
be the comma separated result returned from the command, as I described above.

> I'm thinking specifically of control panel type applications that are designed
specifically for one particular piece of hardware. It will
> need to be recompiled if the 'private' interface changes, but that's expected
behaviour - by definition the two are device-specific and
> tightly coupled and will normally evolve together.

If private interfaces changed then a recompile (and program changes) might be
necessary to a client using those private interfaces. Then there is the issue of
managing multiple versions of the interface. The design pattern I mentioned
above is trivial compared to the management of a set of unique interfaces across
all drivers.

I think it would be possible to define a list of custom CommandString() keywords
that would be used across any driver that supported that keyword. This would at
least minimize the list of commands a client might need to be aware of.

-Ray

> If private interfaces changed then a recompile (and program changes) might
> be necessary to a client using those private interfaces. Then there is the
> issue of managing multiple versions of the interface. The design pattern I
> mentioned above is trivial compared to the management of a set of unique
> interfaces across all drivers.

[TPL] I realized that I'm being pretty sloppy in my use of words. To clarify,
when I said 'interface' what I really meant was just the set of public
properties and methods exposed by a class. I didn’t necessarily mean a formal
interface definition. I really don’t think versioning is an issue because the
scenario I'm envisioning means that the components are inherently interdependent
and would install as a matched set.

--Tim

--
ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=nAQIAAAY025651&from=tim@tigranetwo\
rks.co.uk
Complete email hygeine and business continuity solution available from
http://www.tigranetworks.co.uk

--- In ASCOM-Talk@yahoogroups.com, "Chris Peterson" <cpeterson@...> wrote:
>
>
> IMO the right way to handle this is to adjust the standard as required. I
> haven't noticed a reluctance to do this whenever an actual use case can be
> demonstrated.
>
The reluctance is not in (not) adjusting the standard, it's only in accepting a
"use case"... You will always say it's not "demonstrated".

The result is the development of "private" client apps/drivers that will use the
device with all its abilities. But not with Ascom.

That's not a problem, in fact. For basic operation, if a driver exists, then it
will work as expected. But for advanced operation, then the app will either call
the device's API or use its own plugins to deal with it.
MaximDL does it, as well as Prism and many others.

Why do these devs code if "no use case were demonstrated" ? Do they have money
or time to loose ?

IMO, that is also the main reason that not every new device comes with an Ascom
driver. New devices are not basic anymore and vendors won't ship them with a
driver that would limit its useability.


Btw, I will still annoy you by requesting a set of "CommandXXX" for the focuser
interface. It is nearly the only one that does not have them.
But I won't try to demonstrate anything. If the interface is not changed, then I
will stay away. No problem.
It's easier to tell people that "Ascom can't do that" than to explain how it
could be done (if possible).


Regards,
_________
Christophe

> > If private interfaces changed then a recompile (and program changes) might
> > be necessary to a client using those private interfaces. Then there is the
> > issue of managing multiple versions of the interface. The design pattern I
> > mentioned above is trivial compared to the management of a set of unique
> > interfaces across all drivers.
>
> [TPL] I realized that I'm being pretty sloppy in my use of words. To clarify,
when I said 'interface' what I really meant was just the set
> of public properties and methods exposed by a class. I didn’t necessarily
mean a formal interface definition. I really don’t think
> versioning is an issue because the scenario I'm envisioning means that the
components are inherently interdependent and would
> install as a matched set.

I think the issue of versioning private "interfaces" is very important because
they will likely change much more often than the ASCOM platform itself I think
if that happened it might be difficult  for client apps to maintain them. I
think that would discourage client app writers from using the interfaces as
Chris mentioned.

However, by using the simple design pattern I mentioned it becomes very simple
for client authors to manage extended driver capabilities because it is very
easy to build/parse strings.

-Ray

Christophe,

I would be in support of a ExtendedCommand() function for all drivers to use as
I mentioned in my previous post. This
would allow custom extensions for any driver (telescope, focuser, camera, etc.)

-Ray

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf
Of Bec à Fuel
> Sent: Thursday, November 26, 2009 10:16 AM
> To: ASCOM-Talk@yahoogroups.com
> Subject: Re: [ASCOM] driver-writing: where to put additional non-ASCOM
properties
>
>
>
> --- In ASCOM-Talk@yahoogroups.com <mailto:ASCOM-Talk%40yahoogroups.com> ,
"Chris Peterson" <cpeterson@...> wrote:
> >
> >
> > IMO the right way to handle this is to adjust the standard as required. I
> > haven't noticed a reluctance to do this whenever an actual use case can be
> > demonstrated.
> >
> The reluctance is not in (not) adjusting the standard, it's only in accepting
a "use case"... You will always say it's
not "demonstrated".
>
> The result is the development of "private" client apps/drivers that will use
the device with all its abilities. But
not with Ascom.
>
> That's not a problem, in fact. For basic operation, if a driver exists, then
it will work as expected. But for
advanced operation, then
> the app will either call the device's API or use its own plugins to deal with
it.
> MaximDL does it, as well as Prism and many others.
>
> Why do these devs code if "no use case were demonstrated" ? Do they have money
or time to loose ?
>
> IMO, that is also the main reason that not every new device comes with an
Ascom driver. New devices are not basic
anymore and
> vendors won't ship them with a driver that would limit its useability.
>
> Btw, I will still annoy you by requesting a set of "CommandXXX" for the
focuser interface. It is nearly the only one
that does not
> have them.
> But I won't try to demonstrate anything. If the interface is not changed, then
I will stay away. No problem.
> It's easier to tell people that "Ascom can't do that" than to explain how it
could be done (if possible).
>
> Regards,
> _________
> Christophe
>
>
>
>

 

The reluctance is not in (not) adjusting the standard, it's only in accepting a "use case"... You will always say it's not "demonstrated".

The result is the development of "private" client apps/drivers that will use the device with all its abilities. But not with Ascom.

That's not a problem, in fact. For basic operation, if a driver exists, then it will work as expected. But for advanced operation, then the app will either call the device's API or use its own plugins to deal with it.
MaximDL does it, as well as Prism and many others.

Why do these devs code if "no use case were demonstrated" ? Do they have money or time to loose ?

IMO, that is also the main reason that not every new device comes with an Ascom driver. New devices are not basic anymore and vendors won't ship them with a driver that would limit its useability.

Btw, I will still annoy you by requesting a set of "CommandXXX" for the focuser interface. It is nearly the only one that does not have them.
But I won't try to demonstrate anything. If the interface is not changed, then I will stay away. No problem.
It's easier to tell people that "Ascom can't do that" than to explain how it could be done (if possible).

Regards,
_________
Christophe

-- +------------------------------------------------------------------+
| AM Amateur Radio Operator NØDGN | +------------------------------------------------------------------+
| http://home.comcast.net/~rbethman/ |
+------------------------------------------------------------------+
| Bob Bethman \\\|/// " The absence of a danger |
| \\ ~ ~ // signal does *NOT* mean |
| rbethman@... (/ @ @ /) that everything is OK " |
+----------------------o00o---°(_)°---o00o-------------------------+

--- In ASCOM-Talk@yahoogroups.com, rbethman <rbethman@...> wrote:
>
> Christophe,
>
> I've read ALL of your posts.
Thank you very much.


It's not only about _my_ point of vue or desiderata. As a developer, I have done
Ascom drivers for many people that were using custom hardware or for devices
that didn't already have a driver.

For many of those devices, the standard interface was enough. For some others,
it was not. And those devices are becoming affordable and common for "hand-made"
focusers or filter wheels, for example.

That was the main reasons I've asked for changes. It's only too bad that I was
the only one to speak because those people couldn't argue as they are "simple
users". They want their devices to work, no matter how it is done. It's not even
a client app, it's a client. Final stage on the scale.


Now, like we say in France, I have put some water in my wine and only ask for
the CommandXXXX in the focuser interface. This will give "me" an escape door to
do what "I" want, while still in the Ascom standard.
Me an I being guys that ask for a driver or a controling app.
It can be done in the telescope or in the dome interfaces, for example. Why not
in the focuser ?


You're right on one point, though : if Ascom does not change on this point, I
will go away. You didn't even need to tell me.

And that's already what I've _done_ for one project. A board drives
simultaneously two Accufocus, along with 4 "end of run" (?) contacts that halts
them if necessary.
Both focusers can be accessed locally/remotely, it can even be driven at the
same time by an Ascom driver I've also made; but without the contact stuff, of
course, and one motor at a time.


You're not obliged to read my posts, anyway. I won't be sad if you don't.


Regards,
________
Christophe

 

--- In ASCOM-Talk@yahoogroups.com, rbethman <rbethman@...> wrote:
>
> Christophe,
>
> I've read ALL of your posts.
Thank you very much.

It's not only about _my_ point of vue or desiderata. As a developer, I have done Ascom drivers for many people that were using custom hardware or for devices that didn't already have a driver.

For many of those devices, the standard interface was enough. For some others, it was not. And those devices are becoming affordable and common for "hand-made" focusers or filter wheels, for example.

That was the main reasons I've asked for changes. It's only too bad that I was the only one to speak because those people couldn't argue as they are "simple users". They want their devices to work, no matter how it is done. It's not even a client app, it's a client. Final stage on the scale.

Now, like we say in France, I have put some water in my wine and only ask for the CommandXXXX in the focuser interface. This will give "me" an escape door to do what "I" want, while still in the Ascom standard.
Me an I being guys that ask for a driver or a controling app.
It can be done in the telescope or in the dome interfaces, for example. Why not in the focuser ?

You're right on one point, though : if Ascom does not change on this point, I will go away. You didn't even need to tell me.

And that's already what I've _done_ for one project. A board drives simultaneously two Accufocus, along with 4 "end of run" (?) contacts that halts them if necessary.
Both focusers can be accessed locally/remotely, it can even be driven at the same time by an Ascom driver I've also made; but without the contact stuff, of course, and one motor at a time.

You're not obliged to read my posts, anyway. I won't be sad if you don't.

Regards,
________
Christophe

Gday Chris

--- In ASCOM-Talk@yahoogroups.com, "Chris Peterson" <cpeterson@...> wrote:
>
> Actually, what will happen is that most applications simply
> won't utilize the custom interfaces. Most likely, an app
> supplied by the equipment maker would, but no others.
> That's a good reason to try and stay away from custom
> interfaces.
>
> PEMPro is an unusual case. If I were you, I would have argued
> a long time ago for an updated telescope standard that
> includes access to PE functions.

Just for info, there was a long thread on this mid 2007
Ref http://tech.groups.yahoo.com/group/ASCOM-Talk/message/12194
for a mid point start.
Basically, PEC was deemed to be not important for "operating" a scope.
Adding a new property to the telescope interface wouldnt have broken anything (
that i can tell ), but would have allowed future expansion
if required.

Andrew Johansen Melbourne Australia


> You've certainly demonstrated the need. You are basically carrying the
> burden of writing individual drivers- just what ASCOM is supposed to avoid.
>
> Chris
>
> *****************************************
> Chris L Peterson
> Cloudbait Observatory
> http://www.cloudbait.com
>
>
> ----- Original Message -----
> From: "Ray Gralak (Yahoo Groups)" <yahoo@...>
> To: <ASCOM-Talk@yahoogroups.com>
> Sent: Thursday, November 26, 2009 9:00 AM
> Subject: RE: [ASCOM] driver-writing: where to put additional non-ASCOM
> properties
>
>
> The problem with drivers having their own custom interfaces is that it will
> likely require clients to recompile whenever a driver changes a custom
> interface. That could become a nightmare.
>
> What I have been doing with  PEMPro is having driver writers put in custom
> commands that are interpreted in CommandString() calls. It's more difficult
> than using intellisense on an interface but it is guaranteed not to trigger
> an application recompile.
>
> An example CommandString call might be:
>
> String sSlewRate = scope.CommandString("GetSlewRate");
>
> sSlewRate will contain the mount's slew rate as a string.
>
> Using CommandString() to extend the driver's capabilities doesn't change the
> telescope interface or require a new interface so it will never require a
> recompile just because a driver adds a new command about which my
> application doesn't care. It has worked well for me for years so I think
> this is a design pattern that driver authors should consider. The new AP
> ASCOM driver has a full set of these commands from which I hope some
> powerful tools will be made in the future (I need to finish documenting them
> first).
>
> -Ray Gralak
>

--- In ASCOM-Talk@yahoogroups.com, rbethman <rbethman@...> wrote:
>
> > It's not only about _my_ point of vue or desiderata. As a developer, I
> > have done Ascom drivers for many people that were using custom
> > hardware or for devices that didn't already have a driver.
> >
> You have hit on precisely the real issue.  Custom devices cannot
> arbitrarily modify the Specifications or Standard.  If this was to be
> the "allowed" case, there would NOT be Standards, NOR Specifications.

What I did say is that _I've written Ascom drivers_ for such custom devices.
Many of them didn't need any change. But not all of them.

To me, actual focuser specs don't have room for dealing with improved devices.
Hence my claims for at least the CommandXXX methods.
This would help dealing with upcoming devices without disturbing the interface
(the so-called standard).

Even with simple hardware (no inputs/outputs or whatever), how would you drive 2
focusers with an Ascom driver ? Am I the only one that have 2 focusers (imager &
guider) ? Am I the only one that need to have motorized focus on both ?
"Best" solution today, as proposed by an Ascom member, was to develop two
drivers, one for each motor... With all the ugly stuff about concurrent access
of the board, of course.

Other solution (which I've used in the driver mentionned earlier) is to have a
choice of the active motor in the setup dialog box...
If you want to drive motor 1 then you open the dialog box, select it, modify its
parameters if needed, then close the window and come back to the client app.
Client app that is also meant to drive only one motor at a time, of course,
because the driver lacks the ability to drive more than one at a time...
Classical like the "who was there first? the chicken or the egg?"

Restricting standard also restricts application that rely on it.

Persons that use only barbecue motors may not even need an Ascom driver and will
be happy with two switches to drive their motor.
But if you have an USB interface that can drives more than one motor along with
some inputs/outputs, then if the standard can't deal with it, then the standard
is out-dated.
A standard should not be meant for the past, but for the future (while including
as much past as possible).

> >
> Final stage on the scale would seem to be the driver.
We won't agree here. Sorry. For me, the driver is the first stage. Low level.

> >
> The platform and many drivers are in a migrating process to move from
> older no longer to be supported development tools, to the newer ones
> that have become the main ones.

Platform is migrating to support new development tools only, not new devices.
Too bad.

> >
> >
> So it would appear that you would "expect" everything to change the
> "next" time another "CUSTOM" device pops up as a "one-of-a-kind".  It is
> an unrealistic expectation.
No, I would expect that the standard is smart enough to permit things authors
didn't think of when it was written. Not more. Not less.


> I know that I'm not obliged to read everything.  I am also wise enough
> to know how standards and specifications are created.  I did extensive
> work on the X.400 and X.500 standards development to create a WORKING
> framework from the CCITT/ITU catch-all that left everything in the air,
> and NOTHING that would work with anything else except itself.
I've read texts on this some months ago. I can't remember why but I think it was
related to complexity of something. Sorry I can't remember more than a drawing
on a web page that showed that complexity with many interactions between
different services and different protocols. Was your working about this ?


Regards,
________
Christophe

rbethman wrote:
<->
> I know that I'm not obliged to read everything.  I am also wise enough
> to know how standards and specifications are created.  I did extensive
> work on the X.400 and X.500 standards development to create a WORKING
> framework from the CCITT/ITU catch-all that left everything in the air,
> and NOTHING that would work with anything else except itself.

Thanks for your support Bob.

The impression I get is that the more experience people have with
implementing and maintaining standards the less enthusiastic they are to
change them.

Chris

Bob Bethman:
> [...] CCITT/ITU catch-all that left everything in the air, and NOTHING that
> would work with anything else except itself.

I feel your pain. I went through that era. I was blackballed from speaking at
the Electronic Messaging Association meetings for speaking out against
X.400/X.500 in favor of dotted domain naming and something less bizarre for
directory services (like distributed SQL). I correctly predicted its death. I'm
amazed anyone made anything useful from those CCITT/ITU "design and decree"
specs that were the products of academics and not engineers.

Thank you for speaking up here.

   -- Bob