Date   

Re: Having lots of issues with APCC, Point mapper and other ASCOM products...

Ray Gralak
 

Hi Tom,

Ok. Actually what was happening is that none of the virtual ports were being created. Now that they are, it
seems to be fine.
APCC's Mount group box settings are set by default to allocate and create the virtual ports when APCC starts. Unless you have a good reason to change the settings, you shouldn't change them. Specifically, you should leave the Mount group box's "Auto-Connect" and "Create Virtual ports first" enabled. Also, the AP V2 Driver's "Auto-Config" should be enabled. This last setting is very important, because it reconfigures the ASCOM driver's port number to whatever virtual ports APCC dynamically allocates.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Tom Blahovici
Sent: Monday, September 20, 2021 9:48 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Having lots of issues with APCC, Point mapper and other ASCOM products...

HI
Ok. Actually what was happening is that none of the virtual ports were being created. Now that they are, it
seems to be fine. However, I have some questions.

1. What is the purpose of the AP V2 connect button in APCC? Why does APCC need to connect to the driver?
Applications seem to work fine even if this is not connected.
2. Once I have my mapping done, do I need to use the APPM software to do an initial sync and recal before
using Voyager?
3. Must all recals be turned off in other software when you are using a model?
4. Tonight I did a 100 point model. When the scope went into the west, clouds rolled in and I only got part of
the points there. Do I need to redo the whole model? Or can just the missing points be done or added?
I guess that covers the questions for now.

Thanks, Tom


Re: Having lots of issues with APCC, Point mapper and other ASCOM products...

Tom Blahovici
 

Thanks Brian. Answers a lot.

There are a couple of other items.
Voyager has a mount option to not do a recal. It's called "Not sync if using pointing model. " That's why I asked.

Now I used PemPro for the polar alignment. It gave me a drift of 15 arc seconds over 10 minutes in both axis. However after the model, the parameters for the polar alignment said I was off by 1.5 minutes in azimuth. How is this reconciled?

I'm getting there.
Tom


Re: Having lots of issues with APCC, Point mapper and other ASCOM products...

 

Hi Tom

i'm up so i'll take a crack here ;)


1. What is the purpose of the AP V2 connect button in APCC? Why does APCC need to connect to the driver? Applications seem to work fine even if this is not connected.

You definitely want the AP ASCOM driver to connect through APCC, that's how the modeling is transparent to your connecting applications. I always start up APCC first and auto connect ASCOM driver to it.
  
2. Once I have my mapping done, do I need to use the APPM software to do an initial sync and recal before using Voyager?

No - it already did a sync and recal as part of the modeling. If you are doing plate solve/centering in Voyager i assume it will work like other imaging apps and use Sync for centering routines anyways
 
3. Must all recals be turned off in other software when you are using a model?

No - plate solve uses sync which is required when centering a target. See 1. above re: connect the ascom driver through APCC and the model is transparent to applications
 
4. Tonight I did a 100 point model. When the scope went into the west, clouds rolled in and I only got part of the points there.  Do I need to redo the whole model?  Or can just the missing points be done or added?

afaik you can't add to an existing model, you can only re-do it, so i think you need to re-do the model

 
I guess that covers the questions for now.

Thanks, Tom



--
Brian 



Brian Valente


Re: Having lots of issues with APCC, Point mapper and other ASCOM products...

Tom Blahovici
 

HI
Ok.  Actually what was happening is that none of the virtual ports were being created.  Now that they are, it seems to be fine.  However, I have some questions.

1. What is the purpose of the AP V2 connect button in APCC? Why does APCC need to connect to the driver? Applications seem to work fine even if this is not connected.
2. Once I have my mapping done, do I need to use the APPM software to do an initial sync and recal before using Voyager?
3. Must all recals be turned off in other software when you are using a model?
4. Tonight I did a 100 point model. When the scope went into the west, clouds rolled in and I only got part of the points there.  Do I need to redo the whole model?  Or can just the missing points be done or added?
I guess that covers the questions for now.

Thanks, Tom


Re: Having lots of issues with APCC, Point mapper and other ASCOM products...

Bill Long
 

You can turn off run as admin for Voyager and see if everything functions fine. If it does, no harm done.

If you contact them for support in the future they will ask you to turn run as admin back on. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Tom Blahovici <tom.va2fsq@...>
Sent: Monday, September 20, 2021 7:53 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [ap-gto] Having lots of issues with APCC, Point mapper and other ASCOM products...
 

