ASCOM - mandatory driver features

[Urban Dome]

Hi,

Here's a question for one of the ASCOM guys.

I have a commercial telescope mount controller for which the ASCOM driver includes a mandatory feature for GEM users. It forces the mount to either stop tracking or auto-flip when the mount has tracked beyong the Meridian by a given amount. You can choose either option but not disable the feature.

Yes it prevents a GEM mounted scope crash into the pier. But my pier is unconventional & a collision is mechanically\physically impossible.

If like me you image using client software such as SGP, then obviously the last thing you want is for the tracking to stop or the mount to flip mid image outside the control of the sequencing software. Therefore I'm forced to use SGP's meridian flip feature with timing geared to suit.

Because my pier design means there's no possibilty of any collision for my refractor I would like to track past the meridian and go 'weights up' until I potentially run out of sky, thus avoiding the inevitable wasted time required for a meridian flip, re-centering, plate solving etc.

If you're taking 30min subs in the UK then every wasted imaging minute counts.

The driver developer seems reluctant to make this feature optional & give the end user the choice.

I thought in the 'spirit' of all things ASCOM then the client was king & to dictate such mandatory behaviour would at least be considered presumptious? Is anyone able to point me in the direction of any official ASCOM literature explaning what is required of an ASCOM developer, what should be forbidden & what might be frowned uopn?

Many thanks

[malc-c]

You've been very cagey not naming names of the equipment you have and the software you are using, so it's hard to comment.  I do know that software such as EQMOD does allow you to remove limits and disable a flip, but you mention a commercial controller which I'm guessing doesn't run windows....

I'm also intrigued how you have a pier that makes it impossible for a scope to strike it... Any mount in a weights up surely has a risk of having the scope strike the pier  ?

[Patrick Chevalley]

You can read the ASCOM Telescope specification here: https://www.ascom-standards.org/Help/Developer/html/T_ASCOM_DeviceInterface_ITelescopeV3.htm

To my knowledge there is no requirement about automatic flip initiated by the driver. I agree with you this is more of a nuisance, if required the flip must be commanded by the imaging application between exposure.

[Urban Dome]

Hi Malcolm,

Yes I've been deliberately cagey about naming names. All I'm really interested in at the moment is an ASCOM perspective such as any expansion on the developer notes they publish in the ASCOM developer section of the website.

Regarding my pier it's essentially a conventional pier fitted to a large wedge so that it points to the pole. The RA drive rotates on a plane thats parallel to the wedge & the DEC drive is fitted at 90 deg to that plane. So it's an equatorial that operates as a GEM but no part of the mount or the scope (or anything fitted to the scope) can ever strike the pier.

 

Hi Patrick,

Thank you for offering your take on it I appreciate your view & I'm sure you are right. I'll keep looking & see if I can find anything written that would confirm it.

[malc-c]

Again, without knowing the equipment people may struggle making suggestions, and could be wasting yours and their time.  For example I could spout on about EQMOD being  an ASCOM compliant "driver" for SW/Orion mounts  with configurable limits, and options to chose an auto Meridian flip or not... but if your hardware isn't supported by EQASCOM/EQMOD then it's of no use to you whatso ever...  I confess I'm not interested in the depths and complexities of how ASCOM communicates between applications, so long as my planetarium application, camera control application, PHD2 and EQMOD all talk to each other and work, then for me that's all I need to know

[StevieDvd]

So if I understand this correctly the driver for your type of mount has settings for avoiding mount/scope collisions (which users have probably requested at some stage) but in your case you want to ignore these settings. If you are the first and only person requesting such a change I can see why the developer would be reluctant to add it on a single request. They would need to assess the likelyhood of the change affecting the existing/new users (if they set the values, as you need, in error) since that could end up with equipment damaged.

Coming from many years in the software industry I always used the ethos of 'first do no harm'  before considering any system changes.  Considering the driver author(s) are either a single coder or small set of individuals doing the code for free it's their choice how to maintain the code and what enhancements they consider worthy.

Just my opinion  - others can agree/disagree as they choose.

 

 

 

[malc-c]

Steve, it depends on the software developer....  Currently there are two main interfaces for telescope control when it comes to Skywatcher mounts (and again we're speculating here as the OP is being secretive about the equipment and all this may be irrelevent).  EQMD and GSServer.   The development team of both products have always been flexible and added functionality to these products, even if it only benefited the minority or single user.  For example, a decade back when I was experimenting with converting an HEQ5 to belt drive (long before Rowan Astro came on the scene) Chris at EQMOD added the option for custom gear settings for 3:1, 4:1 and 5:1 gearing ratios, as it was impossible to get off the shelf pulleys to match the factory set ratio.  The guys at GSS server later added this when I started playing with that as an alternative to EQMOD, even though I was probably the only guy wishing to have that functionality.  GSS server had its own operational quirkiness that meant I went back to EQMOD for my choice of telescope control, but that is another story.

In my case the changes didn't really have any safety issues.. If the request was to remove a safety feature, or modify something that could result in someone else with a standard set up driving the scope into the mount then I can see why developers may be reluctant to make those changes... 

[StevieDvd]

Malcolm, I think the issue is restricted to GEM mount types and limited to a specific driver, hence the interaction between the poster and the GEM driver developer.

The poster really needs to find other GEM/EQMOD users who feel this feature would be a benefit, any GEM users reading this will have a more informed opinon than mine on the need.