Trouble with MaxDome II slaving to APPM


Shane Ramotowski
 

No problem, Alan.  Glad to have been some help!

- Shane

On 9/23/2021 11:49 AM, Alan Erickson wrote:
Hi Shane,

Thanks for the tip about Device Hub. That plus passive mode did the trick. I use SGP, but when that is connected to the dome, I can't make another connection, so APPM couldn't monitor the dome. I think the MaxDome II ASCOM driver doesn't want multiple connections.

-Alan
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Alan Erickson
 

Hi Shane,

Thanks for the tip about Device Hub. That plus passive mode did the trick. I use SGP, but when that is connected to the dome, I can't make another connection, so APPM couldn't monitor the dome. I think the MaxDome II ASCOM driver doesn't want multiple connections.

-Alan 


Ray Gralak
 

It's a problem with APPM, not MAXDome.
Again, not really. For MaxDome operation and setting up slaving of the dome to the scope, please take a look at this link:

https://cdn.diffractionlimited.com/help/maxdome/MaxDome.htm

-Ray


Ray Gralak
 

Shane,

You can use the "Passive"mode (in "AP Point Mapper -> Dome Settings" and
ASCOM's Device Hub or SGP's Dome Slaving, but you will likely have to
add significant delays so that APPM can recognize that the dome is
moving . The big disadvantage of this is that your mapping settings
will take hours--I guess that's OK since you shouldn't need to do them
that often...
How much delay do you have configured in APPM for passive dome mode?

If it is 5+5 seconds for each point, then 360 points would add up to 3600 seconds (1 hour) maximum of extra time. If it takes "hours" to create a model, then maybe the dome driver is not promptly reporting movements, which would allow you to reduce the delays?

-Ray


Ray Gralak
 

Hi Shane,

According to Ray, there are no plans to fix APPM's "Active" mode as he
believes that dome geometry should be built into the dome driver. But
it's not. ASCOM standards do not include dome geometry, nor the ability
for the low level drivers (dome and telescope) to exchange information
and send commands to each other. Every other application I've used that
claims to do dome/mount slaving/coordination implements dome geometry.
ASCOM has argued that each application writer doesn't have to reinvent the wheel to use a device, like a telescope mount. However, to actively control a Dome, as you point out, applications HAVE to reinvent the wheel (i.e., dome geometry). My guess at the reason for the "dumb" ASCOM Dome driver API is to "protect" early commercial applications that had already included the dome geometry functionality.

According to Ray, there are no plans to fix APPM's "Active" mode as he
believes that dome geometry should be built into the dome driver.
And that's true because using Passive mode works well enough. You should not have to build a model very often with a permanent setup, so if it takes a little longer, so what. You can build a model on a moonlit night or when the skies have a thin cirrus layer.

That said, soon there may be a platform where people can post new feature requests, and users can vote for the features that interest them. Then, based on popularity and difficulty of implementation, A-P will prioritize and potentially authorize new features to be built into APCC. So, Shane, you can post your feature request there and let other mount owners vote on it.

I don't really know why there is an "Active" mode--I guess if you have a
really small scope or a really wide dome slot, it might work. But my
scope is a 4 inches and the doe slot is 18 inches wide and I still can't
use it.
Active mode works with POTH, which has since been deprecated by the ASCOM team. The "replacement " application, Device Hub, does not include the necessary functionality from POTH, and the author has decided not to port it. BTW, I even offered a solution that would be an extension of the ASCOM API, but it was rejected. So, if you want to put blame somewhere, put it on ASCOM. ASCOM is not providing full backward compatibility for their platform and has mantras that they say they follow, except when they don't.

-Ray



-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Monday, September 20, 2021 4:33 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Trouble with MaxDome II slaving to APPM

Hi Alan,

I ran into this a few months ago. AAPM does not have a way to do dome
geometry so it's dome positioning command are wrong. They are all based
from the center of the dome instead of where the telescope is. You've
seen the first dome slew; the rest are incorrect also most end up with
the dome partially or totally occluding the scope.

There is an extended topic about this from February:
<https://ap-gto.groups.io/g/main/message/76596>

According to Ray, there are no plans to fix APPM's "Active" mode as he
believes that dome geometry should be built into the dome driver. But
it's not. ASCOM standards do not include dome geometry, nor the ability
for the low level drivers (dome and telescope) to exchange information
and send commands to each other. Every other application I've used that
claims to do dome/mount slaving/coordination implements dome geometry.

I don't really know why there is an "Active" mode--I guess if you have a
really small scope or a really wide dome slot, it might work. But my
scope is a 4 inches and the doe slot is 18 inches wide and I still can't
use it.

You can use the "Passive"mode (in "AP Point Mapper -> Dome Settings" and
ASCOM's Device Hub or SGP's Dome Slaving, but you will likely have to
add significant delays so that APPM can recognize that the dome is
moving . The big disadvantage of this is that your mapping settings
will take hours--I guess that's OK since you shouldn't need to do them
that often...

The good news is that both Device Hub and SGP are smart enough to slew
the dome to the correct position, even when the mount goes counterweight
up!

Good Luck - Shane

On 9/19/2021 4:47 PM, alanericksonf6@hotmail.com wrote:
Hi. I'm trying to run APPM with MaxDome II. The first image attempt at
the zenith fails due to the dome being 180 degrees off. The scope is
on the west side of the mount / counterweights on the east. The dome
shutter azimuth is east, but it really should be west because that's
where the scope is. Image attached. Any ideas?

Thanks.
-Alan

--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net




Ray Gralak
 

APPM’s calling the shots in regards to the maxdome moves, so I betcha I’d be calling for help here too.
Actually, APPM is not calling the shots. Because of the poor API design of the ASCOM Dome drivers, the dome driver is usually “dumb” and doesn’t know about mount geometry, so APPM’s “Active” mode usually won’t work.

So, the only way to use a dome with APPM is to put it in “passive” mode where it just watches the dome’s movement until it stops. APPM has configurable delays to wait before starting for checking for dome movement, as well as a time to wait after the dome stops moving.

-Ray


From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
Sent: Sunday, September 19, 2021 9:59 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Trouble with MaxDome II slaving to APPM


This really isn't the right forum for MaxDome-II support.

Not sure why it wouldn’t be...

APPM’s calling the shots in regards to the maxdome moves, so I betcha I’d be calling for help here too.

Funny how some people seem to first think of integrated systems issues as if all problems can only be solved by troubleshooting single component as if it were sitting alone.


Seems pretty obvious to me that when two (or more) pieces of hardware and/or software are integrated together, there are not so many other options but to inquire for help from the parties involved (be it a manufacturer, developer, vendor, etc.)


I unfortunately can’t be of much help to the op’s issue, but man I would definitely not discourage him asking for help here about this !


Sébastien


Shane Ramotowski
 

It's a problem with APPM, not MAXDome. <https://ap-gto.groups.io/g/main/message/76596>

- Shane

On 9/19/2021 5:55 PM, Christopher Erickson wrote:
This really isn't the right forum for MaxDome-II support. Diffraction Limited has their own support forum and there is the Observatory forum on Cloudy Nights.

Is this something that has worked reliably in the past and suddenly started to fail?

I would double-check your az encoder mechanical setup and your MaxDome-II ASCOM driver parameters. Extraneous light near the az encoder can fool an optosenser.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com <http://www.summitkinetics.com>

On Sun, Sep 19, 2021, 1:04 PM <alanericksonf6@hotmail.com <mailto:alanericksonf6@hotmail.com>> wrote:

Hi. I'm trying to run APPM with MaxDome II. The first image
attempt at the zenith fails due to the dome being 180 degrees off.
The scope is on the west side of the mount / counterweights on the
east. The dome shutter azimuth is east, but it really should be
west because that's where the scope is. Image attached. Any ideas?

Thanks.
-Alan

--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Shane Ramotowski
 

Hi Alan,

I ran into this a few months ago.  AAPM does not have a way to do dome geometry so it's dome positioning command are wrong.  They are all based from the center of the dome instead of where the telescope is.  You've seen the first dome slew; the rest are incorrect also most end up with the dome partially or totally occluding the scope.

There is an extended topic about this from February: <https://ap-gto.groups.io/g/main/message/76596>

According to Ray, there are no plans to fix APPM's "Active" mode as he believes that dome geometry should be built into the dome driver.  But it's not.  ASCOM standards do not include dome geometry, nor the ability for the low level drivers (dome and telescope) to exchange information and send commands to each other. Every other application I've used that claims to do dome/mount slaving/coordination implements dome geometry.

I don't really know why there is an "Active" mode--I guess if you have a really small scope or a really wide dome slot, it might work.  But my scope is a 4 inches and the doe slot is 18 inches wide and I still can't use it.

You can use the "Passive"mode (in "AP Point Mapper -> Dome Settings" and ASCOM's Device Hub or SGP's Dome Slaving, but you will likely have to add significant delays so that APPM can recognize that the dome is moving .  The big disadvantage of this is that your mapping settings will take hours--I guess that's OK since you shouldn't need to do them that often...

The good news is that both Device Hub and SGP are smart enough to slew the dome to the correct position, even when the mount goes counterweight up!

Good Luck - Shane

On 9/19/2021 4:47 PM, alanericksonf6@hotmail.com wrote:
Hi. I'm trying to run APPM with MaxDome II. The first image attempt at the zenith fails due to the dome being 180 degrees off. The scope is on the west side of the mount / counterweights on the east. The dome shutter azimuth is east, but it really should be west because that's where the scope is. Image attached. Any ideas?

Thanks.
-Alan

--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Sébastien Doré
 


This really isn't the right forum for MaxDome-II support.

Not sure why it wouldn’t be...

APPM’s calling the shots in regards to the maxdome moves, so I betcha I’d be calling for help here too. 

Funny how some people seem to first think of integrated systems issues as if all problems can only be solved by troubleshooting single component as if it were sitting alone.

Seems pretty obvious to me that when two (or more) pieces of hardware and/or software are integrated together, there are not so many other options but to inquire for help from the parties involved (be it a manufacturer, developer, vendor, etc.) 

I unfortunately can’t be of much help to the op’s issue, but man I would definitely not discourage him asking for help here about this !

Sébastien 




Christopher Erickson
 

This really isn't the right forum for MaxDome-II support. Diffraction Limited has their own support forum and there is the Observatory forum on Cloudy Nights.

Is this something that has worked reliably in the past and suddenly started to fail?

I would double-check your az encoder mechanical setup and your MaxDome-II ASCOM driver parameters. Extraneous light near the az encoder can fool an optosenser.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Sun, Sep 19, 2021, 1:04 PM <alanericksonf6@...> wrote:
Hi. I'm trying to run APPM with MaxDome II. The first image attempt at the zenith fails due to the dome being 180 degrees off. The scope is on the west side of the mount / counterweights on the east. The dome shutter azimuth is east, but it really should be west because that's where the scope is. Image attached. Any ideas?

Thanks.
-Alan


Alan Erickson
 

Hi. I'm trying to run APPM with MaxDome II. The first image attempt at the zenith fails due to the dome being 180 degrees off. The scope is on the west side of the mount / counterweights on the east. The dome shutter azimuth is east, but it really should be west because that's where the scope is. Image attached. Any ideas?

Thanks.
-Alan