Hi,
I am not even sure I know where to start here but something is not right. First I need to point out that I have had a perfectly working setup in the past with my AP600 and Voyager and PhD Guider.  All this has changed now that I have APCC Pro.

Tonight is an example.  I startup APCC and connect to the mount with an IP Address.  This works fine. I then started the Point mapper and had to click on the Connect in APCC for the ASCOM driver.  I then had to select the virtual port in the settings for the ASCOM connection in the point mapper.  This connects and works fine.

When the point mapping is complete I close the program and attempt to startup Voyager which in turn starts PhD Guider.  However, Voyager locks up trying to connect to the AP driver.  Same with PhD Guider.  At this point I have to kill the processes and then reboot the computer.  Note that both, are trying to use the virtual port in the AP driver.

If I start from scratch and tell Voyager that I am using the AP Ascom driver the only thing that works is if I select the IP address and NOT the virtual port.  Same thing for PhD guider.  So I now have three applications going direct to the IP address. This is not right, correct?

So my questions besides the fact that the I cannot use the virtual ports with anything other than the point mapper program are the following:
If all devices are going directly to the IP address then are they using the model I created? Or not?

What's the point of the virtual ports if everything connects directly to the IP address?

Does each application need to use their own virtual port?

Why is everything locking up?
Perhaps if all this is explained with how it actually functions I can make some sense out of this.

Thanks for your help.
BTW, All software is the latest, downloaded two days ago.

Tom





Re: Rain Event Impact on Mount CP

Roland Christen
 

If you can't fix that, please contact George at AP and have him issue a return for the CP4 so we can check it out fully.

Roland


-----Original Message-----
From: Chris White <chris.white@...>
To: main@ap-gto.groups.io
Sent: Mon, Sep 20, 2021 9:37 pm
Subject: [ap-gto] Rain Event Impact on Mount CP

The rain event that I documented over on the AP-UG appears to have also impacted my mount. 

When I attempted to slew the other night I got a motor stall error on DEC, followed by DEC axis starting a slow slew to the south in an uncontrollable movement.  Uncontrollable meaning the mount was unresponsive to the stop command in the ASCOM driver and only by nudging the mount north or south would it arrest. I could repeat the error as every time I tried to move the mount north or south it would produce the motor stall error.  I also once saw a low power error.   RA seemed to slew normally.  So I switched the Y cable from RA to DEC and DEC to RA and DEC began working fine while RA had a motor stall.  I concluded that somehow the Y cable was damaged either by the rain or by me when I disconnected my CP4 to bring it in to dry out. 

I'm hoping that this test is definitive.  I ordered a replacement Y cable (funny enough another counterweight accidentally fell into my shopping cart) and hoping that this resolves my problem.  Anything else I should be concerned about or consider?

--
Roland Christen
Astro-Physics


Re: Having lots of issues with APCC, Point mapper and other ASCOM products...

Ray Gralak
 

Hi Tom,

This is not a problem with ASCOM or APCC. The problem is that Voyager needs to be run "as administrator", which complicates things because all other of the applications also need to be run "as administrator", which is not the default way applications usually are run.

An application that is running "as administrator" that connects to the AP V2 ASCOM driver opens a *different* instance of the AP V2 driver than if another application connects that is running normally. So, in a setting with mixed normal/administrator applications you can have two instances of the AP V2 ASCOM driver running, and they cannot both share the same virtual COM port. So in that sense, they must use two different virtual COM ports,

This issue has been discussed many, many times, so you might want to do a web search to read more about it if you are interested. But the short answer is that you may need to run all of your astronomy applications "as administrator" if you want to use Voyager.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Tom Blahovici
Sent: Monday, September 20, 2021 7:53 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Having lots of issues with APCC, Point mapper and other ASCOM products...

Hi,
I am not even sure I know where to start here but something is not right. First I need to point out that I have
had a perfectly working setup in the past with my AP600 and Voyager and PhD Guider. All this has changed
now that I have APCC Pro.

Tonight is an example. I startup APCC and connect to the mount with an IP Address. This works fine. I then
started the Point mapper and had to click on the Connect in APCC for the ASCOM driver. I then had to select
the virtual port in the settings for the ASCOM connection in the point mapper. This connects and works fine.

When the point mapping is complete I close the program and attempt to startup Voyager which in turn starts
PhD Guider. However, Voyager locks up trying to connect to the AP driver. Same with PhD Guider. At this
point I have to kill the processes and then reboot the computer. Note that both, are trying to use the virtual
port in the AP driver.

If I start from scratch and tell Voyager that I am using the AP Ascom driver the only thing that works is if I
select the IP address and NOT the virtual port. Same thing for PhD guider. So I now have three applications
going direct to the IP address. This is not right, correct?

So my questions besides the fact that the I cannot use the virtual ports with anything other than the point
mapper program are the following:
If all devices are going directly to the IP address then are they using the model I created? Or not?

What's the point of the virtual ports if everything connects directly to the IP address?

Does each application need to use their own virtual port?

Why is everything locking up?
Perhaps if all this is explained with how it actually functions I can make some sense out of this.

Thanks for your help.
BTW, All software is the latest, downloaded two days ago.

Tom







Having lots of issues with APCC, Point mapper and other ASCOM products...

Tom Blahovici
 

Hi,
I am not even sure I know where to start here but something is not right. First I need to point out that I have had a perfectly working setup in the past with my AP600 and Voyager and PhD Guider.  All this has changed now that I have APCC Pro.

Tonight is an example.  I startup APCC and connect to the mount with an IP Address.  This works fine. I then started the Point mapper and had to click on the Connect in APCC for the ASCOM driver.  I then had to select the virtual port in the settings for the ASCOM connection in the point mapper.  This connects and works fine.

When the point mapping is complete I close the program and attempt to startup Voyager which in turn starts PhD Guider.  However, Voyager locks up trying to connect to the AP driver.  Same with PhD Guider.  At this point I have to kill the processes and then reboot the computer.  Note that both, are trying to use the virtual port in the AP driver.

If I start from scratch and tell Voyager that I am using the AP Ascom driver the only thing that works is if I select the IP address and NOT the virtual port.  Same thing for PhD guider.  So I now have three applications going direct to the IP address. This is not right, correct?

So my questions besides the fact that the I cannot use the virtual ports with anything other than the point mapper program are the following:
If all devices are going directly to the IP address then are they using the model I created? Or not?

What's the point of the virtual ports if everything connects directly to the IP address?

Does each application need to use their own virtual port?

Why is everything locking up?
Perhaps if all this is explained with how it actually functions I can make some sense out of this.

Thanks for your help.
BTW, All software is the latest, downloaded two days ago.

Tom





Rain Event Impact on Mount CP

Chris White
 

The rain event that I documented over on the AP-UG appears to have also impacted my mount. 

When I attempted to slew the other night I got a motor stall error on DEC, followed by DEC axis starting a slow slew to the south in an uncontrollable movement.  Uncontrollable meaning the mount was unresponsive to the stop command in the ASCOM driver and only by nudging the mount north or south would it arrest. I could repeat the error as every time I tried to move the mount north or south it would produce the motor stall error.  I also once saw a low power error.   RA seemed to slew normally.  So I switched the Y cable from RA to DEC and DEC to RA and DEC began working fine while RA had a motor stall.  I concluded that somehow the Y cable was damaged either by the rain or by me when I disconnected my CP4 to bring it in to dry out. 

I'm hoping that this test is definitive.  I ordered a replacement Y cable (funny enough another counterweight accidentally fell into my shopping cart) and hoping that this resolves my problem.  Anything else I should be concerned about or consider?


Re: Cloudy Nights post about the Mach 2 needs clarification

Karen Christen
 

Thank you for the clarification, mjb87.  That’s helpful.

Karen

AP

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of mjb87 via groups.io
Sent: Monday, September 20, 2021 4:02 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Cloudy Nights post about the Mach 2 needs clarification

 

I'm a moderator at Cloudy Nights (Observatories, Mounts, etc.). There has been no breach of security at Cloudy Nights. What we have observed, common to many astronomy sites, is concerted efforts by spammers to use passwords found elsewhere on the internet (as other sites have been hacked) to attempt to take over user accounts at Cloudy Nights, specifically in order to post bogus ads.  It has been successful a couple of times. This is a good time to exercise proper web hygiene -- don't reuse passwords and change them periodically.


--
Karen Christen
Astro-Physics


Re: Cloudy Nights post about the Mach 2 needs clarification

mjb87@...
 

I'm a moderator at Cloudy Nights (Observatories, Mounts, etc.). There has been no breach of security at Cloudy Nights. What we have observed, common to many astronomy sites, is concerted efforts by spammers to use passwords found elsewhere on the internet (as other sites have been hacked) to attempt to take over user accounts at Cloudy Nights, specifically in order to post bogus ads.  It has been successful a couple of times. This is a good time to exercise proper web hygiene -- don't reuse passwords and change them periodically.


Re: Mount Synchronization Memory Lapse

Jerome A Yesavage
 

Thanks Ray,
I think I came up with the same result using the chimpanzee solution. I normally park in #5, but on unparking it would not come back even after I move the scope to the right position.  I then dumbly tried 3, moved the scope, and then it would go correctly to the others.  So the #3 is sorta the calibration position?
I am going to print this note out and put it on my bulletin board in the observatory for future reference.
Thanks for the response,
JY


Re: Trouble with MaxDome II slaving to APPM

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


Re: Trouble with MaxDome II slaving to APPM

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


Re: Trouble with MaxDome II slaving to APPM

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




Re: Trouble with MaxDome II slaving to APPM

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


Re: APPM - error

Ray Gralak
 

Hi Ted,

I am glad that APPM and APCC Pro are working well for you!

Is this particular 95-point model only applicable for this equipment, image scale and imaging season?
In general, yes. However, if polar alignment changes enough because of ground settling, or if you change equipment balance significantly, then the model may not work as well.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Ted Mickle via groups.io
Sent: Sunday, September 19, 2021 2:52 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM - error

Ray,

I ran my first-ever APPM model three nights back, a 95 point model.

Since then, using APPM I’ve run hours of 900 second narrowband imaging unguided and marvel at the small
round stars, even in regions of the sky that were not included in the original model (created with a Tak 130,
1100 GTO and QHY 600M).

Is this particular 95-point model only applicable for this equipment, image scale and imaging season?

Thanks for APPM - it’s transformed my astroimaging.

Ted




On Sep 19, 2021, at 13:16, Ray Gralak <iogroups@siriusimaging.com> wrote:

HI Ron,

Now what does "verify" check box do?
It runs the same steps to collect sky data points but with the active model for the purpose of diagnosing
pointing or tracking problems.

and how often should I make a new model?
We might ask you to run this if you have a dramatic pointing or tracking problem with a model, which
doesn't appear to be the case. You are better off using this time for imaging!

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Ron Kramer
Sent: Sunday, September 19, 2021 10:38 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM - error

thanks for the assists Ray - and thanks for the nina compatible updates.
Now what does "verify" check box do?
and how often should I make a new model?
I did a 300, 600 and 1000 second exposure after the APPM model was applied and I had round stars with
no
guiding even at 1000.
And at a good HFR of 3.48 (average is often higher even when guiding).
My max before the model was about 60-90 seconds and I'd still see eggs.


On Sun, Sep 19, 2021 at 12:24 PM Ray Gralak <iogroups@siriusimaging.com> wrote:


Hi Ron,

> Results were well worth it. BEFORE the point model I would get oblong stars if I went over 60-90
second
> exposures. Last night I did 1000 second exposure and had round stars. It blew me away.

That's excellent! I'm glad you got everything working! :-)

Best regards,

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Ron Kramer
> Sent: Sunday, September 19, 2021 6:03 AM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APPM - error
>
> MAYBE that was the fix. I had great results last night. The pop up error never appeared. And one of
the
> solutions I tried was to update ASTAP. I was using the latest but I went back and noticed there is a
dev
> release that is newer and I had installed that.
>
> I made other changes to settings. I went full frame, and bin2 and I sed a APPM setting from default
to 0.
> Something or everything made it work... but could be it was using the dev release of ASTAP that
fixed it.
>
> Results were well worth it. BEFORE the point model I would get oblong stars if I went over 60-90
second
> exposures. Last night I did 1000 second exposure and had round stars. It blew me away.
>
>
>
>










--

Ron Kramer
https://www.facebook.com/Ron.R.Kramer







Re: Trouble with MaxDome II slaving to APPM

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


Re: Trouble with MaxDome II slaving to APPM

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


Re: Cloudy Nights post about the Mach 2 needs clarification

M Hambrick
 

There seems to have been some sort of cyber-security incident at Cloudy Nights. Since a couple days ago you must sign into your account just to be able to look at the classified listings. This morning, the classified menu tab is not even visible until you have signed in.

Mike

1981 - 2000 of 83140