APPM with Dome Questions


Shane Ramotowski
 

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do my first APPM model tonight.  I'm having problems with the dome control and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8 ft dome.  The pier is centered and the bottom of the mount is just about even with the bottom of the dome.  The rotation control is homemade (my COVID quarantine project) and works very will with both ASCOM DeviceHub and SGP.  I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems to do it's calculations based on the center of the dome instead of where the telescope is.  This is not surprising since I can't seem to find any where in the program or the documentation to set the mount and telescope geometry.  I suppose, since APCC knows that I'm using a Mach2, it _could_ already know roughly how far from the center of the RA/DEC axes intersection the bottom of my telescope is.  But I don't see anyway that it could know where the center of my OTA is.  I really don't think it's using the parameters from 3D view; I haven't set that up, but the default is a much larger diameter telescope than mine.

 Anyway, when I use "Active", I end up imaging across the edge of the slot because the slot is positioned for the center of the mount instead of where the telescope is.  Most of the images ended up plate solving anyway, but since  the stars are all diffraction spikes, I don't know the quality of those solutions.  The initial slew to meridian is probably the worst because the dome is in the exact opposite position than it should be and my slot just goes barely past vertical.   I checked the ASCOM logs on the PC and my ASCOM debug screen on the dome controller.  The dome _is_ slewing to the position that APPM requests; that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing?  Where do I enter the offsets for the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two different dome slaving programs: ASCOM Device Hub and SGP.  For "Delay before starting dome slew checking", I used values ranging from 5 to 30 seconds.  For "Settle time after dome stops slewing", I used values from 1 to 20 seconds.  I didn't see any effect when changing these settings; in all cases the the telescope slewed to the next position and started imaging a few seconds after it got there--many seconds before the dome was in position.  None of those images solved since the dome was in the way.  Again, I can't figure out what I'm doing wrong--it's like I'm not even changing the values.  Is there another setting that I'm missing that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an automated dome!  What am I missing?

Thanks - Shane

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


Ray Gralak
 

Hi Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this case, it is the responsibility of the driver or intermediate application to translate the RA/Dec coordinates to the appropriate dome position.

In "Passive mode" APPM waits for the dome to finish slewing by polling the dome's driver (or intermediate application).

So, it seems that your dome's ascom driver (or intermediate application) may not be correctly indicating when the dome is slewing.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do
my first APPM model tonight. I'm having problems with the dome control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8
ft dome. The pier is centered and the bottom of the mount is just about
even with the bottom of the dome. The rotation control is homemade (my
COVID quarantine project) and works very will with both ASCOM DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems
to do it's calculations based on the center of the dome instead of where
the telescope is. This is not surprising since I can't seem to find any
where in the program or the documentation to set the mount and telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the RA/DEC axes
intersection the bottom of my telescope is. But I don't see anyway that
it could know where the center of my OTA is. I really don't think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the edge of the
slot because the slot is positioned for the center of the mount instead
of where the telescope is. Most of the images ended up plate solving
anyway, but since the stars are all diffraction spikes, I don't know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on the dome
controller. The dome _is_ slewing to the position that APPM requests;
that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing? Where do I enter the offsets for
the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two
different dome slaving programs: ASCOM Device Hub and SGP. For "Delay
before starting dome slew checking", I used values ranging from 5 to 30
seconds. For "Settle time after dome stops slewing", I used values from
1 to 20 seconds. I didn't see any effect when changing these settings;
in all cases the the telescope slewed to the next position and started
imaging a few seconds after it got there--many seconds before the dome
was in position. None of those images solved since the dome was in the
way. Again, I can't figure out what I'm doing wrong--it's like I'm not
even changing the values. Is there another setting that I'm missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

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




Terry White
 

Ditto to what Ray said. You should enter all the dome and OTA parameters in the program that directly slews your dome to the OTA, not APPM.


Shane Ramotowski
 

Ray, thanks for the reply, but I don't really see anything that will help.


APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work?  What part of the ASCOM dome API would that be? <https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

I am definitely returning false fort the CanSlave and Slaved properties, since there is no hardware-based slaving capability in the dome controller.  And I don't see way to "send the telescope's destination coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is "SlewToAzimuth()" but I think you are basing that azimuth on the center of the dome rather than the position of the telescope, which can be significantly different--consider the initial slew to zenith in which the RA axis rotates west and level and the DEC axis point strait up.  The telescope is several inches West of the center of the mount.  From what I understand, if you are going to use SlewToAzimuth(), you need to consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who answer most of the dome-related questions posted to the ASCOM Driver and Application Development Support Forum, it has a whole section for dome and mount geometry in it's setup section to allow slaving.

In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected.  What should I set the two passive values to to ensure that the imaging doesn't start for, say, 1 minute after the scope stops slewing?  Or am I not understanding the meaning of those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night.  Under Settings->Dome Settings, Passive is selected, "Delay before starting dome slew checking" is set to 30 seconds and "Settle time after dome stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965:       Info,   State Machine, Entering State=SlewNext
0467222 2021-02-26 20:46:22.103:       Info,        SlewNext, Starting Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10° 00' 00.0")
0467223 2021-02-26 20:46:22.105:       Info,       Slew Next, East=True, Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105:       Info,        Meridian, Setting Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144:       Info,       SlewAsync, Begin UnSAFE Slew to RA/Dec:   8.501824 / -10.000000 ( 08h 30m 06.56s / -10° 00' 00.0")
0467226 2021-02-26 20:46:22.215:       Info,   State Machine, Entering State=PreSlewing
0467227 2021-02-26 20:46:25.482:       Info,   State Machine, Entering State=Slewing
0467228 2021-02-26 20:46:30.722:       Info,   State Machine, Entering State=StartSettle
0467229 2021-02-26 20:46:30.741:       Info,     StartSettle, Starting Settle wait time
0467230 2021-02-26 20:46:30.970:       Info,   State Machine, Entering State=WaitSettle
0467231 2021-02-26 20:46:32.974:       Info,      WaitSettle, Settling Time Complete
0467232 2021-02-26 20:46:33.022:       Info,      WaitSettle, Finished Slew to Point 3
0467233 2021-02-26 20:46:33.022:       Info,      WaitSettle, RA/Dec:   8.501833 / -10.000000 ( 08h 30m 06.60s /  -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022:       Info,      WaitSettle, HA/Dec:  -1.329942 / -10.000000 (-01h 19m 47.79s /  -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226:       Info,   State Machine, Entering State=StartImage
0467236 2021-02-26 20:46:33.260:       Info,   State Machine, Starting Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260:       Info,   State Machine, LST mid image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260:       Info,  StartTakeImage, Sequence Generator Pro: Binning=1, Subframe Type: 0, Duration=5, IsDarkFrame=False

The total time between the start of the point's processing and start of it's imaging is about 12 seconds.  Shouldn't that be at least 40 seconds to allow the dome delay and settle times to happen?  What am I misunderstanding?

The dome controller and ASCOM driver do handle Slewing property correctly, returning TRUE from the time that the slewToAzimuth() is issued until the dome is stopped at the requested position, then returning FALSE until the next slew is issued  Sometimes, DeviceHub or SGP will end up issuing more than one slew to get the dome to the final position.  The slaving software notices that the telescope has moved and starts an azimuth slew to where is while the telescope is still moving.  Once the dome arrives at that position, another azimuth slew to get to where the telescope finally stopped.  Last night, the longest time that such multiple slews took was about 20 seconds.  That is why I set the "Delay before starting dome slew checking" to 30 seconds.  I though that would make APPM not even check for a dome slew until the dome was in place and had stopped moving.  Instead, it seemed to have made no difference: the imaging started almost as soon as the telescope arrived at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this case, it is the responsibility of the driver or intermediate application to translate the RA/Dec coordinates to the appropriate dome position.

In "Passive mode" APPM waits for the dome to finish slewing by polling the dome's driver (or intermediate application).

So, it seems that your dome's ascom driver (or intermediate application) may not be correctly indicating when the dome is slewing.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do
my first APPM model tonight. I'm having problems with the dome control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8
ft dome. The pier is centered and the bottom of the mount is just about
even with the bottom of the dome. The rotation control is homemade (my
COVID quarantine project) and works very will with both ASCOM DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems
to do it's calculations based on the center of the dome instead of where
the telescope is. This is not surprising since I can't seem to find any
where in the program or the documentation to set the mount and telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the RA/DEC axes
intersection the bottom of my telescope is. But I don't see anyway that
it could know where the center of my OTA is. I really don't think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the edge of the
slot because the slot is positioned for the center of the mount instead
of where the telescope is. Most of the images ended up plate solving
anyway, but since the stars are all diffraction spikes, I don't know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on the dome
controller. The dome _is_ slewing to the position that APPM requests;
that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing? Where do I enter the offsets for
the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two
different dome slaving programs: ASCOM Device Hub and SGP. For "Delay
before starting dome slew checking", I used values ranging from 5 to 30
seconds. For "Settle time after dome stops slewing", I used values from
1 to 20 seconds. I didn't see any effect when changing these settings;
in all cases the the telescope slewed to the next position and started
imaging a few seconds after it got there--many seconds before the dome
was in position. None of those images solved since the dome was in the
way. Again, I can't figure out what I'm doing wrong--it's like I'm not
even changing the values. Is there another setting that I'm missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

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








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


Shane Ramotowski
 

Thanks Terry.  In the "Active" case it _is_ APPM that slews the dome to the OTA.  That is the crux of my question!

- Shane

On 2/27/2021 11:28 AM, Terry White wrote:
Ditto to what Ray said. You should enter all the dome and OTA parameters in the program that directly slews your dome to the OTA, not APPM.
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Ray Gralak
 

Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
Again, APPM does not do dome calculations (nor is there a plan for it to do that). IMO, the ASCOM Dome API is missing a way to send scope Ra/Dec/pierside to the Dome driver. ASCOM makes such a big deal about abstracting away telescope applications from the hardware, but the incomplete Dome API pretty much forces the use of a third-party application.

I think each dome manufacturer should each create their own drivers that should take into account the telescope and mount dimensions. It would have made life much easier for each application developer that has had to implement dome coordinate transformations in their applications.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be slaved to the telescope. In this case APPM just polls the slewing state until dome slewing stops. If slaving can't be done, there is an option in APPM to pause after each point, which would allow you to position the dome opening.

The total time between the start of the point's processing and start of
it's imaging is about 12 seconds. Shouldn't that be at least 40 seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what happened. Are you sure that you had APPM connected to your Dome application?

BTW, the problem might be that you are using the ASCOM Device Hub instead of the older POTH dome handling. The behavior is dome behavior is different in Device Hub, and it sounds like the author left out some old functionality.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

Ray, thanks for the reply, but I don't really see anything that will help.


APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

I am definitely returning false fort the CanSlave and Slaved properties,
since there is no hardware-based slaving capability in the dome
controller. And I don't see way to "send the telescope's destination
coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is "SlewToAzimuth()"
but I think you are basing that azimuth on the center of the dome rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the RA axis
rotates west and level and the DEC axis point strait up. The telescope
is several inches West of the center of the mount. From what I
understand, if you are going to use SlewToAzimuth(), you need to
consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who answer
most of the dome-related questions posted to the ASCOM Driver and
Application Development Support Forum, it has a whole section for dome
and mount geometry in it's setup section to allow slaving.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the meaning of
those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before starting
dome slew checking" is set to 30 seconds and "Settle time after dome
stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965: Info, State Machine, Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103: Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10° 00'
00.0")
0467223 2021-02-26 20:46:22.105: Info, Slew Next, East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105: Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec: 8.501824 / -10.000000 ( 08h 30m 06.56s / -10°
00' 00.0")
0467226 2021-02-26 20:46:22.215: Info, State Machine, Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482: Info, State Machine, Entering
State=Slewing
0467228 2021-02-26 20:46:30.722: Info, State Machine, Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741: Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970: Info, State Machine, Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974: Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022: Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022: Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s / -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022: Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s / -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226: Info, State Machine, Entering
State=StartImage
0467236 2021-02-26 20:46:33.260: Info, State Machine, Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260: Info, State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260: Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5, IsDarkFrame=False

The total time between the start of the point's processing and start of
it's imaging is about 12 seconds. Shouldn't that be at least 40 seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?

The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the slewToAzimuth() is
issued until the dome is stopped at the requested position, then
returning FALSE until the next slew is issued Sometimes, DeviceHub or
SGP will end up issuing more than one slew to get the dome to the final
position. The slaving software notices that the telescope has moved and
starts an azimuth slew to where is while the telescope is still moving.
Once the dome arrives at that position, another azimuth slew to get to
where the telescope finally stopped. Last night, the longest time that
such multiple slews took was about 20 seconds. That is why I set the
"Delay before starting dome slew checking" to 30 seconds. I though that
would make APPM not even check for a dome slew until the dome was in
place and had stopped moving. Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope arrived
at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate application to translate the RA/Dec coordinates to the
appropriate dome position.

In "Passive mode" APPM waits for the dome to finish slewing by polling the dome's driver (or intermediate
application).

So, it seems that your dome's ascom driver (or intermediate application) may not be correctly indicating when
the dome is slewing.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do
my first APPM model tonight. I'm having problems with the dome control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8
ft dome. The pier is centered and the bottom of the mount is just about
even with the bottom of the dome. The rotation control is homemade (my
COVID quarantine project) and works very will with both ASCOM DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems
to do it's calculations based on the center of the dome instead of where
the telescope is. This is not surprising since I can't seem to find any
where in the program or the documentation to set the mount and telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the RA/DEC axes
intersection the bottom of my telescope is. But I don't see anyway that
it could know where the center of my OTA is. I really don't think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the edge of the
slot because the slot is positioned for the center of the mount instead
of where the telescope is. Most of the images ended up plate solving
anyway, but since the stars are all diffraction spikes, I don't know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on the dome
controller. The dome _is_ slewing to the position that APPM requests;
that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing? Where do I enter the offsets for
the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two
different dome slaving programs: ASCOM Device Hub and SGP. For "Delay
before starting dome slew checking", I used values ranging from 5 to 30
seconds. For "Settle time after dome stops slewing", I used values from
1 to 20 seconds. I didn't see any effect when changing these settings;
in all cases the the telescope slewed to the next position and started
imaging a few seconds after it got there--many seconds before the dome
was in position. None of those images solved since the dome was in the
way. Again, I can't figure out what I'm doing wrong--it's like I'm not
even changing the values. Is there another setting that I'm missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

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









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




Shane Ramotowski
 

OK.  I'll wait for the ASCOM folks to add the APIs that you want before I try to use "Active" mode again.

For the second part of my reply, I guess I did not make it clear enough that I was using DeviceHub not allowing APPM to connect to the dome, since APPM cannot send the dome to the correct position an DeviceHub can. _I am simply trying to understand what I'm doing wrong when setting up "Passive" parameters in the "Dome Settings" box.__
_
So can you please tell me what settings I can use for "Delay before staring dome slew check" and "Settle time after dome stops slewing" to ensure that I end up with at least 30 seconds between the end of the telescope slew and the start of imaging?  Assume that I did not change the default telescope slew of 900X.  The log entry I posted is from a session that used DeviceHub with "Delay before starting dome slew check" set to 30 seconds and "Settle time after dome stops slewing" set to 10 seconds.  You can see that the time between the start of the telescope slew and the the start of imaging is about 12 seconds.  So, clearly, I am not understanding how these two parameters work.

Thank you - Shane

On 2/27/2021 2:16 PM, Ray Gralak wrote:
Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
Again, APPM does not do dome calculations (nor is there a plan for it to do that). IMO, the ASCOM Dome API is missing a way to send scope Ra/Dec/pierside to the Dome driver. ASCOM makes such a big deal about abstracting away telescope applications from the hardware, but the incomplete Dome API pretty much forces the use of a third-party application.

I think each dome manufacturer should each create their own drivers that should take into account the telescope and mount dimensions. It would have made life much easier for each application developer that has had to implement dome coordinate transformations in their applications.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be slaved to the telescope. In this case APPM just polls the slewing state until dome slewing stops. If slaving can't be done, there is an option in APPM to pause after each point, which would allow you to position the dome opening.

The total time between the start of the point's processing and start of
it's imaging is about 12 seconds. Shouldn't that be at least 40 seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what happened. Are you sure that you had APPM connected to your Dome application?

BTW, the problem might be that you are using the ASCOM Device Hub instead of the older POTH dome handling. The behavior is dome behavior is different in Device Hub, and it sounds like the author left out some old functionality.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

Ray, thanks for the reply, but I don't really see anything that will help.


APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

I am definitely returning false fort the CanSlave and Slaved properties,
since there is no hardware-based slaving capability in the dome
controller. And I don't see way to "send the telescope's destination
coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is "SlewToAzimuth()"
but I think you are basing that azimuth on the center of the dome rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the RA axis
rotates west and level and the DEC axis point strait up. The telescope
is several inches West of the center of the mount. From what I
understand, if you are going to use SlewToAzimuth(), you need to
consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who answer
most of the dome-related questions posted to the ASCOM Driver and
Application Development Support Forum, it has a whole section for dome
and mount geometry in it's setup section to allow slaving.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the meaning of
those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before starting
dome slew checking" is set to 30 seconds and "Settle time after dome
stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965: Info, State Machine, Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103: Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10° 00'
00.0")
0467223 2021-02-26 20:46:22.105: Info, Slew Next, East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105: Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec: 8.501824 / -10.000000 ( 08h 30m 06.56s / -10°
00' 00.0")
0467226 2021-02-26 20:46:22.215: Info, State Machine, Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482: Info, State Machine, Entering
State=Slewing
0467228 2021-02-26 20:46:30.722: Info, State Machine, Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741: Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970: Info, State Machine, Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974: Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022: Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022: Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s / -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022: Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s / -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226: Info, State Machine, Entering
State=StartImage
0467236 2021-02-26 20:46:33.260: Info, State Machine, Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260: Info, State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260: Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5, IsDarkFrame=False

The total time between the start of the point's processing and start of
it's imaging is about 12 seconds. Shouldn't that be at least 40 seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?

The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the slewToAzimuth() is
issued until the dome is stopped at the requested position, then
returning FALSE until the next slew is issued Sometimes, DeviceHub or
SGP will end up issuing more than one slew to get the dome to the final
position. The slaving software notices that the telescope has moved and
starts an azimuth slew to where is while the telescope is still moving.
Once the dome arrives at that position, another azimuth slew to get to
where the telescope finally stopped. Last night, the longest time that
such multiple slews took was about 20 seconds. That is why I set the
"Delay before starting dome slew checking" to 30 seconds. I though that
would make APPM not even check for a dome slew until the dome was in
place and had stopped moving. Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope arrived
at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate application to translate the RA/Dec coordinates to the
appropriate dome position.
In "Passive mode" APPM waits for the dome to finish slewing by polling the dome's driver (or intermediate
application).
So, it seems that your dome's ascom driver (or intermediate application) may not be correctly indicating when
the dome is slewing.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do
my first APPM model tonight. I'm having problems with the dome control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8
ft dome. The pier is centered and the bottom of the mount is just about
even with the bottom of the dome. The rotation control is homemade (my
COVID quarantine project) and works very will with both ASCOM DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems
to do it's calculations based on the center of the dome instead of where
the telescope is. This is not surprising since I can't seem to find any
where in the program or the documentation to set the mount and telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the RA/DEC axes
intersection the bottom of my telescope is. But I don't see anyway that
it could know where the center of my OTA is. I really don't think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the edge of the
slot because the slot is positioned for the center of the mount instead
of where the telescope is. Most of the images ended up plate solving
anyway, but since the stars are all diffraction spikes, I don't know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on the dome
controller. The dome _is_ slewing to the position that APPM requests;
that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing? Where do I enter the offsets for
the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two
different dome slaving programs: ASCOM Device Hub and SGP. For "Delay
before starting dome slew checking", I used values ranging from 5 to 30
seconds. For "Settle time after dome stops slewing", I used values from
1 to 20 seconds. I didn't see any effect when changing these settings;
in all cases the the telescope slewed to the next position and started
imaging a few seconds after it got there--many seconds before the dome
was in position. None of those images solved since the dome was in the
way. Again, I can't figure out what I'm doing wrong--it's like I'm not
even changing the values. Is there another setting that I'm missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

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








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








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


Ray Gralak
 

Shane,

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.
I think you misunderstood. ASCOM is not planning to add those APIs.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when setting
up "Passive" parameters in the "Dome Settings" box.__
In passive mode, APPM only needs to poll the Dome's slewing state to work. If you can't do that then APPM won't be able to tell when the dome is done slewing.

If Device Hub won't let APPM connect to the Dome driver you can use the older ASCOM POTH application, which allows multiple applications to connect to an ASCOM driver.

So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging?
First, the two parameters only have meaning when you are connected to a Dome driver. If you are not connected they won't be used.

"Delay before starting dome slew checking"

The number of seconds before APPM will start checking the dome driver's slew state. This delay allows the dome driver time to initiate dome movement that will be reflected by reading "True" from the Dome driver's "Slewing" property. If the value is False when read, then dome slewing will be considered completed.

"Settle time after dome stops slewing"

The number of seconds to delay slew completion after the Dome driver's "Slewing" property reads "False".

-Ray





-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 2:16 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when setting
up "Passive" parameters in the "Dome Settings" box.__
_
So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging? Assume that I did not change
the default telescope slew of 900X. The log entry I posted is from a
session that used DeviceHub with "Delay before starting dome slew check"
set to 30 seconds and "Settle time after dome stops slewing" set to 10
seconds. You can see that the time between the start of the telescope
slew and the the start of imaging is about 12 seconds. So, clearly, I
am not understanding how these two parameters work.

Thank you - Shane


On 2/27/2021 2:16 PM, Ray Gralak wrote:
Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
Again, APPM does not do dome calculations (nor is there a plan for it to do that). IMO, the ASCOM Dome API
is missing a way to send scope Ra/Dec/pierside to the Dome driver. ASCOM makes such a big deal about
abstracting away telescope applications from the hardware, but the incomplete Dome API pretty much forces
the use of a third-party application.

I think each dome manufacturer should each create their own drivers that should take into account the
telescope and mount dimensions. It would have made life much easier for each application developer that has
had to implement dome coordinate transformations in their applications.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be slaved to the telescope. In this case APPM just
polls the slewing state until dome slewing stops. If slaving can't be done, there is an option in APPM to pause
after each point, which would allow you to position the dome opening.

The total time between the start of the point's processing and start of
it's imaging is about 12 seconds. Shouldn't that be at least 40 seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what happened. Are you sure that you had
APPM connected to your Dome application?

BTW, the problem might be that you are using the ASCOM Device Hub instead of the older POTH dome
handling. The behavior is dome behavior is different in Device Hub, and it sounds like the author left out some
old functionality.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

Ray, thanks for the reply, but I don't really see anything that will help.


APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

I am definitely returning false fort the CanSlave and Slaved properties,
since there is no hardware-based slaving capability in the dome
controller. And I don't see way to "send the telescope's destination
coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is "SlewToAzimuth()"
but I think you are basing that azimuth on the center of the dome rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the RA axis
rotates west and level and the DEC axis point strait up. The telescope
is several inches West of the center of the mount. From what I
understand, if you are going to use SlewToAzimuth(), you need to
consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who answer
most of the dome-related questions posted to the ASCOM Driver and
Application Development Support Forum, it has a whole section for dome
and mount geometry in it's setup section to allow slaving.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the meaning of
those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before starting
dome slew checking" is set to 30 seconds and "Settle time after dome
stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965: Info, State Machine, Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103: Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10° 00'
00.0")
0467223 2021-02-26 20:46:22.105: Info, Slew Next, East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105: Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec: 8.501824 / -10.000000 ( 08h 30m 06.56s / -10°
00' 00.0")
0467226 2021-02-26 20:46:22.215: Info, State Machine, Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482: Info, State Machine, Entering
State=Slewing
0467228 2021-02-26 20:46:30.722: Info, State Machine, Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741: Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970: Info, State Machine, Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974: Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022: Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022: Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s / -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022: Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s / -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226: Info, State Machine, Entering
State=StartImage
0467236 2021-02-26 20:46:33.260: Info, State Machine, Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260: Info, State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260: Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5, IsDarkFrame=False

The total time between the start of the point's processing and start of
it's imaging is about 12 seconds. Shouldn't that be at least 40 seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?

The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the slewToAzimuth() is
issued until the dome is stopped at the requested position, then
returning FALSE until the next slew is issued Sometimes, DeviceHub or
SGP will end up issuing more than one slew to get the dome to the final
position. The slaving software notices that the telescope has moved and
starts an azimuth slew to where is while the telescope is still moving.
Once the dome arrives at that position, another azimuth slew to get to
where the telescope finally stopped. Last night, the longest time that
such multiple slews took was about 20 seconds. That is why I set the
"Delay before starting dome slew checking" to 30 seconds. I though that
would make APPM not even check for a dome slew until the dome was in
place and had stopped moving. Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope arrived
at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate application to translate the RA/Dec coordinates to
the
appropriate dome position.
In "Passive mode" APPM waits for the dome to finish slewing by polling the dome's driver (or intermediate
application).
So, it seems that your dome's ascom driver (or intermediate application) may not be correctly indicating
when
the dome is slewing.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do
my first APPM model tonight. I'm having problems with the dome control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8
ft dome. The pier is centered and the bottom of the mount is just about
even with the bottom of the dome. The rotation control is homemade (my
COVID quarantine project) and works very will with both ASCOM DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems
to do it's calculations based on the center of the dome instead of where
the telescope is. This is not surprising since I can't seem to find any
where in the program or the documentation to set the mount and telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the RA/DEC axes
intersection the bottom of my telescope is. But I don't see anyway that
it could know where the center of my OTA is. I really don't think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the edge of the
slot because the slot is positioned for the center of the mount instead
of where the telescope is. Most of the images ended up plate solving
anyway, but since the stars are all diffraction spikes, I don't know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on the dome
controller. The dome _is_ slewing to the position that APPM requests;
that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing? Where do I enter the offsets for
the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two
different dome slaving programs: ASCOM Device Hub and SGP. For "Delay
before starting dome slew checking", I used values ranging from 5 to 30
seconds. For "Settle time after dome stops slewing", I used values from
1 to 20 seconds. I didn't see any effect when changing these settings;
in all cases the the telescope slewed to the next position and started
imaging a few seconds after it got there--many seconds before the dome
was in position. None of those images solved since the dome was in the
way. Again, I can't figure out what I'm doing wrong--it's like I'm not
even changing the values. Is there another setting that I'm missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

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








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









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




Shane Ramotowski
 

Ahh,  I think it understand.  I use DeviceHub to do the slaving, but still connect to the DeviceHub dome with APPM.   I will try that and see what happens.

Thanks - Shane

On 2/27/2021 5:27 PM, Ray Gralak wrote:
Shane,

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.
I think you misunderstood. ASCOM is not planning to add those APIs.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when setting
up "Passive" parameters in the "Dome Settings" box.__
In passive mode, APPM only needs to poll the Dome's slewing state to work. If you can't do that then APPM won't be able to tell when the dome is done slewing.

If Device Hub won't let APPM connect to the Dome driver you can use the older ASCOM POTH application, which allows multiple applications to connect to an ASCOM driver.

So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging?
First, the two parameters only have meaning when you are connected to a Dome driver. If you are not connected they won't be used.

"Delay before starting dome slew checking"

The number of seconds before APPM will start checking the dome driver's slew state. This delay allows the dome driver time to initiate dome movement that will be reflected by reading "True" from the Dome driver's "Slewing" property. If the value is False when read, then dome slewing will be considered completed.

"Settle time after dome stops slewing"

The number of seconds to delay slew completion after the Dome driver's "Slewing" property reads "False".

-Ray





-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 2:16 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when setting
up "Passive" parameters in the "Dome Settings" box.__
_
So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging? Assume that I did not change
the default telescope slew of 900X. The log entry I posted is from a
session that used DeviceHub with "Delay before starting dome slew check"
set to 30 seconds and "Settle time after dome stops slewing" set to 10
seconds. You can see that the time between the start of the telescope
slew and the the start of imaging is about 12 seconds. So, clearly, I
am not understanding how these two parameters work.

Thank you - Shane


On 2/27/2021 2:16 PM, Ray Gralak wrote:
Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
Again, APPM does not do dome calculations (nor is there a plan for it to do that). IMO, the ASCOM Dome API
is missing a way to send scope Ra/Dec/pierside to the Dome driver. ASCOM makes such a big deal about
abstracting away telescope applications from the hardware, but the incomplete Dome API pretty much forces
the use of a third-party application.
I think each dome manufacturer should each create their own drivers that should take into account the
telescope and mount dimensions. It would have made life much easier for each application developer that has
had to implement dome coordinate transformations in their applications.
> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be slaved to the telescope. In this case APPM just
polls the slewing state until dome slewing stops. If slaving can't be done, there is an option in APPM to pause
after each point, which would allow you to position the dome opening.
The total time between the start of the point's processing and start of
it's imaging is about 12 seconds. Shouldn't that be at least 40 seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what happened. Are you sure that you had
APPM connected to your Dome application?
BTW, the problem might be that you are using the ASCOM Device Hub instead of the older POTH dome
handling. The behavior is dome behavior is different in Device Hub, and it sounds like the author left out some
old functionality.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

Ray, thanks for the reply, but I don't really see anything that will help.


APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

I am definitely returning false fort the CanSlave and Slaved properties,
since there is no hardware-based slaving capability in the dome
controller. And I don't see way to "send the telescope's destination
coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is "SlewToAzimuth()"
but I think you are basing that azimuth on the center of the dome rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the RA axis
rotates west and level and the DEC axis point strait up. The telescope
is several inches West of the center of the mount. From what I
understand, if you are going to use SlewToAzimuth(), you need to
consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who answer
most of the dome-related questions posted to the ASCOM Driver and
Application Development Support Forum, it has a whole section for dome
and mount geometry in it's setup section to allow slaving.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the meaning of
those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before starting
dome slew checking" is set to 30 seconds and "Settle time after dome
stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965: Info, State Machine, Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103: Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10° 00'
00.0")
0467223 2021-02-26 20:46:22.105: Info, Slew Next, East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105: Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec: 8.501824 / -10.000000 ( 08h 30m 06.56s / -10°
00' 00.0")
0467226 2021-02-26 20:46:22.215: Info, State Machine, Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482: Info, State Machine, Entering
State=Slewing
0467228 2021-02-26 20:46:30.722: Info, State Machine, Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741: Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970: Info, State Machine, Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974: Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022: Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022: Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s / -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022: Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s / -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226: Info, State Machine, Entering
State=StartImage
0467236 2021-02-26 20:46:33.260: Info, State Machine, Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260: Info, State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260: Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5, IsDarkFrame=False

The total time between the start of the point's processing and start of
it's imaging is about 12 seconds. Shouldn't that be at least 40 seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?

The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the slewToAzimuth() is
issued until the dome is stopped at the requested position, then
returning FALSE until the next slew is issued Sometimes, DeviceHub or
SGP will end up issuing more than one slew to get the dome to the final
position. The slaving software notices that the telescope has moved and
starts an azimuth slew to where is while the telescope is still moving.
Once the dome arrives at that position, another azimuth slew to get to
where the telescope finally stopped. Last night, the longest time that
such multiple slews took was about 20 seconds. That is why I set the
"Delay before starting dome slew checking" to 30 seconds. I though that
would make APPM not even check for a dome slew until the dome was in
place and had stopped moving. Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope arrived
at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate application to translate the RA/Dec coordinates to
the
appropriate dome position.
In "Passive mode" APPM waits for the dome to finish slewing by polling the dome's driver (or intermediate
application).
So, it seems that your dome's ascom driver (or intermediate application) may not be correctly indicating
when
the dome is slewing.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do
my first APPM model tonight. I'm having problems with the dome control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8
ft dome. The pier is centered and the bottom of the mount is just about
even with the bottom of the dome. The rotation control is homemade (my
COVID quarantine project) and works very will with both ASCOM DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems
to do it's calculations based on the center of the dome instead of where
the telescope is. This is not surprising since I can't seem to find any
where in the program or the documentation to set the mount and telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the RA/DEC axes
intersection the bottom of my telescope is. But I don't see anyway that
it could know where the center of my OTA is. I really don't think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the edge of the
slot because the slot is positioned for the center of the mount instead
of where the telescope is. Most of the images ended up plate solving
anyway, but since the stars are all diffraction spikes, I don't know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on the dome
controller. The dome _is_ slewing to the position that APPM requests;
that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing? Where do I enter the offsets for
the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two
different dome slaving programs: ASCOM Device Hub and SGP. For "Delay
before starting dome slew checking", I used values ranging from 5 to 30
seconds. For "Settle time after dome stops slewing", I used values from
1 to 20 seconds. I didn't see any effect when changing these settings;
in all cases the the telescope slewed to the next position and started
imaging a few seconds after it got there--many seconds before the dome
was in position. None of those images solved since the dome was in the
way. Again, I can't figure out what I'm doing wrong--it's like I'm not
even changing the values. Is there another setting that I'm missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

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







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








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








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


Shane Ramotowski
 

One more question, Ray:  In APPM, is there a way to connect to the DeviceHub telescope or is it locked to the AP ASCOM driver?

Thanks - Shane

On 2/27/2021 8:09 PM, Shane Ramotowski wrote:
Ahh, I think it understand.  I use DeviceHub to do the slaving, but still connect to the DeviceHub dome with APPM.   I will try that and see what happens.

Thanks - Shane

On 2/27/2021 5:27 PM, Ray Gralak wrote:
Shane,

OK.  I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.
I think you misunderstood. ASCOM is not planning to add those APIs.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when setting
up "Passive" parameters in the "Dome Settings" box.__
In passive mode, APPM only needs to poll the Dome's slewing state to work. If you can't do that then APPM won't be able to tell when the dome is done slewing.

If Device Hub won't let APPM connect to the Dome driver you can use the older ASCOM POTH application, which allows multiple applications to connect to an ASCOM driver.

So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging?
First, the two parameters only have meaning when you are connected to a Dome driver. If you are not connected they won't be used.

"Delay before starting dome slew checking"

The number of seconds before APPM will start checking the dome driver's slew state. This delay allows the dome driver time to initiate dome movement that will be reflected by reading "True" from the Dome driver's "Slewing" property. If the value is False when read, then dome slewing will be considered completed.

"Settle time after dome stops slewing"

The number of seconds to delay slew completion after the Dome driver's "Slewing" property reads "False".

-Ray





-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 2:16 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

OK.  I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when setting
up "Passive" parameters in the "Dome Settings" box.__
_
So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging?  Assume that I did not change
the default telescope slew of 900X.  The log entry I posted is from a
session that used DeviceHub with "Delay before starting dome slew check"
set to 30 seconds and "Settle time after dome stops slewing" set to 10
seconds.  You can see that the time between the start of the telescope
slew and the the start of imaging is about 12 seconds.  So, clearly, I
am not understanding how these two parameters work.

Thank you - Shane


On 2/27/2021 2:16 PM, Ray Gralak wrote:
Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work?  What part of the ASCOM dome API would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
Again, APPM does not do dome calculations (nor is there a plan for it to do that). IMO, the ASCOM Dome API
is missing a way to send scope Ra/Dec/pierside to the Dome driver. ASCOM makes such a big deal about
abstracting away telescope applications from the hardware, but the incomplete Dome API pretty much forces
the use of a third-party application.
I think each dome manufacturer should each create their own drivers that should take into account the
telescope and mount dimensions. It would have made life much easier for each application developer that has
had to implement dome coordinate transformations in their applications.
   > In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected.  What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing?  Or am I not understanding the meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be slaved to the telescope. In this case APPM just
polls the slewing state until dome slewing stops. If slaving can't be done, there is an option in APPM to pause
after each point, which would allow you to position the dome opening.
The total time between the start of the point's processing and start of
it's imaging is about 12 seconds.  Shouldn't that be at least 40 seconds
to allow the dome delay and settle times to happen?  What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what happened. Are you sure that you had
APPM connected to your Dome application?
BTW, the problem might be that you are using the ASCOM Device Hub instead of the older POTH dome
handling. The behavior is dome behavior is different in Device Hub, and it sounds like the author left out some
old functionality.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

Ray, thanks for the reply, but I don't really see anything that will help.


APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work?  What part of the ASCOM dome API would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

I am definitely returning false fort the CanSlave and Slaved properties,
since there is no hardware-based slaving capability in the dome
controller.  And I don't see way to "send the telescope's destination
coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is "SlewToAzimuth()"
but I think you are basing that azimuth on the center of the dome rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the RA axis
rotates west and level and the DEC axis point strait up. The telescope
is several inches West of the center of the mount.  From what I
understand, if you are going to use SlewToAzimuth(), you need to
consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who answer
most of the dome-related questions posted to the ASCOM Driver and
Application Development Support Forum, it has a whole section for dome
and mount geometry in it's setup section to allow slaving.

   > In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected.  What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing?  Or am I not understanding the meaning of
those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before starting
dome slew checking" is set to 30 seconds and "Settle time after dome
stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965:       Info,   State Machine, Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103:       Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10° 00'
00.0")
0467223 2021-02-26 20:46:22.105:       Info,       Slew Next, East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105:       Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144:       Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec:   8.501824 / -10.000000 ( 08h 30m 06.56s / -10°
00' 00.0")
0467226 2021-02-26 20:46:22.215:       Info,   State Machine, Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482:       Info,   State Machine, Entering
State=Slewing
0467228 2021-02-26 20:46:30.722:       Info,   State Machine, Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741:       Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970:       Info,   State Machine, Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974:       Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022:       Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022:       Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s /  -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022:       Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s /  -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226:       Info,   State Machine, Entering
State=StartImage
0467236 2021-02-26 20:46:33.260:       Info,   State Machine, Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260:       Info,   State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260:       Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5, IsDarkFrame=False

The total time between the start of the point's processing and start of
it's imaging is about 12 seconds.  Shouldn't that be at least 40 seconds
to allow the dome delay and settle times to happen?  What am I
misunderstanding?

The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the slewToAzimuth() is
issued until the dome is stopped at the requested position, then
returning FALSE until the next slew is issued  Sometimes, DeviceHub or
SGP will end up issuing more than one slew to get the dome to the final
position.  The slaving software notices that the telescope has moved and
starts an azimuth slew to where is while the telescope is still moving.
Once the dome arrives at that position, another azimuth slew to get to
where the telescope finally stopped.  Last night, the longest time that
such multiple slews took was about 20 seconds.  That is why I set the
"Delay before starting dome slew checking" to 30 seconds. I though that
would make APPM not even check for a dome slew until the dome was in
place and had stopped moving.  Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope arrived
at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate application to translate the RA/Dec coordinates to
the
appropriate dome position.
In "Passive mode" APPM waits for the dome to finish slewing by polling the dome's driver (or intermediate
application).
So, it seems that your dome's ascom driver (or intermediate application) may not be correctly indicating
when
the dome is slewing.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do
my first APPM model tonight.  I'm having problems with the dome control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8
ft dome.  The pier is centered and the bottom of the mount is just about
even with the bottom of the dome.  The rotation control is homemade (my
COVID quarantine project) and works very will with both ASCOM DeviceHub
and SGP.  I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems
to do it's calculations based on the center of the dome instead of where
the telescope is.  This is not surprising since I can't seem to find any
where in the program or the documentation to set the mount and telescope
geometry.  I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the RA/DEC axes
intersection the bottom of my telescope is.  But I don't see anyway that
it could know where the center of my OTA is.  I really don't think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

     Anyway, when I use "Active", I end up imaging across the edge of the
slot because the slot is positioned for the center of the mount instead
of where the telescope is.  Most of the images ended up plate solving
anyway, but since  the stars are all diffraction spikes, I don't know
the quality of those solutions.  The initial slew to meridian is
probably the worst because the dome is in the exact opposite position
than it should be and my slot just goes barely past vertical.   I
checked the ASCOM logs on the PC and my ASCOM debug screen on the dome
controller.  The dome _is_ slewing to the position that APPM requests;
that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing?  Where do I enter the offsets for
the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two
different dome slaving programs: ASCOM Device Hub and SGP.  For "Delay
before starting dome slew checking", I used values ranging from 5 to 30
seconds.  For "Settle time after dome stops slewing", I used values from
1 to 20 seconds.  I didn't see any effect when changing these settings;
in all cases the the telescope slewed to the next position and started
imaging a few seconds after it got there--many seconds before the dome
was in position.  None of those images solved since the dome was in the
way.  Again, I can't figure out what I'm doing wrong--it's like I'm not
even changing the values.  Is there another setting that I'm missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome!  What am I missing?

Thanks - Shane

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







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








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









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


Ray Gralak
 

Hi Shane,

One more question, Ray: In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?
You would not want to connect APPM to the DeviceHub telescope. APPM uses some commands that the DeviceHub would not be able to pass through to the AP V2 driver.

That said, what is the use case for this?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Sunday, February 28, 2021 3:52 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

One more question, Ray: In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?

Thanks - Shane

On 2/27/2021 8:09 PM, Shane Ramotowski wrote:
Ahh, I think it understand. I use DeviceHub to do the slaving, but
still connect to the DeviceHub dome with APPM. I will try that and
see what happens.

Thanks - Shane

On 2/27/2021 5:27 PM, Ray Gralak wrote:
Shane,

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.
I think you misunderstood. ASCOM is not planning to add those APIs.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
In passive mode, APPM only needs to poll the Dome's slewing state to
work. If you can't do that then APPM won't be able to tell when the
dome is done slewing.

If Device Hub won't let APPM connect to the Dome driver you can use
the older ASCOM POTH application, which allows multiple applications
to connect to an ASCOM driver.

So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging?
First, the two parameters only have meaning when you are connected to
a Dome driver. If you are not connected they won't be used.

"Delay before starting dome slew checking"

The number of seconds before APPM will start checking the dome
driver's slew state. This delay allows the dome driver time to
initiate dome movement that will be reflected by reading "True" from
the Dome driver's "Slewing" property. If the value is False when
read, then dome slewing will be considered completed.

"Settle time after dome stops slewing"

The number of seconds to delay slew completion after the Dome
driver's "Slewing" property reads "False".

-Ray





-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of Shane Ramotowski
Sent: Saturday, February 27, 2021 2:16 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
_
So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging? Assume that I did not change
the default telescope slew of 900X. The log entry I posted is from a
session that used DeviceHub with "Delay before starting dome slew
check"
set to 30 seconds and "Settle time after dome stops slewing" set to 10
seconds. You can see that the time between the start of the telescope
slew and the the start of imaging is about 12 seconds. So, clearly, I
am not understanding how these two parameters work.

Thank you - Shane


On 2/27/2021 2:16 PM, Ray Gralak wrote:
Shane,

APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
Again, APPM does not do dome calculations (nor is there a plan for
it to do that). IMO, the ASCOM Dome API
is missing a way to send scope Ra/Dec/pierside to the Dome driver.
ASCOM makes such a big deal about
abstracting away telescope applications from the hardware, but the
incomplete Dome API pretty much forces
the use of a third-party application.
I think each dome manufacturer should each create their own drivers
that should take into account the
telescope and mount dimensions. It would have made life much easier
for each application developer that has
had to implement dome coordinate transformations in their applications.
> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the
meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be slaved
to the telescope. In this case APPM just
polls the slewing state until dome slewing stops. If slaving can't
be done, there is an option in APPM to pause
after each point, which would allow you to position the dome opening.
The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds. Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what
happened. Are you sure that you had
APPM connected to your Dome application?
BTW, the problem might be that you are using the ASCOM Device Hub
instead of the older POTH dome
handling. The behavior is dome behavior is different in Device Hub,
and it sounds like the author left out some
old functionality.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

Ray, thanks for the reply, but I don't really see anything that
will help.


APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>


I am definitely returning false fort the CanSlave and Slaved
properties,
since there is no hardware-based slaving capability in the dome
controller. And I don't see way to "send the telescope's destination
coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is
"SlewToAzimuth()"
but I think you are basing that azimuth on the center of the dome
rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the RA axis
rotates west and level and the DEC axis point strait up. The
telescope
is several inches West of the center of the mount. From what I
understand, if you are going to use SlewToAzimuth(), you need to
consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who
answer
most of the dome-related questions posted to the ASCOM Driver and
Application Development Support Forum, it has a whole section for
dome
and mount geometry in it's setup section to allow slaving.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the
meaning of
those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before starting
dome slew checking" is set to 30 seconds and "Settle time after dome
stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965: Info, State Machine,
Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103: Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10°
00'
00.0")
0467223 2021-02-26 20:46:22.105: Info, Slew Next,
East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105: Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec: 8.501824 / -10.000000 ( 08h 30m 06.56s /
-10°
00' 00.0")
0467226 2021-02-26 20:46:22.215: Info, State Machine,
Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482: Info, State Machine,
Entering
State=Slewing
0467228 2021-02-26 20:46:30.722: Info, State Machine,
Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741: Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970: Info, State Machine,
Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974: Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022: Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022: Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s / -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022: Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s / -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226: Info, State Machine,
Entering
State=StartImage
0467236 2021-02-26 20:46:33.260: Info, State Machine,
Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260: Info, State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260: Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5,
IsDarkFrame=False

The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds. Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?

The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the slewToAzimuth() is
issued until the dome is stopped at the requested position, then
returning FALSE until the next slew is issued Sometimes,
DeviceHub or
SGP will end up issuing more than one slew to get the dome to the
final
position. The slaving software notices that the telescope has
moved and
starts an azimuth slew to where is while the telescope is still
moving.
Once the dome arrives at that position, another azimuth slew to
get to
where the telescope finally stopped. Last night, the longest time
that
such multiple slews took was about 20 seconds. That is why I set the
"Delay before starting dome slew checking" to 30 seconds. I though
that
would make APPM not even check for a dome slew until the dome was in
place and had stopped moving. Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope
arrived
at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to
the
appropriate dome position.
In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate
application).
So, it seems that your dome's ascom driver (or intermediate
application) may not be correctly indicating
when
the dome is slewing.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and
tried to do
my first APPM model tonight. I'm having problems with the dome
control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around
anymore) 8
ft dome. The pier is centered and the bottom of the mount is
just about
even with the bottom of the dome. The rotation control is
homemade (my
COVID quarantine project) and works very will with both ASCOM
DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome
properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel,
APPM seems
to do it's calculations based on the center of the dome instead
of where
the telescope is. This is not surprising since I can't seem to
find any
where in the program or the documentation to set the mount and
telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the
RA/DEC axes
intersection the bottom of my telescope is. But I don't see
anyway that
it could know where the center of my OTA is. I really don't
think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the
edge of the
slot because the slot is positioned for the center of the mount
instead
of where the telescope is. Most of the images ended up plate
solving
anyway, but since the stars are all diffraction spikes, I don't
know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite
position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on
the dome
controller. The dome _is_ slewing to the position that APPM
requests;
that position just doesn't seem to be based on where the
telescope is.

Can anyone tell me what I'm missing? Where do I enter the
offsets for
the mount/scope geometer so that APPM can got to the correct
position?

So, after trying "Active", I swiched to "Passive" and tried with
two
different dome slaving programs: ASCOM Device Hub and SGP. For
"Delay
before starting dome slew checking", I used values ranging from
5 to 30
seconds. For "Settle time after dome stops slewing", I used
values from
1 to 20 seconds. I didn't see any effect when changing these
settings;
in all cases the the telescope slewed to the next position and
started
imaging a few seconds after it got there--many seconds before
the dome
was in position. None of those images solved since the dome was
in the
way. Again, I can't figure out what I'm doing wrong--it's like
I'm not
even changing the values. Is there another setting that I'm
missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

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







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








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









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




Shane Ramotowski
 

When using DeviceHub, if you are connected to both DeviceHub's telescope and dome drivers, then when you issue a telescope slew, DeviceHub knows the target RA and DEC and can start a dome slew to the azimuth that the telescope will end at.

If you cannot connect to the DeviceHub telescope and/or dome, then DeviceHub uses a polling scheme to ask where the telescope is and then send the dome to the correct azimuth.  The polling period, unfortunately, seems to have a minimum of 5 seconds.  So, during an APPM run, APPM will tell the telescope to slew.  Sometime less than 5 seconds later, DeviceHub will retrieve the current RA/DEC from the telescope and start the dome slewing to that position.  For longer slews, the telescope may still be moving.  5 seconds after the dome arrives at the indicated position, it finds that the telescope has moved again (in acutality, the telescope never stopped moving, simply completing its original slew.  So DeviceHub issues a second slew to get to the final position.

So for the Passive settings in APPM, I have to use timeouts long enough to account for 2 polling periods plus 2 slew times to ensure that the dome is really in position before imaging starts.  I can't let APPM catch the dome in a stopped state between two dome slews. I hope that makes sense.

I ran a large model last night using DeviceHub.  I lost 5 points in total, which isn't that bad.  Three of them were because of the bodaciously bright almost full moon and the other two were bad luck in the timing of long slews from the end of on string of points to the start of the next.  I was concerned that DeviceHub would not position properly for the counterweight-up points, but it did so correctly.  The model run took a lot longer than I expected since I was waiting 40 seconds (usually unnecessarily) for each point to give the dome time to get into position in case it was a long slew.

I really don't know if supporting DeviceHub's telescope driver will work.   I'm assuming that if the SideOfPier property is set correctly when the slew is issued, DeviceHub will go to the correct location even if it ends up counterweight-up.  But I haven't tested that and I really don't know how--well I guess I could write a little program to do that.  I will do so if you are considering adding such support and the results of that test would help.

As far as the APPM specific commands, could you allow a connection to DeviceHub to send the info necessary for the slew and then send the "special sauce" directly to the AP V2 driver?

- Shane

On 2/28/2021 8:10 AM, Ray Gralak wrote:
Hi Shane,

One more question, Ray: In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?
You would not want to connect APPM to the DeviceHub telescope. APPM uses some commands that the DeviceHub would not be able to pass through to the AP V2 driver.

That said, what is the use case for this?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Sunday, February 28, 2021 3:52 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

One more question, Ray: In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?

Thanks - Shane

On 2/27/2021 8:09 PM, Shane Ramotowski wrote:
Ahh, I think it understand. I use DeviceHub to do the slaving, but
still connect to the DeviceHub dome with APPM. I will try that and
see what happens.

Thanks - Shane

On 2/27/2021 5:27 PM, Ray Gralak wrote:
Shane,

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.
I think you misunderstood. ASCOM is not planning to add those APIs.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
In passive mode, APPM only needs to poll the Dome's slewing state to
work. If you can't do that then APPM won't be able to tell when the
dome is done slewing.

If Device Hub won't let APPM connect to the Dome driver you can use
the older ASCOM POTH application, which allows multiple applications
to connect to an ASCOM driver.

So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging?
First, the two parameters only have meaning when you are connected to
a Dome driver. If you are not connected they won't be used.

"Delay before starting dome slew checking"

The number of seconds before APPM will start checking the dome
driver's slew state. This delay allows the dome driver time to
initiate dome movement that will be reflected by reading "True" from
the Dome driver's "Slewing" property. If the value is False when
read, then dome slewing will be considered completed.

"Settle time after dome stops slewing"

The number of seconds to delay slew completion after the Dome
driver's "Slewing" property reads "False".

-Ray





-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of Shane Ramotowski
Sent: Saturday, February 27, 2021 2:16 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
_
So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging? Assume that I did not change
the default telescope slew of 900X. The log entry I posted is from a
session that used DeviceHub with "Delay before starting dome slew
check"
set to 30 seconds and "Settle time after dome stops slewing" set to 10
seconds. You can see that the time between the start of the telescope
slew and the the start of imaging is about 12 seconds. So, clearly, I
am not understanding how these two parameters work.

Thank you - Shane


On 2/27/2021 2:16 PM, Ray Gralak wrote:
Shane,

APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
Again, APPM does not do dome calculations (nor is there a plan for
it to do that). IMO, the ASCOM Dome API
is missing a way to send scope Ra/Dec/pierside to the Dome driver.
ASCOM makes such a big deal about
abstracting away telescope applications from the hardware, but the
incomplete Dome API pretty much forces
the use of a third-party application.
I think each dome manufacturer should each create their own drivers
that should take into account the
telescope and mount dimensions. It would have made life much easier
for each application developer that has
had to implement dome coordinate transformations in their applications.
> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the
meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be slaved
to the telescope. In this case APPM just
polls the slewing state until dome slewing stops. If slaving can't
be done, there is an option in APPM to pause
after each point, which would allow you to position the dome opening.
The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds. Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what
happened. Are you sure that you had
APPM connected to your Dome application?
BTW, the problem might be that you are using the ASCOM Device Hub
instead of the older POTH dome
handling. The behavior is dome behavior is different in Device Hub,
and it sounds like the author left out some
old functionality.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

Ray, thanks for the reply, but I don't really see anything that
will help.


APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>


I am definitely returning false fort the CanSlave and Slaved
properties,
since there is no hardware-based slaving capability in the dome
controller. And I don't see way to "send the telescope's destination
coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is
"SlewToAzimuth()"
but I think you are basing that azimuth on the center of the dome
rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the RA axis
rotates west and level and the DEC axis point strait up. The
telescope
is several inches West of the center of the mount. From what I
understand, if you are going to use SlewToAzimuth(), you need to
consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who
answer
most of the dome-related questions posted to the ASCOM Driver and
Application Development Support Forum, it has a whole section for
dome
and mount geometry in it's setup section to allow slaving.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the
meaning of
those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before starting
dome slew checking" is set to 30 seconds and "Settle time after dome
stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965: Info, State Machine,
Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103: Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10°
00'
00.0")
0467223 2021-02-26 20:46:22.105: Info, Slew Next,
East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105: Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec: 8.501824 / -10.000000 ( 08h 30m 06.56s /
-10°
00' 00.0")
0467226 2021-02-26 20:46:22.215: Info, State Machine,
Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482: Info, State Machine,
Entering
State=Slewing
0467228 2021-02-26 20:46:30.722: Info, State Machine,
Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741: Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970: Info, State Machine,
Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974: Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022: Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022: Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s / -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022: Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s / -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226: Info, State Machine,
Entering
State=StartImage
0467236 2021-02-26 20:46:33.260: Info, State Machine,
Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260: Info, State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260: Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5,
IsDarkFrame=False

The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds. Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?

The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the slewToAzimuth() is
issued until the dome is stopped at the requested position, then
returning FALSE until the next slew is issued Sometimes,
DeviceHub or
SGP will end up issuing more than one slew to get the dome to the
final
position. The slaving software notices that the telescope has
moved and
starts an azimuth slew to where is while the telescope is still
moving.
Once the dome arrives at that position, another azimuth slew to
get to
where the telescope finally stopped. Last night, the longest time
that
such multiple slews took was about 20 seconds. That is why I set the
"Delay before starting dome slew checking" to 30 seconds. I though
that
would make APPM not even check for a dome slew until the dome was in
place and had stopped moving. Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope
arrived
at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to
the
appropriate dome position.
In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate
application).
So, it seems that your dome's ascom driver (or intermediate
application) may not be correctly indicating
when
the dome is slewing.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and
tried to do
my first APPM model tonight. I'm having problems with the dome
control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around
anymore) 8
ft dome. The pier is centered and the bottom of the mount is
just about
even with the bottom of the dome. The rotation control is
homemade (my
COVID quarantine project) and works very will with both ASCOM
DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome
properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel,
APPM seems
to do it's calculations based on the center of the dome instead
of where
the telescope is. This is not surprising since I can't seem to
find any
where in the program or the documentation to set the mount and
telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the
RA/DEC axes
intersection the bottom of my telescope is. But I don't see
anyway that
it could know where the center of my OTA is. I really don't
think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the
edge of the
slot because the slot is positioned for the center of the mount
instead
of where the telescope is. Most of the images ended up plate
solving
anyway, but since the stars are all diffraction spikes, I don't
know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite
position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on
the dome
controller. The dome _is_ slewing to the position that APPM
requests;
that position just doesn't seem to be based on where the
telescope is.

Can anyone tell me what I'm missing? Where do I enter the
offsets for
the mount/scope geometer so that APPM can got to the correct
position?

So, after trying "Active", I swiched to "Passive" and tried with
two
different dome slaving programs: ASCOM Device Hub and SGP. For
"Delay
before starting dome slew checking", I used values ranging from
5 to 30
seconds. For "Settle time after dome stops slewing", I used
values from
1 to 20 seconds. I didn't see any effect when changing these
settings;
in all cases the the telescope slewed to the next position and
started
imaging a few seconds after it got there--many seconds before
the dome
was in position. None of those images solved since the dome was
in the
way. Again, I can't figure out what I'm doing wrong--it's like
I'm not
even changing the values. Is there another setting that I'm
missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

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






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







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








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








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


Ray Gralak
 

Shane,

As far as the APPM specific commands, could you allow a connection to
DeviceHub to send the info necessary for the slew and then send the
"special sauce" directly to the AP V2 driver?
I would have to bring this up with Marj to see if this is something A-P would want to have implemented and supported. Are you aware of any others that would want this feature?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Sunday, February 28, 2021 4:29 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

When using DeviceHub, if you are connected to both DeviceHub's telescope
and dome drivers, then when you issue a telescope slew, DeviceHub knows
the target RA and DEC and can start a dome slew to the azimuth that the
telescope will end at.

If you cannot connect to the DeviceHub telescope and/or dome, then
DeviceHub uses a polling scheme to ask where the telescope is and then
send the dome to the correct azimuth. The polling period,
unfortunately, seems to have a minimum of 5 seconds. So, during an APPM
run, APPM will tell the telescope to slew. Sometime less than 5 seconds
later, DeviceHub will retrieve the current RA/DEC from the telescope and
start the dome slewing to that position. For longer slews, the
telescope may still be moving. 5 seconds after the dome arrives at the
indicated position, it finds that the telescope has moved again (in
acutality, the telescope never stopped moving, simply completing its
original slew. So DeviceHub issues a second slew to get to the final
position.

So for the Passive settings in APPM, I have to use timeouts long enough
to account for 2 polling periods plus 2 slew times to ensure that the
dome is really in position before imaging starts. I can't let APPM
catch the dome in a stopped state between two dome slews. I hope that
makes sense.

I ran a large model last night using DeviceHub. I lost 5 points in
total, which isn't that bad. Three of them were because of the
bodaciously bright almost full moon and the other two were bad luck in
the timing of long slews from the end of on string of points to the
start of the next. I was concerned that DeviceHub would not position
properly for the counterweight-up points, but it did so correctly. The
model run took a lot longer than I expected since I was waiting 40
seconds (usually unnecessarily) for each point to give the dome time to
get into position in case it was a long slew.

I really don't know if supporting DeviceHub's telescope driver will
work. I'm assuming that if the SideOfPier property is set correctly
when the slew is issued, DeviceHub will go to the correct location even
if it ends up counterweight-up. But I haven't tested that and I really
don't know how--well I guess I could write a little program to do that.
I will do so if you are considering adding such support and the results
of that test would help.

As far as the APPM specific commands, could you allow a connection to
DeviceHub to send the info necessary for the slew and then send the
"special sauce" directly to the AP V2 driver?

- Shane

On 2/28/2021 8:10 AM, Ray Gralak wrote:
Hi Shane,

One more question, Ray: In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?
You would not want to connect APPM to the DeviceHub telescope. APPM uses some commands that the
DeviceHub would not be able to pass through to the AP V2 driver.

That said, what is the use case for this?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Sunday, February 28, 2021 3:52 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

One more question, Ray: In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?

Thanks - Shane

On 2/27/2021 8:09 PM, Shane Ramotowski wrote:
Ahh, I think it understand. I use DeviceHub to do the slaving, but
still connect to the DeviceHub dome with APPM. I will try that and
see what happens.

Thanks - Shane

On 2/27/2021 5:27 PM, Ray Gralak wrote:
Shane,

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.
I think you misunderstood. ASCOM is not planning to add those APIs.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
In passive mode, APPM only needs to poll the Dome's slewing state to
work. If you can't do that then APPM won't be able to tell when the
dome is done slewing.

If Device Hub won't let APPM connect to the Dome driver you can use
the older ASCOM POTH application, which allows multiple applications
to connect to an ASCOM driver.

So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging?
First, the two parameters only have meaning when you are connected to
a Dome driver. If you are not connected they won't be used.

"Delay before starting dome slew checking"

The number of seconds before APPM will start checking the dome
driver's slew state. This delay allows the dome driver time to
initiate dome movement that will be reflected by reading "True" from
the Dome driver's "Slewing" property. If the value is False when
read, then dome slewing will be considered completed.

"Settle time after dome stops slewing"

The number of seconds to delay slew completion after the Dome
driver's "Slewing" property reads "False".

-Ray





-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of Shane Ramotowski
Sent: Saturday, February 27, 2021 2:16 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
_
So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging? Assume that I did not change
the default telescope slew of 900X. The log entry I posted is from a
session that used DeviceHub with "Delay before starting dome slew
check"
set to 30 seconds and "Settle time after dome stops slewing" set to 10
seconds. You can see that the time between the start of the telescope
slew and the the start of imaging is about 12 seconds. So, clearly, I
am not understanding how these two parameters work.

Thank you - Shane


On 2/27/2021 2:16 PM, Ray Gralak wrote:
Shane,

APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
Again, APPM does not do dome calculations (nor is there a plan for
it to do that). IMO, the ASCOM Dome API
is missing a way to send scope Ra/Dec/pierside to the Dome driver.
ASCOM makes such a big deal about
abstracting away telescope applications from the hardware, but the
incomplete Dome API pretty much forces
the use of a third-party application.
I think each dome manufacturer should each create their own drivers
that should take into account the
telescope and mount dimensions. It would have made life much easier
for each application developer that has
had to implement dome coordinate transformations in their applications.
> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the
meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be slaved
to the telescope. In this case APPM just
polls the slewing state until dome slewing stops. If slaving can't
be done, there is an option in APPM to pause
after each point, which would allow you to position the dome opening.
The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds. Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what
happened. Are you sure that you had
APPM connected to your Dome application?
BTW, the problem might be that you are using the ASCOM Device Hub
instead of the older POTH dome
handling. The behavior is dome behavior is different in Device Hub,
and it sounds like the author left out some
old functionality.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

Ray, thanks for the reply, but I don't really see anything that
will help.


APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>


I am definitely returning false fort the CanSlave and Slaved
properties,
since there is no hardware-based slaving capability in the dome
controller. And I don't see way to "send the telescope's destination
coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is
"SlewToAzimuth()"
but I think you are basing that azimuth on the center of the dome
rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the RA axis
rotates west and level and the DEC axis point strait up. The
telescope
is several inches West of the center of the mount. From what I
understand, if you are going to use SlewToAzimuth(), you need to
consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who
answer
most of the dome-related questions posted to the ASCOM Driver and
Application Development Support Forum, it has a whole section for
dome
and mount geometry in it's setup section to allow slaving.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the
meaning of
those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before starting
dome slew checking" is set to 30 seconds and "Settle time after dome
stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965: Info, State Machine,
Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103: Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10°
00'
00.0")
0467223 2021-02-26 20:46:22.105: Info, Slew Next,
East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105: Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec: 8.501824 / -10.000000 ( 08h 30m 06.56s /
-10°
00' 00.0")
0467226 2021-02-26 20:46:22.215: Info, State Machine,
Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482: Info, State Machine,
Entering
State=Slewing
0467228 2021-02-26 20:46:30.722: Info, State Machine,
Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741: Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970: Info, State Machine,
Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974: Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022: Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022: Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s / -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022: Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s / -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226: Info, State Machine,
Entering
State=StartImage
0467236 2021-02-26 20:46:33.260: Info, State Machine,
Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260: Info, State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260: Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5,
IsDarkFrame=False

The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds. Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?

The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the slewToAzimuth() is
issued until the dome is stopped at the requested position, then
returning FALSE until the next slew is issued Sometimes,
DeviceHub or
SGP will end up issuing more than one slew to get the dome to the
final
position. The slaving software notices that the telescope has
moved and
starts an azimuth slew to where is while the telescope is still
moving.
Once the dome arrives at that position, another azimuth slew to
get to
where the telescope finally stopped. Last night, the longest time
that
such multiple slews took was about 20 seconds. That is why I set the
"Delay before starting dome slew checking" to 30 seconds. I though
that
would make APPM not even check for a dome slew until the dome was in
place and had stopped moving. Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope
arrived
at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to
the
appropriate dome position.
In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate
application).
So, it seems that your dome's ascom driver (or intermediate
application) may not be correctly indicating
when
the dome is slewing.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and
tried to do
my first APPM model tonight. I'm having problems with the dome
control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around
anymore) 8
ft dome. The pier is centered and the bottom of the mount is
just about
even with the bottom of the dome. The rotation control is
homemade (my
COVID quarantine project) and works very will with both ASCOM
DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome
properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel,
APPM seems
to do it's calculations based on the center of the dome instead
of where
the telescope is. This is not surprising since I can't seem to
find any
where in the program or the documentation to set the mount and
telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the
RA/DEC axes
intersection the bottom of my telescope is. But I don't see
anyway that
it could know where the center of my OTA is. I really don't
think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the
edge of the
slot because the slot is positioned for the center of the mount
instead
of where the telescope is. Most of the images ended up plate
solving
anyway, but since the stars are all diffraction spikes, I don't
know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite
position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on
the dome
controller. The dome _is_ slewing to the position that APPM
requests;
that position just doesn't seem to be based on where the
telescope is.

Can anyone tell me what I'm missing? Where do I enter the
offsets for
the mount/scope geometer so that APPM can got to the correct
position?

So, after trying "Active", I swiched to "Passive" and tried with
two
different dome slaving programs: ASCOM Device Hub and SGP. For
"Delay
before starting dome slew checking", I used values ranging from
5 to 30
seconds. For "Settle time after dome stops slewing", I used
values from
1 to 20 seconds. I didn't see any effect when changing these
settings;
in all cases the the telescope slewed to the next position and
started
imaging a few seconds after it got there--many seconds before
the dome
was in position. None of those images solved since the dome was
in the
way. Again, I can't figure out what I'm doing wrong--it's like
I'm not
even changing the values. Is there another setting that I'm
missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

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






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







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








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









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




Shane Ramotowski
 

Not personally, but I would think that anyone using a rotational dome would need some way to position it so that the telescope is not blocked by the slot.  Since the "Active" mode doesn't do the geometry, unless you have a very wide slot that goes significantly past vertical, "Passive" is really the only option.  I was unable to test POTH, as you suggested, since it is depricated, no longer part of the ASCOM 6.5SP1 distribution, and I could not find a download of it from a reliable source.  I would expect, however, that it would have a similar issue, either needing to know where the telescope is slewing to or slewing the dome by polling the telescope's position periodically.  SGP has slaving that works well and has a minimum polling frequency of 1 seconds.  But it was made with the intention of some other application connecting to SGP to query the dome slewing state.  I don't know of any other solution than DeviceHub if you are running up-to-date ASCOM.

Of course if you have a roll-off, open clam shell, or are just outside, you don't need any dome support all!

I'm guessing, based on my serial number, that there are a little over 120 Mach2's out there that came with APPM.  I don't know how many copies of APPM are being used by 1100 and 1600 users, nor how many of those users along with other Mach2 owners have rotational domes (I think roll-offs are much more popular), but I am a bit surprised that this has not been brought up before.  The Mach2 is fairly compact and I am using a 4" refractor, so my geometry ought to be about as optimal as it gets.  The slot in my dome looks to be a similar proportion to other domes I've seen; it is by no means overly narrow.  And yet, in Active mode, for most of the sample points, the dome ends up covering more than half of the telescopes view, so I need to use Passive mode.  Maybe I really am doing something totally wrong and stupid, but I sure don't know what that would be...

- Shane

On 2/28/2021 7:19 PM, Ray Gralak wrote:
Shane,

As far as the APPM specific commands, could you allow a connection to
DeviceHub to send the info necessary for the slew and then send the
"special sauce" directly to the AP V2 driver?
I would have to bring this up with Marj to see if this is something A-P would want to have implemented and supported. Are you aware of any others that would want this feature?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Sunday, February 28, 2021 4:29 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

When using DeviceHub, if you are connected to both DeviceHub's telescope
and dome drivers, then when you issue a telescope slew, DeviceHub knows
the target RA and DEC and can start a dome slew to the azimuth that the
telescope will end at.

If you cannot connect to the DeviceHub telescope and/or dome, then
DeviceHub uses a polling scheme to ask where the telescope is and then
send the dome to the correct azimuth. The polling period,
unfortunately, seems to have a minimum of 5 seconds. So, during an APPM
run, APPM will tell the telescope to slew. Sometime less than 5 seconds
later, DeviceHub will retrieve the current RA/DEC from the telescope and
start the dome slewing to that position. For longer slews, the
telescope may still be moving. 5 seconds after the dome arrives at the
indicated position, it finds that the telescope has moved again (in
acutality, the telescope never stopped moving, simply completing its
original slew. So DeviceHub issues a second slew to get to the final
position.

So for the Passive settings in APPM, I have to use timeouts long enough
to account for 2 polling periods plus 2 slew times to ensure that the
dome is really in position before imaging starts. I can't let APPM
catch the dome in a stopped state between two dome slews. I hope that
makes sense.

I ran a large model last night using DeviceHub. I lost 5 points in
total, which isn't that bad. Three of them were because of the
bodaciously bright almost full moon and the other two were bad luck in
the timing of long slews from the end of on string of points to the
start of the next. I was concerned that DeviceHub would not position
properly for the counterweight-up points, but it did so correctly. The
model run took a lot longer than I expected since I was waiting 40
seconds (usually unnecessarily) for each point to give the dome time to
get into position in case it was a long slew.

I really don't know if supporting DeviceHub's telescope driver will
work. I'm assuming that if the SideOfPier property is set correctly
when the slew is issued, DeviceHub will go to the correct location even
if it ends up counterweight-up. But I haven't tested that and I really
don't know how--well I guess I could write a little program to do that.
I will do so if you are considering adding such support and the results
of that test would help.

As far as the APPM specific commands, could you allow a connection to
DeviceHub to send the info necessary for the slew and then send the
"special sauce" directly to the AP V2 driver?

- Shane

On 2/28/2021 8:10 AM, Ray Gralak wrote:
Hi Shane,

One more question, Ray: In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?
You would not want to connect APPM to the DeviceHub telescope. APPM uses some commands that the
DeviceHub would not be able to pass through to the AP V2 driver.
That said, what is the use case for this?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Sunday, February 28, 2021 3:52 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

One more question, Ray: In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?

Thanks - Shane

On 2/27/2021 8:09 PM, Shane Ramotowski wrote:
Ahh, I think it understand. I use DeviceHub to do the slaving, but
still connect to the DeviceHub dome with APPM. I will try that and
see what happens.

Thanks - Shane

On 2/27/2021 5:27 PM, Ray Gralak wrote:
Shane,

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.
I think you misunderstood. ASCOM is not planning to add those APIs.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
In passive mode, APPM only needs to poll the Dome's slewing state to
work. If you can't do that then APPM won't be able to tell when the
dome is done slewing.

If Device Hub won't let APPM connect to the Dome driver you can use
the older ASCOM POTH application, which allows multiple applications
to connect to an ASCOM driver.

So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging?
First, the two parameters only have meaning when you are connected to
a Dome driver. If you are not connected they won't be used.

"Delay before starting dome slew checking"

The number of seconds before APPM will start checking the dome
driver's slew state. This delay allows the dome driver time to
initiate dome movement that will be reflected by reading "True" from
the Dome driver's "Slewing" property. If the value is False when
read, then dome slewing will be considered completed.

"Settle time after dome stops slewing"

The number of seconds to delay slew completion after the Dome
driver's "Slewing" property reads "False".

-Ray





-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of Shane Ramotowski
Sent: Saturday, February 27, 2021 2:16 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

OK. I'll wait for the ASCOM folks to add the APIs that you want before
I try to use "Active" mode again.

For the second part of my reply, I guess I did not make it clear enough
that I was using DeviceHub not allowing APPM to connect to the dome,
since APPM cannot send the dome to the correct position an DeviceHub
can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
_
So can you please tell me what settings I can use for "Delay before
staring dome slew check" and "Settle time after dome stops slewing" to
ensure that I end up with at least 30 seconds between the end of the
telescope slew and the start of imaging? Assume that I did not change
the default telescope slew of 900X. The log entry I posted is from a
session that used DeviceHub with "Delay before starting dome slew
check"
set to 30 seconds and "Settle time after dome stops slewing" set to 10
seconds. You can see that the time between the start of the telescope
slew and the the start of imaging is about 12 seconds. So, clearly, I
am not understanding how these two parameters work.

Thank you - Shane


On 2/27/2021 2:16 PM, Ray Gralak wrote:
Shane,

APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
Again, APPM does not do dome calculations (nor is there a plan for
it to do that). IMO, the ASCOM Dome API
is missing a way to send scope Ra/Dec/pierside to the Dome driver.
ASCOM makes such a big deal about
abstracting away telescope applications from the hardware, but the
incomplete Dome API pretty much forces
the use of a third-party application.
I think each dome manufacturer should each create their own drivers
that should take into account the
telescope and mount dimensions. It would have made life much easier
for each application developer that has
had to implement dome coordinate transformations in their applications.
> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the
meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be slaved
to the telescope. In this case APPM just
polls the slewing state until dome slewing stops. If slaving can't
be done, there is an option in APPM to pause
after each point, which would allow you to position the dome opening.
The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds. Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what
happened. Are you sure that you had
APPM connected to your Dome application?
BTW, the problem might be that you are using the ASCOM Device Hub
instead of the older POTH dome
handling. The behavior is dome behavior is different in Device Hub,
and it sounds like the author left out some
old functionality.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions

Ray, thanks for the reply, but I don't really see anything that
will help.


APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work? What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>


I am definitely returning false fort the CanSlave and Slaved
properties,
since there is no hardware-based slaving capability in the dome
controller. And I don't see way to "send the telescope's destination
coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is
"SlewToAzimuth()"
but I think you are basing that azimuth on the center of the dome
rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the RA axis
rotates west and level and the DEC axis point strait up. The
telescope
is several inches West of the center of the mount. From what I
understand, if you are going to use SlewToAzimuth(), you need to
consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who
answer
most of the dome-related questions posted to the ASCOM Driver and
Application Development Support Forum, it has a whole section for
dome
and mount geometry in it's setup section to allow slaving.

> In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected. What should I set the two passive
values to to ensure that the imaging doesn't start for, say, 1 minute
after the scope stops slewing? Or am I not understanding the
meaning of
those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before starting
dome slew checking" is set to 30 seconds and "Settle time after dome
stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965: Info, State Machine,
Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103: Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10°
00'
00.0")
0467223 2021-02-26 20:46:22.105: Info, Slew Next,
East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105: Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec: 8.501824 / -10.000000 ( 08h 30m 06.56s /
-10°
00' 00.0")
0467226 2021-02-26 20:46:22.215: Info, State Machine,
Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482: Info, State Machine,
Entering
State=Slewing
0467228 2021-02-26 20:46:30.722: Info, State Machine,
Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741: Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970: Info, State Machine,
Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974: Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022: Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022: Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s / -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022: Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s / -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226: Info, State Machine,
Entering
State=StartImage
0467236 2021-02-26 20:46:33.260: Info, State Machine,
Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260: Info, State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260: Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5,
IsDarkFrame=False

The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds. Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen? What am I
misunderstanding?

The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the slewToAzimuth() is
issued until the dome is stopped at the requested position, then
returning FALSE until the next slew is issued Sometimes,
DeviceHub or
SGP will end up issuing more than one slew to get the dome to the
final
position. The slaving software notices that the telescope has
moved and
starts an azimuth slew to where is while the telescope is still
moving.
Once the dome arrives at that position, another azimuth slew to
get to
where the telescope finally stopped. Last night, the longest time
that
such multiple slews took was about 20 seconds. That is why I set the
"Delay before starting dome slew checking" to 30 seconds. I though
that
would make APPM not even check for a dome slew until the dome was in
place and had stopped moving. Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope
arrived
at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to
the
appropriate dome position.
In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate
application).
So, it seems that your dome's ascom driver (or intermediate
application) may not be correctly indicating
when
the dome is slewing.
-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and
tried to do
my first APPM model tonight. I'm having problems with the dome
control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around
anymore) 8
ft dome. The pier is centered and the bottom of the mount is
just about
even with the bottom of the dome. The rotation control is
homemade (my
COVID quarantine project) and works very will with both ASCOM
DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome
properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel,
APPM seems
to do it's calculations based on the center of the dome instead
of where
the telescope is. This is not surprising since I can't seem to
find any
where in the program or the documentation to set the mount and
telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the
RA/DEC axes
intersection the bottom of my telescope is. But I don't see
anyway that
it could know where the center of my OTA is. I really don't
think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the
edge of the
slot because the slot is positioned for the center of the mount
instead
of where the telescope is. Most of the images ended up plate
solving
anyway, but since the stars are all diffraction spikes, I don't
know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite
position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on
the dome
controller. The dome _is_ slewing to the position that APPM
requests;
that position just doesn't seem to be based on where the
telescope is.

Can anyone tell me what I'm missing? Where do I enter the
offsets for
the mount/scope geometer so that APPM can got to the correct
position?

So, after trying "Active", I swiched to "Passive" and tried with
two
different dome slaving programs: ASCOM Device Hub and SGP. For
"Delay
before starting dome slew checking", I used values ranging from
5 to 30
seconds. For "Settle time after dome stops slewing", I used
values from
1 to 20 seconds. I didn't see any effect when changing these
settings;
in all cases the the telescope slewed to the next position and
started
imaging a few seconds after it got there--many seconds before
the dome
was in position. None of those images solved since the dome was
in the
way. Again, I can't figure out what I'm doing wrong--it's like
I'm not
even changing the values. Is there another setting that I'm
missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

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





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






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







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








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








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


Ray Gralak
 

> I was unable to test POTH, as you

> suggested, since it is depricated, no longer part of the ASCOM 6.5SP1

> distribution

 

Sorry, but that is incorrect!

 

By default, POTH is not installed, but it can be installed if you select it..

 

Here’s a screenshot of the ASCOM 6.5 SP1 Setup:

 

 

-Ray

 

> -----Original Message-----

> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski

> Sent: Sunday, February 28, 2021 7:06 PM

> To: main@ap-gto.groups.io

> Subject: Re: [ap-gto] APPM with Dome Questions

>

> Not personally, but I would think that anyone using a rotational dome

> would need some way to position it so that the telescope is not blocked

> by the slot.  Since the "Active" mode doesn't do the geometry, unless

> you have a very wide slot that goes significantly past vertical,

> "Passive" is really the only option.  I was unable to test POTH, as you

> suggested, since it is depricated, no longer part of the ASCOM 6.5SP1

> distribution, and I could not find a download of it from a reliable

> source.  I would expect, however, that it would have a similar issue,

> either needing to know where the telescope is slewing to or slewing the

> dome by polling the telescope's position periodically.  SGP has slaving

> that works well and has a minimum polling frequency of 1 seconds.  But

> it was made with the intention of some other application connecting to

> SGP to query the dome slewing state.  I don't know of any other solution

> than DeviceHub if you are running up-to-date ASCOM.

>

> Of course if you have a roll-off, open clam shell, or are just outside,

> you don't need any dome support all!

>

> I'm guessing, based on my serial number, that there are a little over

> 120 Mach2's out there that came with APPM.  I don't know how many copies

> of APPM are being used by 1100 and 1600 users, nor how many of those

> users along with other Mach2 owners have rotational domes (I think

> roll-offs are much more popular), but I am a bit surprised that this has

> not been brought up before.  The Mach2 is fairly compact and I am using

> a 4" refractor, so my geometry ought to be about as optimal as it gets.

> The slot in my dome looks to be a similar proportion to other domes I've

> seen; it is by no means overly narrow.  And yet, in Active mode, for

> most of the sample points, the dome ends up covering more than half of

> the telescopes view, so I need to use Passive mode.  Maybe I really am

> doing something totally wrong and stupid, but I sure don't know what

> that would be...

>

> - Shane

>

> On 2/28/2021 7:19 PM, Ray Gralak wrote:

> > Shane,

> >

> >> As far as the APPM specific commands, could you allow a connection to

> >> DeviceHub to send the info necessary for the slew and then send the

> >> "special sauce" directly to the AP V2 driver?

> > I would have to bring this up with Marj to see if this is something A-P would want to have implemented and

> supported. Are you aware of any others that  would want this feature?

> >

> > -Ray

> >

> >> -----Original Message-----

> >> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski

> >> Sent: Sunday, February 28, 2021 4:29 PM

> >> To: main@ap-gto.groups.io

> >> Subject: Re: [ap-gto] APPM with Dome Questions

> >>

> >> When using DeviceHub, if you are connected to both DeviceHub's telescope

> >> and dome drivers, then when you issue a telescope slew, DeviceHub knows

> >> the target RA and DEC and can start a dome slew to the azimuth that the

> >> telescope will end at.

> >>

> >> If you cannot connect to the DeviceHub telescope and/or dome, then

> >> DeviceHub uses a polling scheme to ask where the telescope is and then

> >> send the dome to the correct azimuth.  The polling period,

> >> unfortunately, seems to have a minimum of 5 seconds.  So, during an APPM

> >> run, APPM will tell the telescope to slew.  Sometime less than 5 seconds

> >> later, DeviceHub will retrieve the current RA/DEC from the telescope and

> >> start the dome slewing to that position.  For longer slews, the

> >> telescope may still be moving.  5 seconds after the dome arrives at the

> >> indicated position, it finds that the telescope has moved again (in

> >> acutality, the telescope never stopped moving, simply completing its

> >> original slew.  So DeviceHub issues a second slew to get to the final

> >> position.

> >>

> >> So for the Passive settings in APPM, I have to use timeouts long enough

> >> to account for 2 polling periods plus 2 slew times to ensure that the

> >> dome is really in position before imaging starts.  I can't let APPM

> >> catch the dome in a stopped state between two dome slews. I hope that

> >> makes sense.

> >>

> >> I ran a large model last night using DeviceHub.  I lost 5 points in

> >> total, which isn't that bad.  Three of them were because of the

> >> bodaciously bright almost full moon and the other two were bad luck in

> >> the timing of long slews from the end of on string of points to the

> >> start of the next.  I was concerned that DeviceHub would not position

> >> properly for the counterweight-up points, but it did so correctly.  The

> >> model run took a lot longer than I expected since I was waiting 40

> >> seconds (usually unnecessarily) for each point to give the dome time to

> >> get into position in case it was a long slew.

> >>

> >> I really don't know if supporting DeviceHub's telescope driver will

> >> work.   I'm assuming that if the SideOfPier property is set correctly

> >> when the slew is issued, DeviceHub will go to the correct location even

> >> if it ends up counterweight-up.  But I haven't tested that and I really

> >> don't know how--well I guess I could write a little program to do that.

> >> I will do so if you are considering adding such support and the results

> >> of that test would help.

> >>

> >> As far as the APPM specific commands, could you allow a connection to

> >> DeviceHub to send the info necessary for the slew and then send the

> >> "special sauce" directly to the AP V2 driver?

> >>

> >> - Shane

> >>

> >> On 2/28/2021 8:10 AM, Ray Gralak wrote:

> >>> Hi Shane,

> >>>

> >>>> One more question, Ray:  In APPM, is there a way to connect to the

> >>>> DeviceHub telescope or is it locked to the AP ASCOM driver?

> >>> You would not want to connect APPM to the DeviceHub telescope. APPM uses some commands that the

> >> DeviceHub would not be able to pass through to the AP V2 driver.

> >>> That said, what is the use case for this?

> >>>

> >>> -Ray

> >>>

> >>>> -----Original Message-----

> >>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski

> >>>> Sent: Sunday, February 28, 2021 3:52 AM

> >>>> To: main@ap-gto.groups.io

> >>>> Subject: Re: [ap-gto] APPM with Dome Questions

> >>>>

> >>>> One more question, Ray:  In APPM, is there a way to connect to the

> >>>> DeviceHub telescope or is it locked to the AP ASCOM driver?

> >>>>

> >>>> Thanks - Shane

> >>>>

> >>>> On 2/27/2021 8:09 PM, Shane Ramotowski wrote:

> >>>>> Ahh, I think it understand.  I use DeviceHub to do the slaving, but

> >>>>> still connect to the DeviceHub dome with APPM.   I will try that and

> >>>>> see what happens.

> >>>>>

> >>>>> Thanks - Shane

> >>>>>

> >>>>> On 2/27/2021 5:27 PM, Ray Gralak wrote:

> >>>>>> Shane,

> >>>>>>

> >>>>>>> OK.  I'll wait for the ASCOM folks to add the APIs that you want before

> >>>>>>> I try to use "Active" mode again.

> >>>>>> I think you misunderstood. ASCOM is not planning to add those APIs.

> >>>>>>

> >>>>>>> For the second part of my reply, I guess I did not make it clear enough

> >>>>>>> that I was using DeviceHub not allowing APPM to connect to the dome,

> >>>>>>> since APPM cannot send the dome to the correct position an DeviceHub

> >>>>>>> can. _I am simply trying to understand what I'm doing wrong when

> >>>>>>> setting

> >>>>>>> up "Passive" parameters in the "Dome Settings" box.__

> >>>>>> In passive mode, APPM only needs to poll the Dome's slewing state to

> >>>>>> work. If you can't do that then APPM won't be able to tell when the

> >>>>>> dome is done slewing.

> >>>>>>

> >>>>>> If Device Hub won't let APPM connect to the Dome driver you can use

> >>>>>> the older ASCOM POTH application, which allows multiple applications

> >>>>>> to connect to an ASCOM driver.

> >>>>>>

> >>>>>>> So can you please tell me what settings I can use for "Delay before

> >>>>>>> staring dome slew check" and "Settle time after dome stops slewing" to

> >>>>>>> ensure that I end up with at least 30 seconds between the end of the

> >>>>>>> telescope slew and the start of imaging?

> >>>>>> First, the two parameters only have meaning when you are connected to

> >>>>>> a Dome driver. If you are not connected they won't be used.

> >>>>>>

> >>>>>> "Delay before starting dome slew checking"

> >>>>>>

> >>>>>> The number of seconds before APPM will start checking the dome

> >>>>>> driver's slew state. This delay allows the dome driver time to

> >>>>>> initiate dome movement that will be reflected by reading "True" from

> >>>>>> the Dome driver's "Slewing" property. If the value is False when

> >>>>>> read, then dome slewing will be considered completed.

> >>>>>>

> >>>>>> "Settle time after dome stops slewing"

> >>>>>>

> >>>>>> The number of seconds to delay slew completion after the Dome

> >>>>>> driver's "Slewing" property reads "False".

> >>>>>>

> >>>>>> -Ray

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>> -----Original Message-----

> >>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf

> >>>>>>> Of Shane Ramotowski

> >>>>>>> Sent: Saturday, February 27, 2021 2:16 PM

> >>>>>>> To: main@ap-gto.groups.io

> >>>>>>> Subject: Re: [ap-gto] APPM with Dome Questions

> >>>>>>>

> >>>>>>> OK.  I'll wait for the ASCOM folks to add the APIs that you want before

> >>>>>>> I try to use "Active" mode again.

> >>>>>>>

> >>>>>>> For the second part of my reply, I guess I did not make it clear enough

> >>>>>>> that I was using DeviceHub not allowing APPM to connect to the dome,

> >>>>>>> since APPM cannot send the dome to the correct position an DeviceHub

> >>>>>>> can. _I am simply trying to understand what I'm doing wrong when

> >>>>>>> setting

> >>>>>>> up "Passive" parameters in the "Dome Settings" box.__

> >>>>>>> _

> >>>>>>> So can you please tell me what settings I can use for "Delay before

> >>>>>>> staring dome slew check" and "Settle time after dome stops slewing" to

> >>>>>>> ensure that I end up with at least 30 seconds between the end of the

> >>>>>>> telescope slew and the start of imaging?  Assume that I did not change

> >>>>>>> the default telescope slew of 900X.  The log entry I posted is from a

> >>>>>>> session that used DeviceHub with "Delay before starting dome slew

> >>>>>>> check"

> >>>>>>> set to 30 seconds and "Settle time after dome stops slewing" set to 10

> >>>>>>> seconds.  You can see that the time between the start of the telescope

> >>>>>>> slew and the the start of imaging is about 12 seconds.  So, clearly, I

> >>>>>>> am not understanding how these two parameters work.

> >>>>>>>

> >>>>>>> Thank you - Shane

> >>>>>>>

> >>>>>>>

> >>>>>>> On 2/27/2021 2:16 PM, Ray Gralak wrote:

> >>>>>>>> Shane,

> >>>>>>>>

> >>>>>>>>>> APPM's "Active mode" sends the telescope's destination

> >>>>>>>>>> coordinates to the dome ASCOM driver. In this

> >>>>>>>>> case, it is the responsibility of the driver or intermediate

> >>>>>>>>>> application to translate the RA/Dec coordinates to the

> >>>>>>>>>> appropriate dome position.

> >>>>>>>>> Hmmm, so how does that work?  What part of the ASCOM dome API

> >>>>>>>>> would that

> >>>>>>>>> be?

> >>>>>>>>> <https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

> >>>>>>>>>

> >>>>>>>> Again, APPM does not do dome calculations (nor is there a plan for

> >>>>>>>> it to do that). IMO, the ASCOM Dome API

> >>>>>>> is missing a way to send scope Ra/Dec/pierside to the Dome driver.

> >>>>>>> ASCOM makes such a big deal about

> >>>>>>> abstracting away telescope applications from the hardware, but the

> >>>>>>> incomplete Dome API pretty much forces

> >>>>>>> the use of a third-party application.

> >>>>>>>> I think each dome manufacturer should each create their own drivers

> >>>>>>>> that should take into account the

> >>>>>>> telescope and mount dimensions. It would have made life much easier

> >>>>>>> for each application developer that has

> >>>>>>> had to implement dome coordinate transformations in their applications.

> >>>>>>>>>      > In "Passive mode" APPM waits for the dome to finish slewing by

> >>>>>>>>> polling the dome's driver (or intermediate application).

> >>>>>>>>>

> >>>>>>>>> That is exactly what I expected.  What should I set the two passive

> >>>>>>>>> values to to ensure that the imaging doesn't start for, say, 1 minute

> >>>>>>>>> after the scope stops slewing?  Or am I not understanding the

> >>>>>>>>> meaning of

> >>>>>>>>> those two fields and their documentation in the manual?

> >>>>>>>> To use passive mode the dome driver or application must be slaved

> >>>>>>>> to the telescope. In this case APPM just

> >>>>>>> polls the slewing state until dome slewing stops. If slaving can't

> >>>>>>> be done, there is an option in APPM to pause

> >>>>>>> after each point, which would allow you to position the dome opening.

> >>>>>>>>> The total time between the start of the point's processing and

> >>>>>>>>> start of

> >>>>>>>>> it's imaging is about 12 seconds.  Shouldn't that be at least 40

> >>>>>>>>> seconds

> >>>>>>>>> to allow the dome delay and settle times to happen?  What am I

> >>>>>>>>> misunderstanding?.

> >>>>>>>> There are no dome messages in your post so I can't tell you what

> >>>>>>>> happened. Are you sure that you had

> >>>>>>> APPM connected to your Dome application?

> >>>>>>>> BTW, the problem might be that you are using the ASCOM Device Hub

> >>>>>>>> instead of the older POTH dome

> >>>>>>> handling. The behavior is dome behavior is different in Device Hub,

> >>>>>>> and it sounds like the author left out some

> >>>>>>> old functionality.

> >>>>>>>> -Ray

> >>>>>>>>

> >>>>>>>>> -----Original Message-----

> >>>>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On

> >>>>>>>>> Behalf Of Shane Ramotowski

> >>>>>>>>> Sent: Saturday, February 27, 2021 11:32 AM

> >>>>>>>>> To: main@ap-gto.groups.io

> >>>>>>>>> Subject: Re: [ap-gto] APPM with Dome Questions

> >>>>>>>>>

> >>>>>>>>> Ray, thanks for the reply, but I don't really see anything that

> >>>>>>>>> will help.

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>>> APPM's "Active mode" sends the telescope's destination

> >>>>>>>>>> coordinates to the dome ASCOM driver. In this

> >>>>>>>>> case, it is the responsibility of the driver or intermediate

> >>>>>>>>>> application to translate the RA/Dec coordinates to the

> >>>>>>>>>> appropriate dome position.

> >>>>>>>>> Hmmm, so how does that work?  What part of the ASCOM dome API

> >>>>>>>>> would that

> >>>>>>>>> be?

> >>>>>>>>> <https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>> I am definitely returning false fort the CanSlave and Slaved

> >>>>>>>>> properties,

> >>>>>>>>> since there is no hardware-based slaving capability in the dome

> >>>>>>>>> controller.  And I don't see way to "send the telescope's destination

> >>>>>>>>> coordinates" to the ASCOM driver.

> >>>>>>>>>

> >>>>>>>>> The call that the ASCOM driver receives from APPM is

> >>>>>>>>> "SlewToAzimuth()"

> >>>>>>>>> but I think you are basing that azimuth on the center of the dome

> >>>>>>>>> rather

> >>>>>>>>> than the position of the telescope, which can be significantly

> >>>>>>>>> different--consider the initial slew to zenith in which the RA axis

> >>>>>>>>> rotates west and level and the DEC axis point strait up. The

> >>>>>>>>> telescope

> >>>>>>>>> is several inches West of the center of the mount.  From what I

> >>>>>>>>> understand, if you are going to use SlewToAzimuth(), you need to

> >>>>>>>>> consider this.

> >>>>>>>>>

> >>>>>>>>> If you look at ASCOM's DeviceHub, written by Rick and Pete, who

> >>>>>>>>> answer

> >>>>>>>>> most of the dome-related questions posted to the ASCOM Driver and

> >>>>>>>>> Application Development Support Forum, it has a whole section for

> >>>>>>>>> dome

> >>>>>>>>> and mount geometry in it's setup section to allow slaving.

> >>>>>>>>>

> >>>>>>>>>      > In "Passive mode" APPM waits for the dome to finish slewing by

> >>>>>>>>> polling the dome's driver (or intermediate application).

> >>>>>>>>>

> >>>>>>>>> That is exactly what I expected.  What should I set the two passive

> >>>>>>>>> values to to ensure that the imaging doesn't start for, say, 1 minute

> >>>>>>>>> after the scope stops slewing?  Or am I not understanding the

> >>>>>>>>> meaning of

> >>>>>>>>> those two fields and their documentation in the manual?

> >>>>>>>>>

> >>>>>>>>> Here is a log excerpt from one of my attempts last night. Under

> >>>>>>>>> Settings->Dome Settings, Passive is selected, "Delay before starting

> >>>>>>>>> dome slew checking" is set to 30 seconds and "Settle time after dome

> >>>>>>>>> stops slewing" is set to 10 seconds.

> >>>>>>>>>

> >>>>>>>>> 0467221 2021-02-26 20:46:21.965:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=SlewNext

> >>>>>>>>> 0467222 2021-02-26 20:46:22.103:       Info, SlewNext, Starting

> >>>>>>>>> Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10°

> >>>>>>>>> 00'

> >>>>>>>>> 00.0")

> >>>>>>>>> 0467223 2021-02-26 20:46:22.105:       Info,       Slew Next,

> >>>>>>>>> East=True,

> >>>>>>>>> Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0

> >>>>>>>>> 0467224 2021-02-26 20:46:22.105:       Info, Meridian, Setting

> >>>>>>>>> Meridian Delay to -0.25 (-00h 15m 00.00s)

> >>>>>>>>> 0467225 2021-02-26 20:46:22.144:       Info, SlewAsync, Begin

> >>>>>>>>> UnSAFE Slew to RA/Dec:   8.501824 / -10.000000 ( 08h 30m 06.56s /

> >>>>>>>>> -10°

> >>>>>>>>> 00' 00.0")

> >>>>>>>>> 0467226 2021-02-26 20:46:22.215:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=PreSlewing

> >>>>>>>>> 0467227 2021-02-26 20:46:25.482:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=Slewing

> >>>>>>>>> 0467228 2021-02-26 20:46:30.722:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=StartSettle

> >>>>>>>>> 0467229 2021-02-26 20:46:30.741:       Info, StartSettle, Starting

> >>>>>>>>> Settle wait time

> >>>>>>>>> 0467230 2021-02-26 20:46:30.970:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=WaitSettle

> >>>>>>>>> 0467231 2021-02-26 20:46:32.974:       Info, WaitSettle, Settling

> >>>>>>>>> Time Complete

> >>>>>>>>> 0467232 2021-02-26 20:46:33.022:       Info, WaitSettle, Finished

> >>>>>>>>> Slew to Point 3

> >>>>>>>>> 0467233 2021-02-26 20:46:33.022:       Info, WaitSettle, RA/Dec:

> >>>>>>>>> 8.501833 / -10.000000 ( 08h 30m 06.60s /  -10° 00' 00.0")

> >>>>>>>>> 0467234 2021-02-26 20:46:33.022:       Info, WaitSettle, HA/Dec:

> >>>>>>>>> -1.329942 / -10.000000 (-01h 19m 47.79s /  -10° 00' 00.0")

> >>>>>>>>> 0467235 2021-02-26 20:46:33.226:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=StartImage

> >>>>>>>>> 0467236 2021-02-26 20:46:33.260:       Info,   State Machine,

> >>>>>>>>> Starting

> >>>>>>>>> Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)

> >>>>>>>>> 0467237 2021-02-26 20:46:33.260:       Info,   State Machine, LST mid

> >>>>>>>>> image=7.1727475 (07h 10m 21.89s)

> >>>>>>>>> 0467238 2021-02-26 20:46:33.260:       Info, StartTakeImage, Sequence

> >>>>>>>>> Generator Pro: Binning=1, Subframe Type: 0, Duration=5,

> >>>>>>>>> IsDarkFrame=False

> >>>>>>>>>

> >>>>>>>>> The total time between the start of the point's processing and

> >>>>>>>>> start of

> >>>>>>>>> it's imaging is about 12 seconds.  Shouldn't that be at least 40

> >>>>>>>>> seconds

> >>>>>>>>> to allow the dome delay and settle times to happen?  What am I

> >>>>>>>>> misunderstanding?

> >>>>>>>>>

> >>>>>>>>> The dome controller and ASCOM driver do handle Slewing property

> >>>>>>>>> correctly, returning TRUE from the time that the slewToAzimuth() is

> >>>>>>>>> issued until the dome is stopped at the requested position, then

> >>>>>>>>> returning FALSE until the next slew is issued  Sometimes,

> >>>>>>>>> DeviceHub or

> >>>>>>>>> SGP will end up issuing more than one slew to get the dome to the

> >>>>>>>>> final

> >>>>>>>>> position.  The slaving software notices that the telescope has

> >>>>>>>>> moved and

> >>>>>>>>> starts an azimuth slew to where is while the telescope is still

> >>>>>>>>> moving.

> >>>>>>>>> Once the dome arrives at that position, another azimuth slew to

> >>>>>>>>> get to

> >>>>>>>>> where the telescope finally stopped.  Last night, the longest time

> >>>>>>>>> that

> >>>>>>>>> such multiple slews took was about 20 seconds.  That is why I set the

> >>>>>>>>> "Delay before starting dome slew checking" to 30 seconds. I though

> >>>>>>>>> that

> >>>>>>>>> would make APPM not even check for a dome slew until the dome was in

> >>>>>>>>> place and had stopped moving.  Instead, it seemed to have made no

> >>>>>>>>> difference: the imaging started almost as soon as the telescope

> >>>>>>>>> arrived

> >>>>>>>>> at its position.

> >>>>>>>>>

> >>>>>>>>> Thanks - Shane

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>> On 2/27/2021 10:06 AM, Ray Gralak wrote:

> >>>>>>>>>> Hi Shane,

> >>>>>>>>>>

> >>>>>>>>>> APPM's "Active mode" sends the telescope's destination

> >>>>>>>>>> coordinates to the dome ASCOM driver. In this

> >>>>>>>>> case, it is the responsibility of the driver or intermediate

> >>>>>>>>> application to translate the RA/Dec coordinates to

> >>>>>>> the

> >>>>>>>>> appropriate dome position.

> >>>>>>>>>> In "Passive mode" APPM waits for the dome to finish slewing by

> >>>>>>>>>> polling the dome's driver (or intermediate

> >>>>>>>>> application).

> >>>>>>>>>> So, it seems that your dome's ascom driver (or intermediate

> >>>>>>>>>> application) may not be correctly indicating

> >>>>>>> when

> >>>>>>>>> the dome is slewing.

> >>>>>>>>>> -Ray

> >>>>>>>>>>

> >>>>>>>>>>> -----Original Message-----

> >>>>>>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On

> >>>>>>>>>>> Behalf Of Shane Ramotowski

> >>>>>>>>>>> Sent: Friday, February 26, 2021 9:19 PM

> >>>>>>>>>>> To: main@ap-gto.groups.io

> >>>>>>>>>>> Subject: [ap-gto] APPM with Dome Questions

> >>>>>>>>>>>

> >>>>>>>>>>> Hi gang,

> >>>>>>>>>>>

> >>>>>>>>>>> I am the proud owner of a brand new (well 2 weeks) Mach2 and

> >>>>>>>>>>> tried to do

> >>>>>>>>>>> my first APPM model tonight.  I'm having problems with the dome

> >>>>>>>>>>> control

> >>>>>>>>>>> and hope someone can point in the right direction.

> >>>>>>>>>>>

> >>>>>>>>>>> My observatory is a ClearSkys (I don't think they are around

> >>>>>>>>>>> anymore) 8

> >>>>>>>>>>> ft dome.  The pier is centered and the bottom of the mount is

> >>>>>>>>>>> just about

> >>>>>>>>>>> even with the bottom of the dome.  The rotation control is

> >>>>>>>>>>> homemade (my

> >>>>>>>>>>> COVID quarantine project) and works very will with both ASCOM

> >>>>>>>>>>> DeviceHub

> >>>>>>>>>>> and SGP.  I'm using SGP for image capture and plate solve.

> >>>>>>>>>>>

> >>>>>>>>>>> I can't figure out how to set up APPM to control the dome

> >>>>>>>>>>> properly. If I

> >>>>>>>>>>> use "Active" in the "AP Point Mapper - Dome Settings" panel,

> >>>>>>>>>>> APPM seems

> >>>>>>>>>>> to do it's calculations based on the center of the dome instead

> >>>>>>>>>>> of where

> >>>>>>>>>>> the telescope is.  This is not surprising since I can't seem to

> >>>>>>>>>>> find any

> >>>>>>>>>>> where in the program or the documentation to set the mount and

> >>>>>>>>>>> telescope

> >>>>>>>>>>> geometry.  I suppose, since APCC knows that I'm using a Mach2, it

> >>>>>>>>>>> _could_ already know roughly how far from the center of the

> >>>>>>>>>>> RA/DEC axes

> >>>>>>>>>>> intersection the bottom of my telescope is.  But I don't see

> >>>>>>>>>>> anyway that

> >>>>>>>>>>> it could know where the center of my OTA is.  I really don't

> >>>>>>>>>>> think it's

> >>>>>>>>>>> using the parameters from 3D view; I haven't set that up, but the

> >>>>>>>>>>> default is a much larger diameter telescope than mine.

> >>>>>>>>>>>

> >>>>>>>>>>>        Anyway, when I use "Active", I end up imaging across the

> >>>>>>>>>>> edge of the

> >>>>>>>>>>> slot because the slot is positioned for the center of the mount

> >>>>>>>>>>> instead

> >>>>>>>>>>> of where the telescope is.  Most of the images ended up plate

> >>>>>>>>>>> solving

> >>>>>>>>>>> anyway, but since  the stars are all diffraction spikes, I don't

> >>>>>>>>>>> know

> >>>>>>>>>>> the quality of those solutions.  The initial slew to meridian is

> >>>>>>>>>>> probably the worst because the dome is in the exact opposite

> >>>>>>>>>>> position

> >>>>>>>>>>> than it should be and my slot just goes barely past vertical.   I

> >>>>>>>>>>> checked the ASCOM logs on the PC and my ASCOM debug screen on

> >>>>>>>>>>> the dome

> >>>>>>>>>>> controller.  The dome _is_ slewing to the position that APPM

> >>>>>>>>>>> requests;

> >>>>>>>>>>> that position just doesn't seem to be based on where the

> >>>>>>>>>>> telescope is.

> >>>>>>>>>>>

> >>>>>>>>>>> Can anyone tell me what I'm missing?  Where do I enter the

> >>>>>>>>>>> offsets for

> >>>>>>>>>>> the mount/scope geometer so that APPM can got to the correct

> >>>>>>>>>>> position?

> >>>>>>>>>>>

> >>>>>>>>>>> So, after trying "Active", I swiched to "Passive" and tried with

> >>>>>>>>>>> two

> >>>>>>>>>>> different dome slaving programs: ASCOM Device Hub and SGP.  For

> >>>>>>>>>>> "Delay

> >>>>>>>>>>> before starting dome slew checking", I used values ranging from

> >>>>>>>>>>> 5 to 30

> >>>>>>>>>>> seconds.  For "Settle time after dome stops slewing", I used

> >>>>>>>>>>> values from

> >>>>>>>>>>> 1 to 20 seconds.  I didn't see any effect when changing these

> >>>>>>>>>>> settings;

> >>>>>>>>>>> in all cases the the telescope slewed to the next position and

> >>>>>>>>>>> started

> >>>>>>>>>>> imaging a few seconds after it got there--many seconds before

> >>>>>>>>>>> the dome

> >>>>>>>>>>> was in position.  None of those images solved since the dome was

> >>>>>>>>>>> in the

> >>>>>>>>>>> way.  Again, I can't figure out what I'm doing wrong--it's like

> >>>>>>>>>>> I'm not

> >>>>>>>>>>> even changing the values.  Is there another setting that I'm

> >>>>>>>>>>> missing

> >>>>>>>>>>> that enables these timeouts?

> >>>>>>>>>>>

> >>>>>>>>>>> I'm sure someone else has successfully done an APPM run from an

> >>>>>>>>>>> automated dome!  What am I missing?

> >>>>>>>>>>>

> >>>>>>>>>>> Thanks - Shane

> >>>>>>>>>>>

> >>>>>>>>>>> --

> >>>>>>>>>>> Shane Ramotowski

> >>>>>>>>>>> kor@...

> >>>>>>>>>>> https://www.kor-astro.net

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>> --

> >>>>>>>>> Shane Ramotowski

> >>>>>>>>> kor@...

> >>>>>>>>> https://www.kor-astro.net

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>> --

> >>>>>>> Shane Ramotowski

> >>>>>>> kor@...

> >>>>>>> https://www.kor-astro.net

> >>>>>>>

> >>>>>>>

> >>>>>>>

> >>>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>> --

> >>>> Shane Ramotowski

> >>>> kor@...

> >>>> https://www.kor-astro.net

> >>>>

> >>>>

> >>>>

> >>>>

> >>>

> >>>

> >>>

> >>>

> >>>

> >>>

> >>>

> >> --

> >> Shane Ramotowski

> >> kor@...

> >> https://www.kor-astro.net

> >>

> >>

> >>

> >>

> >

> >

> >

> >

> >

> >

> >

> >

>

> --

> Shane Ramotowski

> kor@...

> https://www.kor-astro.net

>

>

>

>

 


Ray Gralak
 

> And yet, in Active mode, for

> most of the sample points, the dome ends up covering more than half of

> the telescopes view, so I need to use Passive mode. 

 

Shane,

 

Ø  Maybe I really am doing something totally wrong

 

One other possibility… are you using the point ordering strategy for Dome setups? See this screenshot:

 

 

-Ray

 

> -----Original Message-----

> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski

> Sent: Sunday, February 28, 2021 7:06 PM

> To: main@ap-gto.groups.io

> Subject: Re: [ap-gto] APPM with Dome Questions

>

> Not personally, but I would think that anyone using a rotational dome

> would need some way to position it so that the telescope is not blocked

> by the slot.  Since the "Active" mode doesn't do the geometry, unless

> you have a very wide slot that goes significantly past vertical,

> "Passive" is really the only option.  I was unable to test POTH, as you

> suggested, since it is depricated, no longer part of the ASCOM 6.5SP1

> distribution, and I could not find a download of it from a reliable

> source.  I would expect, however, that it would have a similar issue,

> either needing to know where the telescope is slewing to or slewing the

> dome by polling the telescope's position periodically.  SGP has slaving

> that works well and has a minimum polling frequency of 1 seconds.  But

> it was made with the intention of some other application connecting to

> SGP to query the dome slewing state.  I don't know of any other solution

> than DeviceHub if you are running up-to-date ASCOM.

>

> Of course if you have a roll-off, open clam shell, or are just outside,

> you don't need any dome support all!

>

> I'm guessing, based on my serial number, that there are a little over

> 120 Mach2's out there that came with APPM.  I don't know how many copies

> of APPM are being used by 1100 and 1600 users, nor how many of those

> users along with other Mach2 owners have rotational domes (I think

> roll-offs are much more popular), but I am a bit surprised that this has

> not been brought up before.  The Mach2 is fairly compact and I am using

> a 4" refractor, so my geometry ought to be about as optimal as it gets.

> The slot in my dome looks to be a similar proportion to other domes I've

> seen; it is by no means overly narrow.  And yet, in Active mode, for

> most of the sample points, the dome ends up covering more than half of

> the telescopes view, so I need to use Passive mode.  Maybe I really am

> doing something totally wrong and stupid, but I sure don't know what

> that would be...

>

> - Shane

>

> On 2/28/2021 7:19 PM, Ray Gralak wrote:

> > Shane,

> >

> >> As far as the APPM specific commands, could you allow a connection to

> >> DeviceHub to send the info necessary for the slew and then send the

> >> "special sauce" directly to the AP V2 driver?

> > I would have to bring this up with Marj to see if this is something A-P would want to have implemented and

> supported. Are you aware of any others that  would want this feature?

> >

> > -Ray

> >

> >> -----Original Message-----

> >> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski

> >> Sent: Sunday, February 28, 2021 4:29 PM

> >> To: main@ap-gto.groups.io

> >> Subject: Re: [ap-gto] APPM with Dome Questions

> >>

> >> When using DeviceHub, if you are connected to both DeviceHub's telescope

> >> and dome drivers, then when you issue a telescope slew, DeviceHub knows

> >> the target RA and DEC and can start a dome slew to the azimuth that the

> >> telescope will end at.

> >>

> >> If you cannot connect to the DeviceHub telescope and/or dome, then

> >> DeviceHub uses a polling scheme to ask where the telescope is and then

> >> send the dome to the correct azimuth.  The polling period,

> >> unfortunately, seems to have a minimum of 5 seconds.  So, during an APPM

> >> run, APPM will tell the telescope to slew.  Sometime less than 5 seconds

> >> later, DeviceHub will retrieve the current RA/DEC from the telescope and

> >> start the dome slewing to that position.  For longer slews, the

> >> telescope may still be moving.  5 seconds after the dome arrives at the

> >> indicated position, it finds that the telescope has moved again (in

> >> acutality, the telescope never stopped moving, simply completing its

> >> original slew.  So DeviceHub issues a second slew to get to the final

> >> position.

> >>

> >> So for the Passive settings in APPM, I have to use timeouts long enough

> >> to account for 2 polling periods plus 2 slew times to ensure that the

> >> dome is really in position before imaging starts.  I can't let APPM

> >> catch the dome in a stopped state between two dome slews. I hope that

> >> makes sense.

> >>

> >> I ran a large model last night using DeviceHub.  I lost 5 points in

> >> total, which isn't that bad.  Three of them were because of the

> >> bodaciously bright almost full moon and the other two were bad luck in

> >> the timing of long slews from the end of on string of points to the

> >> start of the next.  I was concerned that DeviceHub would not position

> >> properly for the counterweight-up points, but it did so correctly.  The

> >> model run took a lot longer than I expected since I was waiting 40

> >> seconds (usually unnecessarily) for each point to give the dome time to

> >> get into position in case it was a long slew.

> >>

> >> I really don't know if supporting DeviceHub's telescope driver will

> >> work.   I'm assuming that if the SideOfPier property is set correctly

> >> when the slew is issued, DeviceHub will go to the correct location even

> >> if it ends up counterweight-up.  But I haven't tested that and I really

> >> don't know how--well I guess I could write a little program to do that.

> >> I will do so if you are considering adding such support and the results

> >> of that test would help.

> >>

> >> As far as the APPM specific commands, could you allow a connection to

> >> DeviceHub to send the info necessary for the slew and then send the

> >> "special sauce" directly to the AP V2 driver?

> >>

> >> - Shane

> >>

> >> On 2/28/2021 8:10 AM, Ray Gralak wrote:

> >>> Hi Shane,

> >>>

> >>>> One more question, Ray:  In APPM, is there a way to connect to the

> >>>> DeviceHub telescope or is it locked to the AP ASCOM driver?

> >>> You would not want to connect APPM to the DeviceHub telescope. APPM uses some commands that the

> >> DeviceHub would not be able to pass through to the AP V2 driver.

> >>> That said, what is the use case for this?

> >>>

> >>> -Ray

> >>>

> >>>> -----Original Message-----

> >>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski

> >>>> Sent: Sunday, February 28, 2021 3:52 AM

> >>>> To: main@ap-gto.groups.io

> >>>> Subject: Re: [ap-gto] APPM with Dome Questions

> >>>>

> >>>> One more question, Ray:  In APPM, is there a way to connect to the

> >>>> DeviceHub telescope or is it locked to the AP ASCOM driver?

> >>>>

> >>>> Thanks - Shane

> >>>>

> >>>> On 2/27/2021 8:09 PM, Shane Ramotowski wrote:

> >>>>> Ahh, I think it understand.  I use DeviceHub to do the slaving, but

> >>>>> still connect to the DeviceHub dome with APPM.   I will try that and

> >>>>> see what happens.

> >>>>>

> >>>>> Thanks - Shane

> >>>>>

> >>>>> On 2/27/2021 5:27 PM, Ray Gralak wrote:

> >>>>>> Shane,

> >>>>>>

> >>>>>>> OK.  I'll wait for the ASCOM folks to add the APIs that you want before

> >>>>>>> I try to use "Active" mode again.

> >>>>>> I think you misunderstood. ASCOM is not planning to add those APIs.

> >>>>>>

> >>>>>>> For the second part of my reply, I guess I did not make it clear enough

> >>>>>>> that I was using DeviceHub not allowing APPM to connect to the dome,

> >>>>>>> since APPM cannot send the dome to the correct position an DeviceHub

> >>>>>>> can. _I am simply trying to understand what I'm doing wrong when

> >>>>>>> setting

> >>>>>>> up "Passive" parameters in the "Dome Settings" box.__

> >>>>>> In passive mode, APPM only needs to poll the Dome's slewing state to

> >>>>>> work. If you can't do that then APPM won't be able to tell when the

> >>>>>> dome is done slewing.

> >>>>>>

> >>>>>> If Device Hub won't let APPM connect to the Dome driver you can use

> >>>>>> the older ASCOM POTH application, which allows multiple applications

> >>>>>> to connect to an ASCOM driver.

> >>>>>>

> >>>>>>> So can you please tell me what settings I can use for "Delay before

> >>>>>>> staring dome slew check" and "Settle time after dome stops slewing" to

> >>>>>>> ensure that I end up with at least 30 seconds between the end of the

> >>>>>>> telescope slew and the start of imaging?

> >>>>>> First, the two parameters only have meaning when you are connected to

> >>>>>> a Dome driver. If you are not connected they won't be used.

> >>>>>>

> >>>>>> "Delay before starting dome slew checking"

> >>>>>>

> >>>>>> The number of seconds before APPM will start checking the dome

> >>>>>> driver's slew state. This delay allows the dome driver time to

> >>>>>> initiate dome movement that will be reflected by reading "True" from

> >>>>>> the Dome driver's "Slewing" property. If the value is False when

> >>>>>> read, then dome slewing will be considered completed.

> >>>>>>

> >>>>>> "Settle time after dome stops slewing"

> >>>>>>

> >>>>>> The number of seconds to delay slew completion after the Dome

> >>>>>> driver's "Slewing" property reads "False".

> >>>>>>

> >>>>>> -Ray

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>> -----Original Message-----

> >>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf

> >>>>>>> Of Shane Ramotowski

> >>>>>>> Sent: Saturday, February 27, 2021 2:16 PM

> >>>>>>> To: main@ap-gto.groups.io

> >>>>>>> Subject: Re: [ap-gto] APPM with Dome Questions

> >>>>>>>

> >>>>>>> OK.  I'll wait for the ASCOM folks to add the APIs that you want before

> >>>>>>> I try to use "Active" mode again.

> >>>>>>>

> >>>>>>> For the second part of my reply, I guess I did not make it clear enough

> >>>>>>> that I was using DeviceHub not allowing APPM to connect to the dome,

> >>>>>>> since APPM cannot send the dome to the correct position an DeviceHub

> >>>>>>> can. _I am simply trying to understand what I'm doing wrong when

> >>>>>>> setting

> >>>>>>> up "Passive" parameters in the "Dome Settings" box.__

> >>>>>>> _

> >>>>>>> So can you please tell me what settings I can use for "Delay before

> >>>>>>> staring dome slew check" and "Settle time after dome stops slewing" to

> >>>>>>> ensure that I end up with at least 30 seconds between the end of the

> >>>>>>> telescope slew and the start of imaging?  Assume that I did not change

> >>>>>>> the default telescope slew of 900X.  The log entry I posted is from a

> >>>>>>> session that used DeviceHub with "Delay before starting dome slew

> >>>>>>> check"

> >>>>>>> set to 30 seconds and "Settle time after dome stops slewing" set to 10

> >>>>>>> seconds.  You can see that the time between the start of the telescope

> >>>>>>> slew and the the start of imaging is about 12 seconds.  So, clearly, I

> >>>>>>> am not understanding how these two parameters work.

> >>>>>>>

> >>>>>>> Thank you - Shane

> >>>>>>>

> >>>>>>>

> >>>>>>> On 2/27/2021 2:16 PM, Ray Gralak wrote:

> >>>>>>>> Shane,

> >>>>>>>>

> >>>>>>>>>> APPM's "Active mode" sends the telescope's destination

> >>>>>>>>>> coordinates to the dome ASCOM driver. In this

> >>>>>>>>> case, it is the responsibility of the driver or intermediate

> >>>>>>>>>> application to translate the RA/Dec coordinates to the

> >>>>>>>>>> appropriate dome position.

> >>>>>>>>> Hmmm, so how does that work?  What part of the ASCOM dome API

> >>>>>>>>> would that

> >>>>>>>>> be?

> >>>>>>>>> <https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

> >>>>>>>>>

> >>>>>>>> Again, APPM does not do dome calculations (nor is there a plan for

> >>>>>>>> it to do that). IMO, the ASCOM Dome API

> >>>>>>> is missing a way to send scope Ra/Dec/pierside to the Dome driver.

> >>>>>>> ASCOM makes such a big deal about

> >>>>>>> abstracting away telescope applications from the hardware, but the

> >>>>>>> incomplete Dome API pretty much forces

> >>>>>>> the use of a third-party application.

> >>>>>>>> I think each dome manufacturer should each create their own drivers

> >>>>>>>> that should take into account the

> >>>>>>> telescope and mount dimensions. It would have made life much easier

> >>>>>>> for each application developer that has

> >>>>>>> had to implement dome coordinate transformations in their applications.

> >>>>>>>>>      > In "Passive mode" APPM waits for the dome to finish slewing by

> >>>>>>>>> polling the dome's driver (or intermediate application).

> >>>>>>>>>

> >>>>>>>>> That is exactly what I expected.  What should I set the two passive

> >>>>>>>>> values to to ensure that the imaging doesn't start for, say, 1 minute

> >>>>>>>>> after the scope stops slewing?  Or am I not understanding the

> >>>>>>>>> meaning of

> >>>>>>>>> those two fields and their documentation in the manual?

> >>>>>>>> To use passive mode the dome driver or application must be slaved

> >>>>>>>> to the telescope. In this case APPM just

> >>>>>>> polls the slewing state until dome slewing stops. If slaving can't

> >>>>>>> be done, there is an option in APPM to pause

> >>>>>>> after each point, which would allow you to position the dome opening.

> >>>>>>>>> The total time between the start of the point's processing and

> >>>>>>>>> start of

> >>>>>>>>> it's imaging is about 12 seconds.  Shouldn't that be at least 40

> >>>>>>>>> seconds

> >>>>>>>>> to allow the dome delay and settle times to happen?  What am I

> >>>>>>>>> misunderstanding?.

> >>>>>>>> There are no dome messages in your post so I can't tell you what

> >>>>>>>> happened. Are you sure that you had

> >>>>>>> APPM connected to your Dome application?

> >>>>>>>> BTW, the problem might be that you are using the ASCOM Device Hub

> >>>>>>>> instead of the older POTH dome

> >>>>>>> handling. The behavior is dome behavior is different in Device Hub,

> >>>>>>> and it sounds like the author left out some

> >>>>>>> old functionality.

> >>>>>>>> -Ray

> >>>>>>>>

> >>>>>>>>> -----Original Message-----

> >>>>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On

> >>>>>>>>> Behalf Of Shane Ramotowski

> >>>>>>>>> Sent: Saturday, February 27, 2021 11:32 AM

> >>>>>>>>> To: main@ap-gto.groups.io

> >>>>>>>>> Subject: Re: [ap-gto] APPM with Dome Questions

> >>>>>>>>>

> >>>>>>>>> Ray, thanks for the reply, but I don't really see anything that

> >>>>>>>>> will help.

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>>> APPM's "Active mode" sends the telescope's destination

> >>>>>>>>>> coordinates to the dome ASCOM driver. In this

> >>>>>>>>> case, it is the responsibility of the driver or intermediate

> >>>>>>>>>> application to translate the RA/Dec coordinates to the

> >>>>>>>>>> appropriate dome position.

> >>>>>>>>> Hmmm, so how does that work?  What part of the ASCOM dome API

> >>>>>>>>> would that

> >>>>>>>>> be?

> >>>>>>>>> <https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>> I am definitely returning false fort the CanSlave and Slaved

> >>>>>>>>> properties,

> >>>>>>>>> since there is no hardware-based slaving capability in the dome

> >>>>>>>>> controller.  And I don't see way to "send the telescope's destination

> >>>>>>>>> coordinates" to the ASCOM driver.

> >>>>>>>>>

> >>>>>>>>> The call that the ASCOM driver receives from APPM is

> >>>>>>>>> "SlewToAzimuth()"

> >>>>>>>>> but I think you are basing that azimuth on the center of the dome

> >>>>>>>>> rather

> >>>>>>>>> than the position of the telescope, which can be significantly

> >>>>>>>>> different--consider the initial slew to zenith in which the RA axis

> >>>>>>>>> rotates west and level and the DEC axis point strait up. The

> >>>>>>>>> telescope

> >>>>>>>>> is several inches West of the center of the mount.  From what I

> >>>>>>>>> understand, if you are going to use SlewToAzimuth(), you need to

> >>>>>>>>> consider this.

> >>>>>>>>>

> >>>>>>>>> If you look at ASCOM's DeviceHub, written by Rick and Pete, who

> >>>>>>>>> answer

> >>>>>>>>> most of the dome-related questions posted to the ASCOM Driver and

> >>>>>>>>> Application Development Support Forum, it has a whole section for

> >>>>>>>>> dome

> >>>>>>>>> and mount geometry in it's setup section to allow slaving.

> >>>>>>>>>

> >>>>>>>>>      > In "Passive mode" APPM waits for the dome to finish slewing by

> >>>>>>>>> polling the dome's driver (or intermediate application).

> >>>>>>>>>

> >>>>>>>>> That is exactly what I expected.  What should I set the two passive

> >>>>>>>>> values to to ensure that the imaging doesn't start for, say, 1 minute

> >>>>>>>>> after the scope stops slewing?  Or am I not understanding the

> >>>>>>>>> meaning of

> >>>>>>>>> those two fields and their documentation in the manual?

> >>>>>>>>>

> >>>>>>>>> Here is a log excerpt from one of my attempts last night. Under

> >>>>>>>>> Settings->Dome Settings, Passive is selected, "Delay before starting

> >>>>>>>>> dome slew checking" is set to 30 seconds and "Settle time after dome

> >>>>>>>>> stops slewing" is set to 10 seconds.

> >>>>>>>>>

> >>>>>>>>> 0467221 2021-02-26 20:46:21.965:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=SlewNext

> >>>>>>>>> 0467222 2021-02-26 20:46:22.103:       Info, SlewNext, Starting

> >>>>>>>>> Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10°

> >>>>>>>>> 00'

> >>>>>>>>> 00.0")

> >>>>>>>>> 0467223 2021-02-26 20:46:22.105:       Info,       Slew Next,

> >>>>>>>>> East=True,

> >>>>>>>>> Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0

> >>>>>>>>> 0467224 2021-02-26 20:46:22.105:       Info, Meridian, Setting

> >>>>>>>>> Meridian Delay to -0.25 (-00h 15m 00.00s)

> >>>>>>>>> 0467225 2021-02-26 20:46:22.144:       Info, SlewAsync, Begin

> >>>>>>>>> UnSAFE Slew to RA/Dec:   8.501824 / -10.000000 ( 08h 30m 06.56s /

> >>>>>>>>> -10°

> >>>>>>>>> 00' 00.0")

> >>>>>>>>> 0467226 2021-02-26 20:46:22.215:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=PreSlewing

> >>>>>>>>> 0467227 2021-02-26 20:46:25.482:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=Slewing

> >>>>>>>>> 0467228 2021-02-26 20:46:30.722:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=StartSettle

> >>>>>>>>> 0467229 2021-02-26 20:46:30.741:       Info, StartSettle, Starting

> >>>>>>>>> Settle wait time

> >>>>>>>>> 0467230 2021-02-26 20:46:30.970:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=WaitSettle

> >>>>>>>>> 0467231 2021-02-26 20:46:32.974:       Info, WaitSettle, Settling

> >>>>>>>>> Time Complete

> >>>>>>>>> 0467232 2021-02-26 20:46:33.022:       Info, WaitSettle, Finished

> >>>>>>>>> Slew to Point 3

> >>>>>>>>> 0467233 2021-02-26 20:46:33.022:       Info, WaitSettle, RA/Dec:

> >>>>>>>>> 8.501833 / -10.000000 ( 08h 30m 06.60s /  -10° 00' 00.0")

> >>>>>>>>> 0467234 2021-02-26 20:46:33.022:       Info, WaitSettle, HA/Dec:

> >>>>>>>>> -1.329942 / -10.000000 (-01h 19m 47.79s /  -10° 00' 00.0")

> >>>>>>>>> 0467235 2021-02-26 20:46:33.226:       Info,   State Machine,

> >>>>>>>>> Entering

> >>>>>>>>> State=StartImage

> >>>>>>>>> 0467236 2021-02-26 20:46:33.260:       Info,   State Machine,

> >>>>>>>>> Starting

> >>>>>>>>> Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)

> >>>>>>>>> 0467237 2021-02-26 20:46:33.260:       Info,   State Machine, LST mid

> >>>>>>>>> image=7.1727475 (07h 10m 21.89s)

> >>>>>>>>> 0467238 2021-02-26 20:46:33.260:       Info, StartTakeImage, Sequence

> >>>>>>>>> Generator Pro: Binning=1, Subframe Type: 0, Duration=5,

> >>>>>>>>> IsDarkFrame=False

> >>>>>>>>>

> >>>>>>>>> The total time between the start of the point's processing and

> >>>>>>>>> start of

> >>>>>>>>> it's imaging is about 12 seconds.  Shouldn't that be at least 40

> >>>>>>>>> seconds

> >>>>>>>>> to allow the dome delay and settle times to happen?  What am I

> >>>>>>>>> misunderstanding?

> >>>>>>>>>

> >>>>>>>>> The dome controller and ASCOM driver do handle Slewing property

> >>>>>>>>> correctly, returning TRUE from the time that the slewToAzimuth() is

> >>>>>>>>> issued until the dome is stopped at the requested position, then

> >>>>>>>>> returning FALSE until the next slew is issued  Sometimes,

> >>>>>>>>> DeviceHub or

> >>>>>>>>> SGP will end up issuing more than one slew to get the dome to the

> >>>>>>>>> final

> >>>>>>>>> position.  The slaving software notices that the telescope has

> >>>>>>>>> moved and

> >>>>>>>>> starts an azimuth slew to where is while the telescope is still

> >>>>>>>>> moving.

> >>>>>>>>> Once the dome arrives at that position, another azimuth slew to

> >>>>>>>>> get to

> >>>>>>>>> where the telescope finally stopped.  Last night, the longest time

> >>>>>>>>> that

> >>>>>>>>> such multiple slews took was about 20 seconds.  That is why I set the

> >>>>>>>>> "Delay before starting dome slew checking" to 30 seconds. I though

> >>>>>>>>> that

> >>>>>>>>> would make APPM not even check for a dome slew until the dome was in

> >>>>>>>>> place and had stopped moving.  Instead, it seemed to have made no

> >>>>>>>>> difference: the imaging started almost as soon as the telescope

> >>>>>>>>> arrived

> >>>>>>>>> at its position.

> >>>>>>>>>

> >>>>>>>>> Thanks - Shane

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>> On 2/27/2021 10:06 AM, Ray Gralak wrote:

> >>>>>>>>>> Hi Shane,

> >>>>>>>>>>

> >>>>>>>>>> APPM's "Active mode" sends the telescope's destination

> >>>>>>>>>> coordinates to the dome ASCOM driver. In this

> >>>>>>>>> case, it is the responsibility of the driver or intermediate

> >>>>>>>>> application to translate the RA/Dec coordinates to

> >>>>>>> the

> >>>>>>>>> appropriate dome position.

> >>>>>>>>>> In "Passive mode" APPM waits for the dome to finish slewing by

> >>>>>>>>>> polling the dome's driver (or intermediate

> >>>>>>>>> application).

> >>>>>>>>>> So, it seems that your dome's ascom driver (or intermediate

> >>>>>>>>>> application) may not be correctly indicating

> >>>>>>> when

> >>>>>>>>> the dome is slewing.

> >>>>>>>>>> -Ray

> >>>>>>>>>>

> >>>>>>>>>>> -----Original Message-----

> >>>>>>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On

> >>>>>>>>>>> Behalf Of Shane Ramotowski

> >>>>>>>>>>> Sent: Friday, February 26, 2021 9:19 PM

> >>>>>>>>>>> To: main@ap-gto.groups.io

> >>>>>>>>>>> Subject: [ap-gto] APPM with Dome Questions

> >>>>>>>>>>>

> >>>>>>>>>>> Hi gang,

> >>>>>>>>>>>

> >>>>>>>>>>> I am the proud owner of a brand new (well 2 weeks) Mach2 and

> >>>>>>>>>>> tried to do

> >>>>>>>>>>> my first APPM model tonight.  I'm having problems with the dome

> >>>>>>>>>>> control

> >>>>>>>>>>> and hope someone can point in the right direction.

> >>>>>>>>>>>

> >>>>>>>>>>> My observatory is a ClearSkys (I don't think they are around

> >>>>>>>>>>> anymore) 8

> >>>>>>>>>>> ft dome.  The pier is centered and the bottom of the mount is

> >>>>>>>>>>> just about

> >>>>>>>>>>> even with the bottom of the dome.  The rotation control is

> >>>>>>>>>>> homemade (my

> >>>>>>>>>>> COVID quarantine project) and works very will with both ASCOM

> >>>>>>>>>>> DeviceHub

> >>>>>>>>>>> and SGP.  I'm using SGP for image capture and plate solve.

> >>>>>>>>>>>

> >>>>>>>>>>> I can't figure out how to set up APPM to control the dome

> >>>>>>>>>>> properly. If I

> >>>>>>>>>>> use "Active" in the "AP Point Mapper - Dome Settings" panel,

> >>>>>>>>>>> APPM seems

> >>>>>>>>>>> to do it's calculations based on the center of the dome instead

> >>>>>>>>>>> of where

> >>>>>>>>>>> the telescope is.  This is not surprising since I can't seem to

> >>>>>>>>>>> find any

> >>>>>>>>>>> where in the program or the documentation to set the mount and

> >>>>>>>>>>> telescope

> >>>>>>>>>>> geometry.  I suppose, since APCC knows that I'm using a Mach2, it

> >>>>>>>>>>> _could_ already know roughly how far from the center of the

> >>>>>>>>>>> RA/DEC axes

> >>>>>>>>>>> intersection the bottom of my telescope is.  But I don't see

> >>>>>>>>>>> anyway that

> >>>>>>>>>>> it could know where the center of my OTA is.  I really don't

> >>>>>>>>>>> think it's

> >>>>>>>>>>> using the parameters from 3D view; I haven't set that up, but the

> >>>>>>>>>>> default is a much larger diameter telescope than mine.

> >>>>>>>>>>>

> >>>>>>>>>>>        Anyway, when I use "Active", I end up imaging across the

> >>>>>>>>>>> edge of the

> >>>>>>>>>>> slot because the slot is positioned for the center of the mount

> >>>>>>>>>>> instead

> >>>>>>>>>>> of where the telescope is.  Most of the images ended up plate

> >>>>>>>>>>> solving

> >>>>>>>>>>> anyway, but since  the stars are all diffraction spikes, I don't

> >>>>>>>>>>> know

> >>>>>>>>>>> the quality of those solutions.  The initial slew to meridian is

> >>>>>>>>>>> probably the worst because the dome is in the exact opposite

> >>>>>>>>>>> position

> >>>>>>>>>>> than it should be and my slot just goes barely past vertical.   I

> >>>>>>>>>>> checked the ASCOM logs on the PC and my ASCOM debug screen on

> >>>>>>>>>>> the dome

> >>>>>>>>>>> controller.  The dome _is_ slewing to the position that APPM

> >>>>>>>>>>> requests;

> >>>>>>>>>>> that position just doesn't seem to be based on where the

> >>>>>>>>>>> telescope is.

> >>>>>>>>>>>

> >>>>>>>>>>> Can anyone tell me what I'm missing?  Where do I enter the

> >>>>>>>>>>> offsets for

> >>>>>>>>>>> the mount/scope geometer so that APPM can got to the correct

> >>>>>>>>>>> position?

> >>>>>>>>>>>

> >>>>>>>>>>> So, after trying "Active", I swiched to "Passive" and tried with

> >>>>>>>>>>> two

> >>>>>>>>>>> different dome slaving programs: ASCOM Device Hub and SGP.  For

> >>>>>>>>>>> "Delay

> >>>>>>>>>>> before starting dome slew checking", I used values ranging from

> >>>>>>>>>>> 5 to 30

> >>>>>>>>>>> seconds.  For "Settle time after dome stops slewing", I used

> >>>>>>>>>>> values from

> >>>>>>>>>>> 1 to 20 seconds.  I didn't see any effect when changing these

> >>>>>>>>>>> settings;

> >>>>>>>>>>> in all cases the the telescope slewed to the next position and

> >>>>>>>>>>> started

> >>>>>>>>>>> imaging a few seconds after it got there--many seconds before

> >>>>>>>>>>> the dome

> >>>>>>>>>>> was in position.  None of those images solved since the dome was

> >>>>>>>>>>> in the

> >>>>>>>>>>> way.  Again, I can't figure out what I'm doing wrong--it's like

> >>>>>>>>>>> I'm not

> >>>>>>>>>>> even changing the values.  Is there another setting that I'm

> >>>>>>>>>>> missing

> >>>>>>>>>>> that enables these timeouts?

> >>>>>>>>>>>

> >>>>>>>>>>> I'm sure someone else has successfully done an APPM run from an

> >>>>>>>>>>> automated dome!  What am I missing?

> >>>>>>>>>>>

> >>>>>>>>>>> Thanks - Shane

> >>>>>>>>>>>

> >>>>>>>>>>> --

> >>>>>>>>>>> Shane Ramotowski

> >>>>>>>>>>> kor@...

> >>>>>>>>>>> https://www.kor-astro.net

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>> --

> >>>>>>>>> Shane Ramotowski

> >>>>>>>>> kor@...

> >>>>>>>>> https://www.kor-astro.net

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>> --

> >>>>>>> Shane Ramotowski

> >>>>>>> kor@...

> >>>>>>> https://www.kor-astro.net

> >>>>>>>

> >>>>>>>

> >>>>>>>

> >>>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>> --

> >>>> Shane Ramotowski

> >>>> kor@...

> >>>> https://www.kor-astro.net

> >>>>

> >>>>

> >>>>

> >>>>

> >>>

> >>>

> >>>

> >>>

> >>>

> >>>

> >>>

> >> --

> >> Shane Ramotowski

> >> kor@...

> >> https://www.kor-astro.net

> >>

> >>

> >>

> >>

> >

> >

> >

> >

> >

> >

> >

> >

>

> --

> Shane Ramotowski

> kor@...

> https://www.kor-astro.net

>

>

>

>

 


Shane Ramotowski
 

Yes I am.  That seems to minimize the number of the longer slews.

- Shane

On 2/28/2021 8:55 PM, Ray Gralak wrote:

And yet, in Active mode, for
most of the sample points, the dome ends up covering more than half of
the telescopes view, so I need to use Passive mode.
Shane,

ØMaybe I really am doing something totally wrong

One other possibility… are you using the point ordering strategy for Dome setups? See this screenshot:

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of
Shane Ramotowski

Sent: Sunday, February 28, 2021 7:06 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions
Not personally, but I would think that anyone using a rotational dome
would need some way to position it so that the telescope is not blocked
by the slot. Since the "Active" mode doesn't do the geometry, unless
you have a very wide slot that goes significantly past vertical,
"Passive" is really the only option.  I was unable to test POTH, as you
suggested, since it is depricated, no longer part of the ASCOM 6.5SP1
distribution, and I could not find a download of it from a reliable
source.  I would expect, however, that it would have a similar issue,
either needing to know where the telescope is slewing to or slewing the
dome by polling the telescope's position periodically.  SGP has slaving
that works well and has a minimum polling frequency of 1 seconds.  But
it was made with the intention of some other application connecting to
SGP to query the dome slewing state.  I don't know of any other solution
than DeviceHub if you are running up-to-date ASCOM.
Of course if you have a roll-off, open clam shell, or are just outside,
you don't need any dome support all!
I'm guessing, based on my serial number, that there are a little over
120 Mach2's out there that came with APPM.  I don't know how many copies
of APPM are being used by 1100 and 1600 users, nor how many of those
users along with other Mach2 owners have rotational domes (I think
roll-offs are much more popular), but I am a bit surprised that this has
not been brought up before.  The Mach2 is fairly compact and I am using
a 4" refractor, so my geometry ought to be about as optimal as it gets.
The slot in my dome looks to be a similar proportion to other domes I've
seen; it is by no means overly narrow.  And yet, in Active mode, for
most of the sample points, the dome ends up covering more than half of
the telescopes view, so I need to use Passive mode.  Maybe I really am
doing something totally wrong and stupid, but I sure don't know what
that would be...
- Shane
On 2/28/2021 7:19 PM, Ray Gralak wrote:
Shane,
As far as the APPM specific commands, could you allow a connection to
DeviceHub to send the info necessary for the slew and then send the
"special sauce" directly to the AP V2 driver?
I would have to bring this up with Marj to see if this is something A-P would want
to have implemented and

supported. Are you aware of any others thatwould want this feature?
-Ray
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of
Shane Ramotowski

Sent: Sunday, February 28, 2021 4:29 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions
When using DeviceHub, if you are connected to both DeviceHub's telescope
and dome drivers, then when you issue a telescope slew, DeviceHub knows
the target RA and DEC and can start a dome slew to the azimuth that the
telescope will end at.
If you cannot connect to the DeviceHub telescope and/or dome, then
DeviceHub uses a polling scheme to ask where the telescope is and then
send the dome to the correct azimuth.The polling period,
unfortunately, seems to have a minimum of 5 seconds.So, during an APPM
run, APPM will tell the telescope to slew.Sometime less than 5 seconds
later, DeviceHub will retrieve the current RA/DEC from the telescope and
start the dome slewing to that position.For longer slews, the
telescope may still be moving.5 seconds after the dome arrives at the
indicated position, it finds that the telescope has moved again (in
acutality, the telescope never stopped moving, simply completing its
original slew.So DeviceHub issues a second slew to get to the final
position.
So for the Passive settings in APPM, I have to use timeouts long enough
to account for 2 polling periods plus 2 slew times to ensure that the
dome is really in position before imaging starts.I can't let APPM
catch the dome in a stopped state between two dome slews. I hope that
makes sense.
I ran a large model last night using DeviceHub.I lost 5 points in
total, which isn't that bad.Three of them were because of the
bodaciously bright almost full moon and the other two were bad luck in
the timing of long slews from the end of on string of points to the
start of the next.I was concerned that DeviceHub would not position
properly for the counterweight-up points, but it did so correctly.The
model run took a lot longer than I expected since I was waiting 40
seconds (usually unnecessarily) for each point to give the dome time to
get into position in case it was a long slew.
I really don't know if supporting DeviceHub's telescope driver will
work.I'm assuming that if the SideOfPier property is set correctly
when the slew is issued, DeviceHub will go to the correct location even
if it ends up counterweight-up.But I haven't tested that and I really
don't know how--well I guess I could write a little program to do that.
I will do so if you are considering adding such support and the results
of that test would help.
As far as the APPM specific commands, could you allow a connection to
DeviceHub to send the info necessary for the slew and then send the
"special sauce" directly to the AP V2 driver?
- Shane
On 2/28/2021 8:10 AM, Ray Gralak wrote:
Hi Shane,
One more question, Ray:In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?
You would not want to connect APPM to the DeviceHub telescope. APPM uses
some commands that the

DeviceHub would not be able to pass through to the AP V2 driver.
That said, what is the use case for this?
-Ray
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of Shane Ramotowski

Sent: Sunday, February 28, 2021 3:52 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions
One more question, Ray:In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?
Thanks - Shane
On 2/27/2021 8:09 PM, Shane Ramotowski wrote:
Ahh, I think it understand.I use DeviceHub to do the slaving, but
still connect to the DeviceHub dome with APPM.I will try that and
see what happens.
Thanks - Shane
On 2/27/2021 5:27 PM, Ray Gralak wrote:
Shane,
OK.I'll wait for the ASCOM folks to add the APIs that you
want before

I try to use "Active" mode again.
I think you misunderstood. ASCOM is not planning to add those
APIs.

For the second part of my reply, I guess I did not make it
clear enough

that I was using DeviceHub not allowing APPM to connect to
the dome,

since APPM cannot send the dome to the correct position an
DeviceHub

can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
In passive mode, APPM only needs to poll the Dome's slewing
state to

work. If you can't do that then APPM won't be able to tell
when the

dome is done slewing.
If Device Hub won't let APPM connect to the Dome driver you
can use

the older ASCOM POTH application, which allows multiple
applications

to connect to an ASCOM driver.
So can you please tell me what settings I can use for "Delay
before

staring dome slew check" and "Settle time after dome stops
slewing" to

ensure that I end up with at least 30 seconds between the end
of the

telescope slew and the start of imaging?
First, the two parameters only have meaning when you are
connected to

a Dome driver. If you are not connected they won't be used.
"Delay before starting dome slew checking"
The number of seconds before APPM will start checking the dome
driver's slew state. This delay allows the dome driver time to
initiate dome movement that will be reflected by reading
"True" from

the Dome driver's "Slewing" property. If the value is False when
read, then dome slewing will be considered completed.
"Settle time after dome stops slewing"
The number of seconds to delay slew completion after the Dome
driver's "Slewing" property reads "False".
-Ray
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf

Of Shane Ramotowski
Sent: Saturday, February 27, 2021 2:16 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions
OK.I'll wait for the ASCOM folks to add the APIs that you
want before

I try to use "Active" mode again.
For the second part of my reply, I guess I did not make it
clear enough

that I was using DeviceHub not allowing APPM to connect to
the dome,

since APPM cannot send the dome to the correct position an
DeviceHub

can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
_
So can you please tell me what settings I can use for "Delay
before

staring dome slew check" and "Settle time after dome stops
slewing" to

ensure that I end up with at least 30 seconds between the end
of the

telescope slew and the start of imaging?Assume that I did not
change

the default telescope slew of 900X.The log entry I posted is
from a

session that used DeviceHub with "Delay before starting dome slew
check"
set to 30 seconds and "Settle time after dome stops slewing"
set to 10

seconds.You can see that the time between the start of the
telescope

slew and the the start of imaging is about 12 seconds.So,
clearly, I

am not understanding how these two parameters work.
Thank you - Shane
On 2/27/2021 2:16 PM, Ray Gralak wrote:
Shane,
APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work?What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

Again, APPM does not do dome calculations (nor is there a
plan for

it to do that). IMO, the ASCOM Dome API
is missing a way to send scope Ra/Dec/pierside to the Dome
driver.

ASCOM makes such a big deal about
abstracting away telescope applications from the hardware,
but the

incomplete Dome API pretty much forces
the use of a third-party application.
I think each dome manufacturer should each create their own
drivers

that should take into account the
telescope and mount dimensions. It would have made life much
easier

for each application developer that has
had to implement dome coordinate transformations in their
applications.

In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).
That is exactly what I expected.What should I set the two
passive

values to to ensure that the imaging doesn't start for,
say, 1 minute

after the scope stops slewing?Or am I not understanding the
meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be
slaved

to the telescope. In this case APPM just
polls the slewing state until dome slewing stops. If slaving
can't

be done, there is an option in APPM to pause
after each point, which would allow you to position the dome
opening.

The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds.Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen?What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what
happened. Are you sure that you had
APPM connected to your Dome application?
BTW, the problem might be that you are using the ASCOM
Device Hub

instead of the older POTH dome
handling. The behavior is dome behavior is different in
Device Hub,

and it sounds like the author left out some
old functionality.
-Ray
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions
Ray, thanks for the reply, but I don't really see anything that
will help.
APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work?What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

I am definitely returning false fort the CanSlave and Slaved
properties,
since there is no hardware-based slaving capability in the dome
controller.And I don't see way to "send the telescope's
destination

coordinates" to the ASCOM driver.
The call that the ASCOM driver receives from APPM is
"SlewToAzimuth()"
but I think you are basing that azimuth on the center of
the dome

rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the
RA axis

rotates west and level and the DEC axis point strait up. The
telescope
is several inches West of the center of the mount.From what I
understand, if you are going to use SlewToAzimuth(), you
need to

consider this.
If you look at ASCOM's DeviceHub, written by Rick and Pete, who
answer
most of the dome-related questions posted to the ASCOM
Driver and

Application Development Support Forum, it has a whole
section for

dome
and mount geometry in it's setup section to allow slaving.
In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).
That is exactly what I expected.What should I set the two
passive

values to to ensure that the imaging doesn't start for,
say, 1 minute

after the scope stops slewing?Or am I not understanding the
meaning of
those two fields and their documentation in the manual?
Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before
starting

dome slew checking" is set to 30 seconds and "Settle time
after dome

stops slewing" is set to 10 seconds.
0467221 2021-02-26 20:46:21.965:Info,State Machine,
Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103:Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s,
Dec: -10°

00'
00.0")
0467223 2021-02-26 20:46:22.105:Info,Slew Next,
East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105:Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144:Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec:8.501824 / -10.000000 ( 08h 30m 06.56s /
-10°
00' 00.0")
0467226 2021-02-26 20:46:22.215:Info,State Machine,
Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482:Info,State Machine,
Entering
State=Slewing
0467228 2021-02-26 20:46:30.722:Info,State Machine,
Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741:Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970:Info,State Machine,
Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974:Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022:Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022:Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s /-10° 00' 00.0")
0467234 2021-02-26 20:46:33.022:Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s /-10° 00' 00.0")
0467235 2021-02-26 20:46:33.226:Info,State Machine,
Entering
State=StartImage
0467236 2021-02-26 20:46:33.260:Info,State Machine,
Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260:Info,State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260:Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5,
IsDarkFrame=False
The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds.Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen?What am I
misunderstanding?
The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the
slewToAzimuth() is

issued until the dome is stopped at the requested position,
then

returning FALSE until the next slew is issuedSometimes,
DeviceHub or
SGP will end up issuing more than one slew to get the dome
to the

final
position.The slaving software notices that the telescope has
moved and
starts an azimuth slew to where is while the telescope is still
moving.
Once the dome arrives at that position, another azimuth slew to
get to
where the telescope finally stopped.Last night, the longest
time

that
such multiple slews took was about 20 seconds.That is why I
set the

"Delay before starting dome slew checking" to 30 seconds. I
though

that
would make APPM not even check for a dome slew until the
dome was in

place and had stopped moving.Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope
arrived
at its position.
Thanks - Shane
On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,
APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to
the
appropriate dome position.
In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate
application).
So, it seems that your dome's ascom driver (or intermediate
application) may not be correctly indicating
when
the dome is slewing.
-Ray
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions
Hi gang,
I am the proud owner of a brand new (well 2 weeks) Mach2 and
tried to do
my first APPM model tonight.I'm having problems with the dome
control
and hope someone can point in the right direction.
My observatory is a ClearSkys (I don't think they are around
anymore) 8
ft dome.The pier is centered and the bottom of the mount is
just about
even with the bottom of the dome.The rotation control is
homemade (my
COVID quarantine project) and works very will with both ASCOM
DeviceHub
and SGP.I'm using SGP for image capture and plate solve.
I can't figure out how to set up APPM to control the dome
properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel,
APPM seems
to do it's calculations based on the center of the dome
instead

of where
the telescope is.This is not surprising since I can't seem to
find any
where in the program or the documentation to set the
mount and

telescope
geometry.I suppose, since APCC knows that I'm using a
Mach2, it

_could_ already know roughly how far from the center of the
RA/DEC axes
intersection the bottom of my telescope is.But I don't see
anyway that
it could know where the center of my OTA is.I really don't
think it's
using the parameters from 3D view; I haven't set that up,
but the

default is a much larger diameter telescope than mine.
Anyway, when I use "Active", I end up imaging across the
edge of the
slot because the slot is positioned for the center of the
mount

instead
of where the telescope is.Most of the images ended up plate
solving
anyway, but sincethe stars are all diffraction spikes, I
don't

know
the quality of those solutions.The initial slew to
meridian is

probably the worst because the dome is in the exact opposite
position
than it should be and my slot just goes barely past
vertical.I

checked the ASCOM logs on the PC and my ASCOM debug screen on
the dome
controller.The dome _is_ slewing to the position that APPM
requests;
that position just doesn't seem to be based on where the
telescope is.
Can anyone tell me what I'm missing?Where do I enter the
offsets for
the mount/scope geometer so that APPM can got to the correct
position?
So, after trying "Active", I swiched to "Passive" and
tried with

two
different dome slaving programs: ASCOM Device Hub and SGP.For
"Delay
before starting dome slew checking", I used values
ranging from

5 to 30
seconds.For "Settle time after dome stops slewing", I used
values from
1 to 20 seconds.I didn't see any effect when changing these
settings;
in all cases the the telescope slewed to the next
position and

started
imaging a few seconds after it got there--many seconds before
the dome
was in position.None of those images solved since the
dome was

in the
way.Again, I can't figure out what I'm doing wrong--it's like
I'm not
even changing the values.Is there another setting that I'm
missing
that enables these timeouts?
I'm sure someone else has successfully done an APPM run
from an

automated dome!What am I missing?
Thanks - Shane
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Shane Ramotowski
 

OK.  I'll see if I can install and test it.

I apologize: "depricated" was not the term they used.  POTH has been "retired" and "will be removed in a future release".

From the v6.5/v6.5.SP1 Version History <https://ascom-standards.org/Help/Platform/html/FC49CB34-01CF-4D01-BE66-6D55796512D5.htm>:

> Retired Components

The following Platform 5 hubs have been retired in this release and
are replaced by the new Device Hub. We strongly recommend that you
switch over to using the Device Hub because these components will be
removed in a future release.

* POTH
* Hub
* Pipe
* Dome Control Hub


- Shane

On 2/28/2021 8:49 PM, Ray Gralak wrote:

I was unable to test POTH, as you
suggested, since it is depricated, no longer part of the ASCOM 6.5SP1
distribution
Sorry, but that is incorrect!

By default, POTH is not installed, but it can be installed if you select it..

Here’s a screenshot of the ASCOM 6.5 SP1 Setup:

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of
Shane Ramotowski

Sent: Sunday, February 28, 2021 7:06 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions
Not personally, but I would think that anyone using a rotational dome
would need some way to position it so that the telescope is not blocked
by the slot. Since the "Active" mode doesn't do the geometry, unless
you have a very wide slot that goes significantly past vertical,
"Passive" is really the only option.  I was unable to test POTH, as you
suggested, since it is depricated, no longer part of the ASCOM 6.5SP1
distribution, and I could not find a download of it from a reliable
source.  I would expect, however, that it would have a similar issue,
either needing to know where the telescope is slewing to or slewing the
dome by polling the telescope's position periodically.  SGP has slaving
that works well and has a minimum polling frequency of 1 seconds.  But
it was made with the intention of some other application connecting to
SGP to query the dome slewing state.  I don't know of any other solution
than DeviceHub if you are running up-to-date ASCOM.
Of course if you have a roll-off, open clam shell, or are just outside,
you don't need any dome support all!
I'm guessing, based on my serial number, that there are a little over
120 Mach2's out there that came with APPM.  I don't know how many copies
of APPM are being used by 1100 and 1600 users, nor how many of those
users along with other Mach2 owners have rotational domes (I think
roll-offs are much more popular), but I am a bit surprised that this has
not been brought up before.  The Mach2 is fairly compact and I am using
a 4" refractor, so my geometry ought to be about as optimal as it gets.
The slot in my dome looks to be a similar proportion to other domes I've
seen; it is by no means overly narrow.  And yet, in Active mode, for
most of the sample points, the dome ends up covering more than half of
the telescopes view, so I need to use Passive mode.  Maybe I really am
doing something totally wrong and stupid, but I sure don't know what
that would be...
- Shane
On 2/28/2021 7:19 PM, Ray Gralak wrote:
Shane,
As far as the APPM specific commands, could you allow a connection to
DeviceHub to send the info necessary for the slew and then send the
"special sauce" directly to the AP V2 driver?
I would have to bring this up with Marj to see if this is something A-P would want
to have implemented and

supported. Are you aware of any others thatwould want this feature?
-Ray
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of
Shane Ramotowski

Sent: Sunday, February 28, 2021 4:29 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions
When using DeviceHub, if you are connected to both DeviceHub's telescope
and dome drivers, then when you issue a telescope slew, DeviceHub knows
the target RA and DEC and can start a dome slew to the azimuth that the
telescope will end at.
If you cannot connect to the DeviceHub telescope and/or dome, then
DeviceHub uses a polling scheme to ask where the telescope is and then
send the dome to the correct azimuth.The polling period,
unfortunately, seems to have a minimum of 5 seconds.So, during an APPM
run, APPM will tell the telescope to slew.Sometime less than 5 seconds
later, DeviceHub will retrieve the current RA/DEC from the telescope and
start the dome slewing to that position.For longer slews, the
telescope may still be moving.5 seconds after the dome arrives at the
indicated position, it finds that the telescope has moved again (in
acutality, the telescope never stopped moving, simply completing its
original slew.So DeviceHub issues a second slew to get to the final
position.
So for the Passive settings in APPM, I have to use timeouts long enough
to account for 2 polling periods plus 2 slew times to ensure that the
dome is really in position before imaging starts.I can't let APPM
catch the dome in a stopped state between two dome slews. I hope that
makes sense.
I ran a large model last night using DeviceHub.I lost 5 points in
total, which isn't that bad.Three of them were because of the
bodaciously bright almost full moon and the other two were bad luck in
the timing of long slews from the end of on string of points to the
start of the next.I was concerned that DeviceHub would not position
properly for the counterweight-up points, but it did so correctly.The
model run took a lot longer than I expected since I was waiting 40
seconds (usually unnecessarily) for each point to give the dome time to
get into position in case it was a long slew.
I really don't know if supporting DeviceHub's telescope driver will
work.I'm assuming that if the SideOfPier property is set correctly
when the slew is issued, DeviceHub will go to the correct location even
if it ends up counterweight-up.But I haven't tested that and I really
don't know how--well I guess I could write a little program to do that.
I will do so if you are considering adding such support and the results
of that test would help.
As far as the APPM specific commands, could you allow a connection to
DeviceHub to send the info necessary for the slew and then send the
"special sauce" directly to the AP V2 driver?
- Shane
On 2/28/2021 8:10 AM, Ray Gralak wrote:
Hi Shane,
One more question, Ray:In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?
You would not want to connect APPM to the DeviceHub telescope. APPM uses
some commands that the

DeviceHub would not be able to pass through to the AP V2 driver.
That said, what is the use case for this?
-Ray
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of Shane Ramotowski

Sent: Sunday, February 28, 2021 3:52 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions
One more question, Ray:In APPM, is there a way to connect to the
DeviceHub telescope or is it locked to the AP ASCOM driver?
Thanks - Shane
On 2/27/2021 8:09 PM, Shane Ramotowski wrote:
Ahh, I think it understand.I use DeviceHub to do the slaving, but
still connect to the DeviceHub dome with APPM.I will try that and
see what happens.
Thanks - Shane
On 2/27/2021 5:27 PM, Ray Gralak wrote:
Shane,
OK.I'll wait for the ASCOM folks to add the APIs that you
want before

I try to use "Active" mode again.
I think you misunderstood. ASCOM is not planning to add those
APIs.

For the second part of my reply, I guess I did not make it
clear enough

that I was using DeviceHub not allowing APPM to connect to
the dome,

since APPM cannot send the dome to the correct position an
DeviceHub

can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
In passive mode, APPM only needs to poll the Dome's slewing
state to

work. If you can't do that then APPM won't be able to tell
when the

dome is done slewing.
If Device Hub won't let APPM connect to the Dome driver you
can use

the older ASCOM POTH application, which allows multiple
applications

to connect to an ASCOM driver.
So can you please tell me what settings I can use for "Delay
before

staring dome slew check" and "Settle time after dome stops
slewing" to

ensure that I end up with at least 30 seconds between the end
of the

telescope slew and the start of imaging?
First, the two parameters only have meaning when you are
connected to

a Dome driver. If you are not connected they won't be used.
"Delay before starting dome slew checking"
The number of seconds before APPM will start checking the dome
driver's slew state. This delay allows the dome driver time to
initiate dome movement that will be reflected by reading
"True" from

the Dome driver's "Slewing" property. If the value is False when
read, then dome slewing will be considered completed.
"Settle time after dome stops slewing"
The number of seconds to delay slew completion after the Dome
driver's "Slewing" property reads "False".
-Ray
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf

Of Shane Ramotowski
Sent: Saturday, February 27, 2021 2:16 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions
OK.I'll wait for the ASCOM folks to add the APIs that you
want before

I try to use "Active" mode again.
For the second part of my reply, I guess I did not make it
clear enough

that I was using DeviceHub not allowing APPM to connect to
the dome,

since APPM cannot send the dome to the correct position an
DeviceHub

can. _I am simply trying to understand what I'm doing wrong when
setting
up "Passive" parameters in the "Dome Settings" box.__
_
So can you please tell me what settings I can use for "Delay
before

staring dome slew check" and "Settle time after dome stops
slewing" to

ensure that I end up with at least 30 seconds between the end
of the

telescope slew and the start of imaging?Assume that I did not
change

the default telescope slew of 900X.The log entry I posted is
from a

session that used DeviceHub with "Delay before starting dome slew
check"
set to 30 seconds and "Settle time after dome stops slewing"
set to 10

seconds.You can see that the time between the start of the
telescope

slew and the the start of imaging is about 12 seconds.So,
clearly, I

am not understanding how these two parameters work.
Thank you - Shane
On 2/27/2021 2:16 PM, Ray Gralak wrote:
Shane,
APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work?What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

Again, APPM does not do dome calculations (nor is there a
plan for

it to do that). IMO, the ASCOM Dome API
is missing a way to send scope Ra/Dec/pierside to the Dome
driver.

ASCOM makes such a big deal about
abstracting away telescope applications from the hardware,
but the

incomplete Dome API pretty much forces
the use of a third-party application.
I think each dome manufacturer should each create their own
drivers

that should take into account the
telescope and mount dimensions. It would have made life much
easier

for each application developer that has
had to implement dome coordinate transformations in their
applications.

In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).
That is exactly what I expected.What should I set the two
passive

values to to ensure that the imaging doesn't start for,
say, 1 minute

after the scope stops slewing?Or am I not understanding the
meaning of
those two fields and their documentation in the manual?
To use passive mode the dome driver or application must be
slaved

to the telescope. In this case APPM just
polls the slewing state until dome slewing stops. If slaving
can't

be done, there is an option in APPM to pause
after each point, which would allow you to position the dome
opening.

The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds.Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen?What am I
misunderstanding?.
There are no dome messages in your post so I can't tell you what
happened. Are you sure that you had
APPM connected to your Dome application?
BTW, the problem might be that you are using the ASCOM
Device Hub

instead of the older POTH dome
handling. The behavior is dome behavior is different in
Device Hub,

and it sounds like the author left out some
old functionality.
-Ray
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Saturday, February 27, 2021 11:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with Dome Questions
Ray, thanks for the reply, but I don't really see anything that
will help.
APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the
appropriate dome position.
Hmmm, so how does that work?What part of the ASCOM dome API
would that
be?
<https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

I am definitely returning false fort the CanSlave and Slaved
properties,
since there is no hardware-based slaving capability in the dome
controller.And I don't see way to "send the telescope's
destination

coordinates" to the ASCOM driver.
The call that the ASCOM driver receives from APPM is
"SlewToAzimuth()"
but I think you are basing that azimuth on the center of
the dome

rather
than the position of the telescope, which can be significantly
different--consider the initial slew to zenith in which the
RA axis

rotates west and level and the DEC axis point strait up. The
telescope
is several inches West of the center of the mount.From what I
understand, if you are going to use SlewToAzimuth(), you
need to

consider this.
If you look at ASCOM's DeviceHub, written by Rick and Pete, who
answer
most of the dome-related questions posted to the ASCOM
Driver and

Application Development Support Forum, it has a whole
section for

dome
and mount geometry in it's setup section to allow slaving.
In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).
That is exactly what I expected.What should I set the two
passive

values to to ensure that the imaging doesn't start for,
say, 1 minute

after the scope stops slewing?Or am I not understanding the
meaning of
those two fields and their documentation in the manual?
Here is a log excerpt from one of my attempts last night. Under
Settings->Dome Settings, Passive is selected, "Delay before
starting

dome slew checking" is set to 30 seconds and "Settle time
after dome

stops slewing" is set to 10 seconds.
0467221 2021-02-26 20:46:21.965:Info,State Machine,
Entering
State=SlewNext
0467222 2021-02-26 20:46:22.103:Info, SlewNext, Starting
Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s,
Dec: -10°

00'
00.0")
0467223 2021-02-26 20:46:22.105:Info,Slew Next,
East=True,
Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105:Info, Meridian, Setting
Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
UnSAFE Slew to RA/Dec:8.501824 / -10.000000 ( 08h 30m 06.56s /
-10°
00' 00.0")
0467226 2021-02-26 20:46:22.215:Info,State Machine,
Entering
State=PreSlewing
0467227 2021-02-26 20:46:25.482:Info,State Machine,
Entering
State=Slewing
0467228 2021-02-26 20:46:30.722:Info,State Machine,
Entering
State=StartSettle
0467229 2021-02-26 20:46:30.741:Info, StartSettle, Starting
Settle wait time
0467230 2021-02-26 20:46:30.970:Info,State Machine,
Entering
State=WaitSettle
0467231 2021-02-26 20:46:32.974:Info, WaitSettle, Settling
Time Complete
0467232 2021-02-26 20:46:33.022:Info, WaitSettle, Finished
Slew to Point 3
0467233 2021-02-26 20:46:33.022:Info, WaitSettle, RA/Dec:
8.501833 / -10.000000 ( 08h 30m 06.60s /-10° 00' 00.0")
0467234 2021-02-26 20:46:33.022:Info, WaitSettle, HA/Dec:
-1.329942 / -10.000000 (-01h 19m 47.79s /-10° 00' 00.0")
0467235 2021-02-26 20:46:33.226:Info,State Machine,
Entering
State=StartImage
0467236 2021-02-26 20:46:33.260:Info,State Machine,
Starting
Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260:Info,State Machine, LST mid
image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260:Info, StartTakeImage, Sequence
Generator Pro: Binning=1, Subframe Type: 0, Duration=5,
IsDarkFrame=False
The total time between the start of the point's processing and
start of
it's imaging is about 12 seconds.Shouldn't that be at least 40
seconds
to allow the dome delay and settle times to happen?What am I
misunderstanding?
The dome controller and ASCOM driver do handle Slewing property
correctly, returning TRUE from the time that the
slewToAzimuth() is

issued until the dome is stopped at the requested position,
then

returning FALSE until the next slew is issuedSometimes,
DeviceHub or
SGP will end up issuing more than one slew to get the dome
to the

final
position.The slaving software notices that the telescope has
moved and
starts an azimuth slew to where is while the telescope is still
moving.
Once the dome arrives at that position, another azimuth slew to
get to
where the telescope finally stopped.Last night, the longest
time

that
such multiple slews took was about 20 seconds.That is why I
set the

"Delay before starting dome slew checking" to 30 seconds. I
though

that
would make APPM not even check for a dome slew until the
dome was in

place and had stopped moving.Instead, it seemed to have made no
difference: the imaging started almost as soon as the telescope
arrived
at its position.
Thanks - Shane
On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,
APPM's "Active mode" sends the telescope's destination
coordinates to the dome ASCOM driver. In this
case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to
the
appropriate dome position.
In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate
application).
So, it seems that your dome's ascom driver (or intermediate
application) may not be correctly indicating
when
the dome is slewing.
-Ray
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions
Hi gang,
I am the proud owner of a brand new (well 2 weeks) Mach2 and
tried to do
my first APPM model tonight.I'm having problems with the dome
control
and hope someone can point in the right direction.
My observatory is a ClearSkys (I don't think they are around
anymore) 8
ft dome.The pier is centered and the bottom of the mount is
just about
even with the bottom of the dome.The rotation control is
homemade (my
COVID quarantine project) and works very will with both ASCOM
DeviceHub
and SGP.I'm using SGP for image capture and plate solve.
I can't figure out how to set up APPM to control the dome
properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel,
APPM seems
to do it's calculations based on the center of the dome
instead

of where
the telescope is.This is not surprising since I can't seem to
find any
where in the program or the documentation to set the
mount and

telescope
geometry.I suppose, since APCC knows that I'm using a
Mach2, it

_could_ already know roughly how far from the center of the
RA/DEC axes
intersection the bottom of my telescope is.But I don't see
anyway that
it could know where the center of my OTA is.I really don't
think it's
using the parameters from 3D view; I haven't set that up,
but the

default is a much larger diameter telescope than mine.
Anyway, when I use "Active", I end up imaging across the
edge of the
slot because the slot is positioned for the center of the
mount

instead
of where the telescope is.Most of the images ended up plate
solving
anyway, but sincethe stars are all diffraction spikes, I
don't

know
the quality of those solutions.The initial slew to
meridian is

probably the worst because the dome is in the exact opposite
position
than it should be and my slot just goes barely past
vertical.I

checked the ASCOM logs on the PC and my ASCOM debug screen on
the dome
controller.The dome _is_ slewing to the position that APPM
requests;
that position just doesn't seem to be based on where the
telescope is.
Can anyone tell me what I'm missing?Where do I enter the
offsets for
the mount/scope geometer so that APPM can got to the correct
position?
So, after trying "Active", I swiched to "Passive" and
tried with

two
different dome slaving programs: ASCOM Device Hub and SGP.For
"Delay
before starting dome slew checking", I used values
ranging from

5 to 30
seconds.For "Settle time after dome stops slewing", I used
values from
1 to 20 seconds.I didn't see any effect when changing these
settings;
in all cases the the telescope slewed to the next
position and

started
imaging a few seconds after it got there--many seconds before
the dome
was in position.None of those images solved since the
dome was

in the
way.Again, I can't figure out what I'm doing wrong--it's like
I'm not
even changing the values.Is there another setting that I'm
missing
that enables these timeouts?
I'm sure someone else has successfully done an APPM run
from an

automated dome!What am I missing?
Thanks - Shane
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Ron Kramer
 

Following.  I read the thread and have experienced much the same as Shane.   APPM, scope and dome do not play together on my setup either. timing is off and it's quite a chore to revert back to SGP which I normally have deleted from my observatory drive.  I have been waiting to use APPM for when NINA is supported. 
Shane, give NINA a try (free) it's jaw-droppingly good coming from SGP. 

On Mon, Mar 1, 2021 at 8:33 AM Shane Ramotowski <kor@...> wrote:
OK.  I'll see if I can install and test it.

I apologize: "depricated" was not the term they used.  POTH has been
"retired" and "will be removed in a future release".

 From the v6.5/v6.5.SP1 Version History
<https://ascom-standards.org/Help/Platform/html/FC49CB34-01CF-4D01-BE66-6D55796512D5.htm>:

    > Retired  Components

    The following Platform 5 hubs have been retired in this release and
    are replaced by the new Device Hub. We strongly recommend that you
    switch over to using the Device Hub because these components will be
    removed in a future release.

      * POTH
      * Hub
      * Pipe
      * Dome Control Hub


- Shane

On 2/28/2021 8:49 PM, Ray Gralak wrote:
>
> > I was unable to test POTH, as you
>
> > suggested, since it is depricated, no longer part of the ASCOM 6.5SP1
>
> > distribution
>
> Sorry, but that is incorrect!
>
> By default, POTH is not installed, but it can be installed if you
> select it..
>
> Here’s a screenshot of the ASCOM 6.5 SP1 Setup:
>
> -Ray
>
> > -----Original Message-----
>
> > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of
> Shane Ramotowski
>
> > Sent: Sunday, February 28, 2021 7:06 PM
>
> > To: main@ap-gto.groups.io
>
> > Subject: Re: [ap-gto] APPM with Dome Questions
>
> >
>
> > Not personally, but I would think that anyone using a rotational dome
>
> > would need some way to position it so that the telescope is not blocked
>
> > by the slot. Since the "Active" mode doesn't do the geometry, unless
>
> > you have a very wide slot that goes significantly past vertical,
>
> > "Passive" is really the only option.  I was unable to test POTH, as you
>
> > suggested, since it is depricated, no longer part of the ASCOM 6.5SP1
>
> > distribution, and I could not find a download of it from a reliable
>
> > source.  I would expect, however, that it would have a similar issue,
>
> > either needing to know where the telescope is slewing to or slewing the
>
> > dome by polling the telescope's position periodically.  SGP has slaving
>
> > that works well and has a minimum polling frequency of 1 seconds.  But
>
> > it was made with the intention of some other application connecting to
>
> > SGP to query the dome slewing state.  I don't know of any other solution
>
> > than DeviceHub if you are running up-to-date ASCOM.
>
> >
>
> > Of course if you have a roll-off, open clam shell, or are just outside,
>
> > you don't need any dome support all!
>
> >
>
> > I'm guessing, based on my serial number, that there are a little over
>
> > 120 Mach2's out there that came with APPM.  I don't know how many copies
>
> > of APPM are being used by 1100 and 1600 users, nor how many of those
>
> > users along with other Mach2 owners have rotational domes (I think
>
> > roll-offs are much more popular), but I am a bit surprised that this has
>
> > not been brought up before.  The Mach2 is fairly compact and I am using
>
> > a 4" refractor, so my geometry ought to be about as optimal as it gets.
>
> > The slot in my dome looks to be a similar proportion to other domes I've
>
> > seen; it is by no means overly narrow.  And yet, in Active mode, for
>
> > most of the sample points, the dome ends up covering more than half of
>
> > the telescopes view, so I need to use Passive mode.  Maybe I really am
>
> > doing something totally wrong and stupid, but I sure don't know what
>
> > that would be...
>
> >
>
> > - Shane
>
> >
>
> > On 2/28/2021 7:19 PM, Ray Gralak wrote:
>
> > > Shane,
>
> > >
>
> > >> As far as the APPM specific commands, could you allow a connection to
>
> > >> DeviceHub to send the info necessary for the slew and then send the
>
> > >> "special sauce" directly to the AP V2 driver?
>
> > > I would have to bring this up with Marj to see if this is something A-P would want
> to have implemented and
>
> > supported. Are you aware of any others thatwould want this feature?
>
> > >
>
> > > -Ray
>
> > >
>
> > >> -----Original Message-----
>
> > >> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of
> Shane Ramotowski
>
> > >> Sent: Sunday, February 28, 2021 4:29 PM
>
> > >> To: main@ap-gto.groups.io
>
> > >> Subject: Re: [ap-gto] APPM with Dome Questions
>
> > >>
>
> > >> When using DeviceHub, if you are connected to both DeviceHub's telescope
>
> > >> and dome drivers, then when you issue a telescope slew, DeviceHub knows
>
> > >> the target RA and DEC and can start a dome slew to the azimuth that the
>
> > >> telescope will end at.
>
> > >>
>
> > >> If you cannot connect to the DeviceHub telescope and/or dome, then
>
> > >> DeviceHub uses a polling scheme to ask where the telescope is and then
>
> > >> send the dome to the correct azimuth.The polling period,
>
> > >> unfortunately, seems to have a minimum of 5 seconds.So, during an APPM
>
> > >> run, APPM will tell the telescope to slew.Sometime less than 5 seconds
>
> > >> later, DeviceHub will retrieve the current RA/DEC from the telescope and
>
> > >> start the dome slewing to that position.For longer slews, the
>
> > >> telescope may still be moving.5 seconds after the dome arrives at the
>
> > >> indicated position, it finds that the telescope has moved again (in
>
> > >> acutality, the telescope never stopped moving, simply completing its
>
> > >> original slew.So DeviceHub issues a second slew to get to the final
>
> > >> position.
>
> > >>
>
> > >> So for the Passive settings in APPM, I have to use timeouts long enough
>
> > >> to account for 2 polling periods plus 2 slew times to ensure that the
>
> > >> dome is really in position before imaging starts.I can't let APPM
>
> > >> catch the dome in a stopped state between two dome slews. I hope that
>
> > >> makes sense.
>
> > >>
>
> > >> I ran a large model last night using DeviceHub.I lost 5 points in
>
> > >> total, which isn't that bad.Three of them were because of the
>
> > >> bodaciously bright almost full moon and the other two were bad luck in
>
> > >> the timing of long slews from the end of on string of points to the
>
> > >> start of the next.I was concerned that DeviceHub would not position
>
> > >> properly for the counterweight-up points, but it did so correctly.The
>
> > >> model run took a lot longer than I expected since I was waiting 40
>
> > >> seconds (usually unnecessarily) for each point to give the dome time to
>
> > >> get into position in case it was a long slew.
>
> > >>
>
> > >> I really don't know if supporting DeviceHub's telescope driver will
>
> > >> work.I'm assuming that if the SideOfPier property is set correctly
>
> > >> when the slew is issued, DeviceHub will go to the correct location even
>
> > >> if it ends up counterweight-up.But I haven't tested that and I really
>
> > >> don't know how--well I guess I could write a little program to do that.
>
> > >> I will do so if you are considering adding such support and the results
>
> > >> of that test would help.
>
> > >>
>
> > >> As far as the APPM specific commands, could you allow a connection to
>
> > >> DeviceHub to send the info necessary for the slew and then send the
>
> > >> "special sauce" directly to the AP V2 driver?
>
> > >>
>
> > >> - Shane
>
> > >>
>
> > >> On 2/28/2021 8:10 AM, Ray Gralak wrote:
>
> > >>> Hi Shane,
>
> > >>>
>
> > >>>> One more question, Ray:In APPM, is there a way to connect to the
>
> > >>>> DeviceHub telescope or is it locked to the AP ASCOM driver?
>
> > >>> You would not want to connect APPM to the DeviceHub telescope. APPM uses
> some commands that the
>
> > >> DeviceHub would not be able to pass through to the AP V2 driver.
>
> > >>> That said, what is the use case for this?
>
> > >>>
>
> > >>> -Ray
>
> > >>>
>
> > >>>> -----Original Message-----
>
> > >>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
> Of Shane Ramotowski
>
> > >>>> Sent: Sunday, February 28, 2021 3:52 AM
>
> > >>>> To: main@ap-gto.groups.io
>
> > >>>> Subject: Re: [ap-gto] APPM with Dome Questions
>
> > >>>>
>
> > >>>> One more question, Ray:In APPM, is there a way to connect to the
>
> > >>>> DeviceHub telescope or is it locked to the AP ASCOM driver?
>
> > >>>>
>
> > >>>> Thanks - Shane
>
> > >>>>
>
> > >>>> On 2/27/2021 8:09 PM, Shane Ramotowski wrote:
>
> > >>>>> Ahh, I think it understand.I use DeviceHub to do the slaving, but
>
> > >>>>> still connect to the DeviceHub dome with APPM.I will try that and
>
> > >>>>> see what happens.
>
> > >>>>>
>
> > >>>>> Thanks - Shane
>
> > >>>>>
>
> > >>>>> On 2/27/2021 5:27 PM, Ray Gralak wrote:
>
> > >>>>>> Shane,
>
> > >>>>>>
>
> > >>>>>>> OK.I'll wait for the ASCOM folks to add the APIs that you
> want before
>
> > >>>>>>> I try to use "Active" mode again.
>
> > >>>>>> I think you misunderstood. ASCOM is not planning to add those
> APIs.
>
> > >>>>>>
>
> > >>>>>>> For the second part of my reply, I guess I did not make it
> clear enough
>
> > >>>>>>> that I was using DeviceHub not allowing APPM to connect to
> the dome,
>
> > >>>>>>> since APPM cannot send the dome to the correct position an
> DeviceHub
>
> > >>>>>>> can. _I am simply trying to understand what I'm doing wrong when
>
> > >>>>>>> setting
>
> > >>>>>>> up "Passive" parameters in the "Dome Settings" box.__
>
> > >>>>>> In passive mode, APPM only needs to poll the Dome's slewing
> state to
>
> > >>>>>> work. If you can't do that then APPM won't be able to tell
> when the
>
> > >>>>>> dome is done slewing.
>
> > >>>>>>
>
> > >>>>>> If Device Hub won't let APPM connect to the Dome driver you
> can use
>
> > >>>>>> the older ASCOM POTH application, which allows multiple
> applications
>
> > >>>>>> to connect to an ASCOM driver.
>
> > >>>>>>
>
> > >>>>>>> So can you please tell me what settings I can use for "Delay
> before
>
> > >>>>>>> staring dome slew check" and "Settle time after dome stops
> slewing" to
>
> > >>>>>>> ensure that I end up with at least 30 seconds between the end
> of the
>
> > >>>>>>> telescope slew and the start of imaging?
>
> > >>>>>> First, the two parameters only have meaning when you are
> connected to
>
> > >>>>>> a Dome driver. If you are not connected they won't be used.
>
> > >>>>>>
>
> > >>>>>> "Delay before starting dome slew checking"
>
> > >>>>>>
>
> > >>>>>> The number of seconds before APPM will start checking the dome
>
> > >>>>>> driver's slew state. This delay allows the dome driver time to
>
> > >>>>>> initiate dome movement that will be reflected by reading
> "True" from
>
> > >>>>>> the Dome driver's "Slewing" property. If the value is False when
>
> > >>>>>> read, then dome slewing will be considered completed.
>
> > >>>>>>
>
> > >>>>>> "Settle time after dome stops slewing"
>
> > >>>>>>
>
> > >>>>>> The number of seconds to delay slew completion after the Dome
>
> > >>>>>> driver's "Slewing" property reads "False".
>
> > >>>>>>
>
> > >>>>>> -Ray
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>> -----Original Message-----
>
> > >>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
> Behalf
>
> > >>>>>>> Of Shane Ramotowski
>
> > >>>>>>> Sent: Saturday, February 27, 2021 2:16 PM
>
> > >>>>>>> To: main@ap-gto.groups.io
>
> > >>>>>>> Subject: Re: [ap-gto] APPM with Dome Questions
>
> > >>>>>>>
>
> > >>>>>>> OK.I'll wait for the ASCOM folks to add the APIs that you
> want before
>
> > >>>>>>> I try to use "Active" mode again.
>
> > >>>>>>>
>
> > >>>>>>> For the second part of my reply, I guess I did not make it
> clear enough
>
> > >>>>>>> that I was using DeviceHub not allowing APPM to connect to
> the dome,
>
> > >>>>>>> since APPM cannot send the dome to the correct position an
> DeviceHub
>
> > >>>>>>> can. _I am simply trying to understand what I'm doing wrong when
>
> > >>>>>>> setting
>
> > >>>>>>> up "Passive" parameters in the "Dome Settings" box.__
>
> > >>>>>>> _
>
> > >>>>>>> So can you please tell me what settings I can use for "Delay
> before
>
> > >>>>>>> staring dome slew check" and "Settle time after dome stops
> slewing" to
>
> > >>>>>>> ensure that I end up with at least 30 seconds between the end
> of the
>
> > >>>>>>> telescope slew and the start of imaging?Assume that I did not
> change
>
> > >>>>>>> the default telescope slew of 900X.The log entry I posted is
> from a
>
> > >>>>>>> session that used DeviceHub with "Delay before starting dome slew
>
> > >>>>>>> check"
>
> > >>>>>>> set to 30 seconds and "Settle time after dome stops slewing"
> set to 10
>
> > >>>>>>> seconds.You can see that the time between the start of the
> telescope
>
> > >>>>>>> slew and the the start of imaging is about 12 seconds.So,
> clearly, I
>
> > >>>>>>> am not understanding how these two parameters work.
>
> > >>>>>>>
>
> > >>>>>>> Thank you - Shane
>
> > >>>>>>>
>
> > >>>>>>>
>
> > >>>>>>> On 2/27/2021 2:16 PM, Ray Gralak wrote:
>
> > >>>>>>>> Shane,
>
> > >>>>>>>>
>
> > >>>>>>>>>> APPM's "Active mode" sends the telescope's destination
>
> > >>>>>>>>>> coordinates to the dome ASCOM driver. In this
>
> > >>>>>>>>> case, it is the responsibility of the driver or intermediate
>
> > >>>>>>>>>> application to translate the RA/Dec coordinates to the
>
> > >>>>>>>>>> appropriate dome position.
>
> > >>>>>>>>> Hmmm, so how does that work?What part of the ASCOM dome API
>
> > >>>>>>>>> would that
>
> > >>>>>>>>> be?
>
> > >>>>>>>>>
> <https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
>
> > >>>>>>>>>
>
> > >>>>>>>> Again, APPM does not do dome calculations (nor is there a
> plan for
>
> > >>>>>>>> it to do that). IMO, the ASCOM Dome API
>
> > >>>>>>> is missing a way to send scope Ra/Dec/pierside to the Dome
> driver.
>
> > >>>>>>> ASCOM makes such a big deal about
>
> > >>>>>>> abstracting away telescope applications from the hardware,
> but the
>
> > >>>>>>> incomplete Dome API pretty much forces
>
> > >>>>>>> the use of a third-party application.
>
> > >>>>>>>> I think each dome manufacturer should each create their own
> drivers
>
> > >>>>>>>> that should take into account the
>
> > >>>>>>> telescope and mount dimensions. It would have made life much
> easier
>
> > >>>>>>> for each application developer that has
>
> > >>>>>>> had to implement dome coordinate transformations in their
> applications.
>
> > >>>>>>>>>> In "Passive mode" APPM waits for the dome to finish slewing by
>
> > >>>>>>>>> polling the dome's driver (or intermediate application).
>
> > >>>>>>>>>
>
> > >>>>>>>>> That is exactly what I expected.What should I set the two
> passive
>
> > >>>>>>>>> values to to ensure that the imaging doesn't start for,
> say, 1 minute
>
> > >>>>>>>>> after the scope stops slewing?Or am I not understanding the
>
> > >>>>>>>>> meaning of
>
> > >>>>>>>>> those two fields and their documentation in the manual?
>
> > >>>>>>>> To use passive mode the dome driver or application must be
> slaved
>
> > >>>>>>>> to the telescope. In this case APPM just
>
> > >>>>>>> polls the slewing state until dome slewing stops. If slaving
> can't
>
> > >>>>>>> be done, there is an option in APPM to pause
>
> > >>>>>>> after each point, which would allow you to position the dome
> opening.
>
> > >>>>>>>>> The total time between the start of the point's processing and
>
> > >>>>>>>>> start of
>
> > >>>>>>>>> it's imaging is about 12 seconds.Shouldn't that be at least 40
>
> > >>>>>>>>> seconds
>
> > >>>>>>>>> to allow the dome delay and settle times to happen?What am I
>
> > >>>>>>>>> misunderstanding?.
>
> > >>>>>>>> There are no dome messages in your post so I can't tell you what
>
> > >>>>>>>> happened. Are you sure that you had
>
> > >>>>>>> APPM connected to your Dome application?
>
> > >>>>>>>> BTW, the problem might be that you are using the ASCOM
> Device Hub
>
> > >>>>>>>> instead of the older POTH dome
>
> > >>>>>>> handling. The behavior is dome behavior is different in
> Device Hub,
>
> > >>>>>>> and it sounds like the author left out some
>
> > >>>>>>> old functionality.
>
> > >>>>>>>> -Ray
>
> > >>>>>>>>
>
> > >>>>>>>>> -----Original Message-----
>
> > >>>>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
>
> > >>>>>>>>> Behalf Of Shane Ramotowski
>
> > >>>>>>>>> Sent: Saturday, February 27, 2021 11:32 AM
>
> > >>>>>>>>> To: main@ap-gto.groups.io
>
> > >>>>>>>>> Subject: Re: [ap-gto] APPM with Dome Questions
>
> > >>>>>>>>>
>
> > >>>>>>>>> Ray, thanks for the reply, but I don't really see anything that
>
> > >>>>>>>>> will help.
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>>> APPM's "Active mode" sends the telescope's destination
>
> > >>>>>>>>>> coordinates to the dome ASCOM driver. In this
>
> > >>>>>>>>> case, it is the responsibility of the driver or intermediate
>
> > >>>>>>>>>> application to translate the RA/Dec coordinates to the
>
> > >>>>>>>>>> appropriate dome position.
>
> > >>>>>>>>> Hmmm, so how does that work?What part of the ASCOM dome API
>
> > >>>>>>>>> would that
>
> > >>>>>>>>> be?
>
> > >>>>>>>>>
> <https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>> I am definitely returning false fort the CanSlave and Slaved
>
> > >>>>>>>>> properties,
>
> > >>>>>>>>> since there is no hardware-based slaving capability in the dome
>
> > >>>>>>>>> controller.And I don't see way to "send the telescope's
> destination
>
> > >>>>>>>>> coordinates" to the ASCOM driver.
>
> > >>>>>>>>>
>
> > >>>>>>>>> The call that the ASCOM driver receives from APPM is
>
> > >>>>>>>>> "SlewToAzimuth()"
>
> > >>>>>>>>> but I think you are basing that azimuth on the center of
> the dome
>
> > >>>>>>>>> rather
>
> > >>>>>>>>> than the position of the telescope, which can be significantly
>
> > >>>>>>>>> different--consider the initial slew to zenith in which the
> RA axis
>
> > >>>>>>>>> rotates west and level and the DEC axis point strait up. The
>
> > >>>>>>>>> telescope
>
> > >>>>>>>>> is several inches West of the center of the mount.From what I
>
> > >>>>>>>>> understand, if you are going to use SlewToAzimuth(), you
> need to
>
> > >>>>>>>>> consider this.
>
> > >>>>>>>>>
>
> > >>>>>>>>> If you look at ASCOM's DeviceHub, written by Rick and Pete, who
>
> > >>>>>>>>> answer
>
> > >>>>>>>>> most of the dome-related questions posted to the ASCOM
> Driver and
>
> > >>>>>>>>> Application Development Support Forum, it has a whole
> section for
>
> > >>>>>>>>> dome
>
> > >>>>>>>>> and mount geometry in it's setup section to allow slaving.
>
> > >>>>>>>>>
>
> > >>>>>>>>>> In "Passive mode" APPM waits for the dome to finish slewing by
>
> > >>>>>>>>> polling the dome's driver (or intermediate application).
>
> > >>>>>>>>>
>
> > >>>>>>>>> That is exactly what I expected.What should I set the two
> passive
>
> > >>>>>>>>> values to to ensure that the imaging doesn't start for,
> say, 1 minute
>
> > >>>>>>>>> after the scope stops slewing?Or am I not understanding the
>
> > >>>>>>>>> meaning of
>
> > >>>>>>>>> those two fields and their documentation in the manual?
>
> > >>>>>>>>>
>
> > >>>>>>>>> Here is a log excerpt from one of my attempts last night. Under
>
> > >>>>>>>>> Settings->Dome Settings, Passive is selected, "Delay before
> starting
>
> > >>>>>>>>> dome slew checking" is set to 30 seconds and "Settle time
> after dome
>
> > >>>>>>>>> stops slewing" is set to 10 seconds.
>
> > >>>>>>>>>
>
> > >>>>>>>>> 0467221 2021-02-26 20:46:21.965:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=SlewNext
>
> > >>>>>>>>> 0467222 2021-02-26 20:46:22.103:Info, SlewNext, Starting
>
> > >>>>>>>>> Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s,
> Dec: -10°
>
> > >>>>>>>>> 00'
>
> > >>>>>>>>> 00.0")
>
> > >>>>>>>>> 0467223 2021-02-26 20:46:22.105:Info,Slew Next,
>
> > >>>>>>>>> East=True,
>
> > >>>>>>>>> Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
>
> > >>>>>>>>> 0467224 2021-02-26 20:46:22.105:Info, Meridian, Setting
>
> > >>>>>>>>> Meridian Delay to -0.25 (-00h 15m 00.00s)
>
> > >>>>>>>>> 0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
>
> > >>>>>>>>> UnSAFE Slew to RA/Dec:8.501824 / -10.000000 ( 08h 30m 06.56s /
>
> > >>>>>>>>> -10°
>
> > >>>>>>>>> 00' 00.0")
>
> > >>>>>>>>> 0467226 2021-02-26 20:46:22.215:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=PreSlewing
>
> > >>>>>>>>> 0467227 2021-02-26 20:46:25.482:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=Slewing
>
> > >>>>>>>>> 0467228 2021-02-26 20:46:30.722:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=StartSettle
>
> > >>>>>>>>> 0467229 2021-02-26 20:46:30.741:Info, StartSettle, Starting
>
> > >>>>>>>>> Settle wait time
>
> > >>>>>>>>> 0467230 2021-02-26 20:46:30.970:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=WaitSettle
>
> > >>>>>>>>> 0467231 2021-02-26 20:46:32.974:Info, WaitSettle, Settling
>
> > >>>>>>>>> Time Complete
>
> > >>>>>>>>> 0467232 2021-02-26 20:46:33.022:Info, WaitSettle, Finished
>
> > >>>>>>>>> Slew to Point 3
>
> > >>>>>>>>> 0467233 2021-02-26 20:46:33.022:Info, WaitSettle, RA/Dec:
>
> > >>>>>>>>> 8.501833 / -10.000000 ( 08h 30m 06.60s /-10° 00' 00.0")
>
> > >>>>>>>>> 0467234 2021-02-26 20:46:33.022:Info, WaitSettle, HA/Dec:
>
> > >>>>>>>>> -1.329942 / -10.000000 (-01h 19m 47.79s /-10° 00' 00.0")
>
> > >>>>>>>>> 0467235 2021-02-26 20:46:33.226:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=StartImage
>
> > >>>>>>>>> 0467236 2021-02-26 20:46:33.260:Info,State Machine,
>
> > >>>>>>>>> Starting
>
> > >>>>>>>>> Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
>
> > >>>>>>>>> 0467237 2021-02-26 20:46:33.260:Info,State Machine, LST mid
>
> > >>>>>>>>> image=7.1727475 (07h 10m 21.89s)
>
> > >>>>>>>>> 0467238 2021-02-26 20:46:33.260:Info, StartTakeImage, Sequence
>
> > >>>>>>>>> Generator Pro: Binning=1, Subframe Type: 0, Duration=5,
>
> > >>>>>>>>> IsDarkFrame=False
>
> > >>>>>>>>>
>
> > >>>>>>>>> The total time between the start of the point's processing and
>
> > >>>>>>>>> start of
>
> > >>>>>>>>> it's imaging is about 12 seconds.Shouldn't that be at least 40
>
> > >>>>>>>>> seconds
>
> > >>>>>>>>> to allow the dome delay and settle times to happen?What am I
>
> > >>>>>>>>> misunderstanding?
>
> > >>>>>>>>>
>
> > >>>>>>>>> The dome controller and ASCOM driver do handle Slewing property
>
> > >>>>>>>>> correctly, returning TRUE from the time that the
> slewToAzimuth() is
>
> > >>>>>>>>> issued until the dome is stopped at the requested position,
> then
>
> > >>>>>>>>> returning FALSE until the next slew is issuedSometimes,
>
> > >>>>>>>>> DeviceHub or
>
> > >>>>>>>>> SGP will end up issuing more than one slew to get the dome
> to the
>
> > >>>>>>>>> final
>
> > >>>>>>>>> position.The slaving software notices that the telescope has
>
> > >>>>>>>>> moved and
>
> > >>>>>>>>> starts an azimuth slew to where is while the telescope is still
>
> > >>>>>>>>> moving.
>
> > >>>>>>>>> Once the dome arrives at that position, another azimuth slew to
>
> > >>>>>>>>> get to
>
> > >>>>>>>>> where the telescope finally stopped.Last night, the longest
> time
>
> > >>>>>>>>> that
>
> > >>>>>>>>> such multiple slews took was about 20 seconds.That is why I
> set the
>
> > >>>>>>>>> "Delay before starting dome slew checking" to 30 seconds. I
> though
>
> > >>>>>>>>> that
>
> > >>>>>>>>> would make APPM not even check for a dome slew until the
> dome was in
>
> > >>>>>>>>> place and had stopped moving.Instead, it seemed to have made no
>
> > >>>>>>>>> difference: the imaging started almost as soon as the telescope
>
> > >>>>>>>>> arrived
>
> > >>>>>>>>> at its position.
>
> > >>>>>>>>>
>
> > >>>>>>>>> Thanks - Shane
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>> On 2/27/2021 10:06 AM, Ray Gralak wrote:
>
> > >>>>>>>>>> Hi Shane,
>
> > >>>>>>>>>>
>
> > >>>>>>>>>> APPM's "Active mode" sends the telescope's destination
>
> > >>>>>>>>>> coordinates to the dome ASCOM driver. In this
>
> > >>>>>>>>> case, it is the responsibility of the driver or intermediate
>
> > >>>>>>>>> application to translate the RA/Dec coordinates to
>
> > >>>>>>> the
>
> > >>>>>>>>> appropriate dome position.
>
> > >>>>>>>>>> In "Passive mode" APPM waits for the dome to finish slewing by
>
> > >>>>>>>>>> polling the dome's driver (or intermediate
>
> > >>>>>>>>> application).
>
> > >>>>>>>>>> So, it seems that your dome's ascom driver (or intermediate
>
> > >>>>>>>>>> application) may not be correctly indicating
>
> > >>>>>>> when
>
> > >>>>>>>>> the dome is slewing.
>
> > >>>>>>>>>> -Ray
>
> > >>>>>>>>>>
>
> > >>>>>>>>>>> -----Original Message-----
>
> > >>>>>>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
>
> > >>>>>>>>>>> Behalf Of Shane Ramotowski
>
> > >>>>>>>>>>> Sent: Friday, February 26, 2021 9:19 PM
>
> > >>>>>>>>>>> To: main@ap-gto.groups.io
>
> > >>>>>>>>>>> Subject: [ap-gto] APPM with Dome Questions
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> Hi gang,
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> I am the proud owner of a brand new (well 2 weeks) Mach2 and
>
> > >>>>>>>>>>> tried to do
>
> > >>>>>>>>>>> my first APPM model tonight.I'm having problems with the dome
>
> > >>>>>>>>>>> control
>
> > >>>>>>>>>>> and hope someone can point in the right direction.
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> My observatory is a ClearSkys (I don't think they are around
>
> > >>>>>>>>>>> anymore) 8
>
> > >>>>>>>>>>> ft dome.The pier is centered and the bottom of the mount is
>
> > >>>>>>>>>>> just about
>
> > >>>>>>>>>>> even with the bottom of the dome.The rotation control is
>
> > >>>>>>>>>>> homemade (my
>
> > >>>>>>>>>>> COVID quarantine project) and works very will with both ASCOM
>
> > >>>>>>>>>>> DeviceHub
>
> > >>>>>>>>>>> and SGP.I'm using SGP for image capture and plate solve.
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> I can't figure out how to set up APPM to control the dome
>
> > >>>>>>>>>>> properly. If I
>
> > >>>>>>>>>>> use "Active" in the "AP Point Mapper - Dome Settings" panel,
>
> > >>>>>>>>>>> APPM seems
>
> > >>>>>>>>>>> to do it's calculations based on the center of the dome
> instead
>
> > >>>>>>>>>>> of where
>
> > >>>>>>>>>>> the telescope is.This is not surprising since I can't seem to
>
> > >>>>>>>>>>> find any
>
> > >>>>>>>>>>> where in the program or the documentation to set the
> mount and
>
> > >>>>>>>>>>> telescope
>
> > >>>>>>>>>>> geometry.I suppose, since APCC knows that I'm using a
> Mach2, it
>
> > >>>>>>>>>>> _could_ already know roughly how far from the center of the
>
> > >>>>>>>>>>> RA/DEC axes
>
> > >>>>>>>>>>> intersection the bottom of my telescope is.But I don't see
>
> > >>>>>>>>>>> anyway that
>
> > >>>>>>>>>>> it could know where the center of my OTA is.I really don't
>
> > >>>>>>>>>>> think it's
>
> > >>>>>>>>>>> using the parameters from 3D view; I haven't set that up,
> but the
>
> > >>>>>>>>>>> default is a much larger diameter telescope than mine.
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>>Anyway, when I use "Active", I end up imaging across the
>
> > >>>>>>>>>>> edge of the
>
> > >>>>>>>>>>> slot because the slot is positioned for the center of the
> mount
>
> > >>>>>>>>>>> instead
>
> > >>>>>>>>>>> of where the telescope is.Most of the images ended up plate
>
> > >>>>>>>>>>> solving
>
> > >>>>>>>>>>> anyway, but sincethe stars are all diffraction spikes, I
> don't
>
> > >>>>>>>>>>> know
>
> > >>>>>>>>>>> the quality of those solutions.The initial slew to
> meridian is
>
> > >>>>>>>>>>> probably the worst because the dome is in the exact opposite
>
> > >>>>>>>>>>> position
>
> > >>>>>>>>>>> than it should be and my slot just goes barely past
> vertical.I
>
> > >>>>>>>>>>> checked the ASCOM logs on the PC and my ASCOM debug screen on
>
> > >>>>>>>>>>> the dome
>
> > >>>>>>>>>>> controller.The dome _is_ slewing to the position that APPM
>
> > >>>>>>>>>>> requests;
>
> > >>>>>>>>>>> that position just doesn't seem to be based on where the
>
> > >>>>>>>>>>> telescope is.
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> Can anyone tell me what I'm missing?Where do I enter the
>
> > >>>>>>>>>>> offsets for
>
> > >>>>>>>>>>> the mount/scope geometer so that APPM can got to the correct
>
> > >>>>>>>>>>> position?
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> So, after trying "Active", I swiched to "Passive" and
> tried with
>
> > >>>>>>>>>>> two
>
> > >>>>>>>>>>> different dome slaving programs: ASCOM Device Hub and SGP.For
>
> > >>>>>>>>>>> "Delay
>
> > >>>>>>>>>>> before starting dome slew checking", I used values
> ranging from
>
> > >>>>>>>>>>> 5 to 30
>
> > >>>>>>>>>>> seconds.For "Settle time after dome stops slewing", I used
>
> > >>>>>>>>>>> values from
>
> > >>>>>>>>>>> 1 to 20 seconds.I didn't see any effect when changing these
>
> > >>>>>>>>>>> settings;
>
> > >>>>>>>>>>> in all cases the the telescope slewed to the next
> position and
>
> > >>>>>>>>>>> started
>
> > >>>>>>>>>>> imaging a few seconds after it got there--many seconds before
>
> > >>>>>>>>>>> the dome
>
> > >>>>>>>>>>> was in position.None of those images solved since the
> dome was
>
> > >>>>>>>>>>> in the
>
> > >>>>>>>>>>> way.Again, I can't figure out what I'm doing wrong--it's like
>
> > >>>>>>>>>>> I'm not
>
> > >>>>>>>>>>> even changing the values.Is there another setting that I'm
>
> > >>>>>>>>>>> missing
>
> > >>>>>>>>>>> that enables these timeouts?
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> I'm sure someone else has successfully done an APPM run
> from an
>
> > >>>>>>>>>>> automated dome!What am I missing?
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> Thanks - Shane
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> --
>
> > >>>>>>>>>>> Shane Ramotowski
>
> > >>>>>>>>>>> kor@...
>
> > >>>>>>>>>>> https://www.kor-astro.net
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>
>
> > >>>>>>>>>>
>
> > >>>>>>>>>>
>
> > >>>>>>>>>>
>
> > >>>>>>>>> --
>
> > >>>>>>>>> Shane Ramotowski
>
> > >>>>>>>>> kor@...
>
> > >>>>>>>>> https://www.kor-astro.net
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>> --
>
> > >>>>>>> Shane Ramotowski
>
> > >>>>>>> kor@...
>
> > >>>>>>> https://www.kor-astro.net
>
> > >>>>>>>
>
> > >>>>>>>
>
> > >>>>>>>
>
> > >>>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>> --
>
> > >>>> Shane Ramotowski
>
> > >>>> kor@...
>
> > >>>> https://www.kor-astro.net
>
> > >>>>
>
> > >>>>
>
> > >>>>
>
> > >>>>
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >> --
>
> > >> Shane Ramotowski
>
> > >> kor@...
>
> > >> https://www.kor-astro.net
>
> > >>
>
> > >>
>
> > >>
>
> > >>
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> >
>
> > --
>
> > Shane Ramotowski
>
> > kor@...
>
> > https://www.kor-astro.net
>
> >
>
> >
>
> >
>
> >
>
>

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









Ron Kramer
 

PS the other issue is ASTAP is vastly superior to platesolve2.  I no longer have the later configured. 
I would recommend supporting NINA and ASTAP instead since both are free.  Unlike SGP. (buy something just to configure APPM)? 


On Thu, Mar 4, 2021 at 10:01 AM Ron Kramer via groups.io <ronkramer1957=gmail.com@groups.io> wrote:
Following.  I read the thread and have experienced much the same as Shane.   APPM, scope and dome do not play together on my setup either. timing is off and it's quite a chore to revert back to SGP which I normally have deleted from my observatory drive.  I have been waiting to use APPM for when NINA is supported. 
Shane, give NINA a try (free) it's jaw-droppingly good coming from SGP. 

On Mon, Mar 1, 2021 at 8:33 AM Shane Ramotowski <kor@...> wrote:
OK.  I'll see if I can install and test it.

I apologize: "depricated" was not the term they used.  POTH has been
"retired" and "will be removed in a future release".

 From the v6.5/v6.5.SP1 Version History
<https://ascom-standards.org/Help/Platform/html/FC49CB34-01CF-4D01-BE66-6D55796512D5.htm>:

    > Retired  Components

    The following Platform 5 hubs have been retired in this release and
    are replaced by the new Device Hub. We strongly recommend that you
    switch over to using the Device Hub because these components will be
    removed in a future release.

      * POTH
      * Hub
      * Pipe
      * Dome Control Hub


- Shane

On 2/28/2021 8:49 PM, Ray Gralak wrote:
>
> > I was unable to test POTH, as you
>
> > suggested, since it is depricated, no longer part of the ASCOM 6.5SP1
>
> > distribution
>
> Sorry, but that is incorrect!
>
> By default, POTH is not installed, but it can be installed if you
> select it..
>
> Here’s a screenshot of the ASCOM 6.5 SP1 Setup:
>
> -Ray
>
> > -----Original Message-----
>
> > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of
> Shane Ramotowski
>
> > Sent: Sunday, February 28, 2021 7:06 PM
>
> > To: main@ap-gto.groups.io
>
> > Subject: Re: [ap-gto] APPM with Dome Questions
>
> >
>
> > Not personally, but I would think that anyone using a rotational dome
>
> > would need some way to position it so that the telescope is not blocked
>
> > by the slot. Since the "Active" mode doesn't do the geometry, unless
>
> > you have a very wide slot that goes significantly past vertical,
>
> > "Passive" is really the only option.  I was unable to test POTH, as you
>
> > suggested, since it is depricated, no longer part of the ASCOM 6.5SP1
>
> > distribution, and I could not find a download of it from a reliable
>
> > source.  I would expect, however, that it would have a similar issue,
>
> > either needing to know where the telescope is slewing to or slewing the
>
> > dome by polling the telescope's position periodically.  SGP has slaving
>
> > that works well and has a minimum polling frequency of 1 seconds.  But
>
> > it was made with the intention of some other application connecting to
>
> > SGP to query the dome slewing state.  I don't know of any other solution
>
> > than DeviceHub if you are running up-to-date ASCOM.
>
> >
>
> > Of course if you have a roll-off, open clam shell, or are just outside,
>
> > you don't need any dome support all!
>
> >
>
> > I'm guessing, based on my serial number, that there are a little over
>
> > 120 Mach2's out there that came with APPM.  I don't know how many copies
>
> > of APPM are being used by 1100 and 1600 users, nor how many of those
>
> > users along with other Mach2 owners have rotational domes (I think
>
> > roll-offs are much more popular), but I am a bit surprised that this has
>
> > not been brought up before.  The Mach2 is fairly compact and I am using
>
> > a 4" refractor, so my geometry ought to be about as optimal as it gets.
>
> > The slot in my dome looks to be a similar proportion to other domes I've
>
> > seen; it is by no means overly narrow.  And yet, in Active mode, for
>
> > most of the sample points, the dome ends up covering more than half of
>
> > the telescopes view, so I need to use Passive mode.  Maybe I really am
>
> > doing something totally wrong and stupid, but I sure don't know what
>
> > that would be...
>
> >
>
> > - Shane
>
> >
>
> > On 2/28/2021 7:19 PM, Ray Gralak wrote:
>
> > > Shane,
>
> > >
>
> > >> As far as the APPM specific commands, could you allow a connection to
>
> > >> DeviceHub to send the info necessary for the slew and then send the
>
> > >> "special sauce" directly to the AP V2 driver?
>
> > > I would have to bring this up with Marj to see if this is something A-P would want
> to have implemented and
>
> > supported. Are you aware of any others thatwould want this feature?
>
> > >
>
> > > -Ray
>
> > >
>
> > >> -----Original Message-----
>
> > >> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of
> Shane Ramotowski
>
> > >> Sent: Sunday, February 28, 2021 4:29 PM
>
> > >> To: main@ap-gto.groups.io
>
> > >> Subject: Re: [ap-gto] APPM with Dome Questions
>
> > >>
>
> > >> When using DeviceHub, if you are connected to both DeviceHub's telescope
>
> > >> and dome drivers, then when you issue a telescope slew, DeviceHub knows
>
> > >> the target RA and DEC and can start a dome slew to the azimuth that the
>
> > >> telescope will end at.
>
> > >>
>
> > >> If you cannot connect to the DeviceHub telescope and/or dome, then
>
> > >> DeviceHub uses a polling scheme to ask where the telescope is and then
>
> > >> send the dome to the correct azimuth.The polling period,
>
> > >> unfortunately, seems to have a minimum of 5 seconds.So, during an APPM
>
> > >> run, APPM will tell the telescope to slew.Sometime less than 5 seconds
>
> > >> later, DeviceHub will retrieve the current RA/DEC from the telescope and
>
> > >> start the dome slewing to that position.For longer slews, the
>
> > >> telescope may still be moving.5 seconds after the dome arrives at the
>
> > >> indicated position, it finds that the telescope has moved again (in
>
> > >> acutality, the telescope never stopped moving, simply completing its
>
> > >> original slew.So DeviceHub issues a second slew to get to the final
>
> > >> position.
>
> > >>
>
> > >> So for the Passive settings in APPM, I have to use timeouts long enough
>
> > >> to account for 2 polling periods plus 2 slew times to ensure that the
>
> > >> dome is really in position before imaging starts.I can't let APPM
>
> > >> catch the dome in a stopped state between two dome slews. I hope that
>
> > >> makes sense.
>
> > >>
>
> > >> I ran a large model last night using DeviceHub.I lost 5 points in
>
> > >> total, which isn't that bad.Three of them were because of the
>
> > >> bodaciously bright almost full moon and the other two were bad luck in
>
> > >> the timing of long slews from the end of on string of points to the
>
> > >> start of the next.I was concerned that DeviceHub would not position
>
> > >> properly for the counterweight-up points, but it did so correctly.The
>
> > >> model run took a lot longer than I expected since I was waiting 40
>
> > >> seconds (usually unnecessarily) for each point to give the dome time to
>
> > >> get into position in case it was a long slew.
>
> > >>
>
> > >> I really don't know if supporting DeviceHub's telescope driver will
>
> > >> work.I'm assuming that if the SideOfPier property is set correctly
>
> > >> when the slew is issued, DeviceHub will go to the correct location even
>
> > >> if it ends up counterweight-up.But I haven't tested that and I really
>
> > >> don't know how--well I guess I could write a little program to do that.
>
> > >> I will do so if you are considering adding such support and the results
>
> > >> of that test would help.
>
> > >>
>
> > >> As far as the APPM specific commands, could you allow a connection to
>
> > >> DeviceHub to send the info necessary for the slew and then send the
>
> > >> "special sauce" directly to the AP V2 driver?
>
> > >>
>
> > >> - Shane
>
> > >>
>
> > >> On 2/28/2021 8:10 AM, Ray Gralak wrote:
>
> > >>> Hi Shane,
>
> > >>>
>
> > >>>> One more question, Ray:In APPM, is there a way to connect to the
>
> > >>>> DeviceHub telescope or is it locked to the AP ASCOM driver?
>
> > >>> You would not want to connect APPM to the DeviceHub telescope. APPM uses
> some commands that the
>
> > >> DeviceHub would not be able to pass through to the AP V2 driver.
>
> > >>> That said, what is the use case for this?
>
> > >>>
>
> > >>> -Ray
>
> > >>>
>
> > >>>> -----Original Message-----
>
> > >>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
> Of Shane Ramotowski
>
> > >>>> Sent: Sunday, February 28, 2021 3:52 AM
>
> > >>>> To: main@ap-gto.groups.io
>
> > >>>> Subject: Re: [ap-gto] APPM with Dome Questions
>
> > >>>>
>
> > >>>> One more question, Ray:In APPM, is there a way to connect to the
>
> > >>>> DeviceHub telescope or is it locked to the AP ASCOM driver?
>
> > >>>>
>
> > >>>> Thanks - Shane
>
> > >>>>
>
> > >>>> On 2/27/2021 8:09 PM, Shane Ramotowski wrote:
>
> > >>>>> Ahh, I think it understand.I use DeviceHub to do the slaving, but
>
> > >>>>> still connect to the DeviceHub dome with APPM.I will try that and
>
> > >>>>> see what happens.
>
> > >>>>>
>
> > >>>>> Thanks - Shane
>
> > >>>>>
>
> > >>>>> On 2/27/2021 5:27 PM, Ray Gralak wrote:
>
> > >>>>>> Shane,
>
> > >>>>>>
>
> > >>>>>>> OK.I'll wait for the ASCOM folks to add the APIs that you
> want before
>
> > >>>>>>> I try to use "Active" mode again.
>
> > >>>>>> I think you misunderstood. ASCOM is not planning to add those
> APIs.
>
> > >>>>>>
>
> > >>>>>>> For the second part of my reply, I guess I did not make it
> clear enough
>
> > >>>>>>> that I was using DeviceHub not allowing APPM to connect to
> the dome,
>
> > >>>>>>> since APPM cannot send the dome to the correct position an
> DeviceHub
>
> > >>>>>>> can. _I am simply trying to understand what I'm doing wrong when
>
> > >>>>>>> setting
>
> > >>>>>>> up "Passive" parameters in the "Dome Settings" box.__
>
> > >>>>>> In passive mode, APPM only needs to poll the Dome's slewing
> state to
>
> > >>>>>> work. If you can't do that then APPM won't be able to tell
> when the
>
> > >>>>>> dome is done slewing.
>
> > >>>>>>
>
> > >>>>>> If Device Hub won't let APPM connect to the Dome driver you
> can use
>
> > >>>>>> the older ASCOM POTH application, which allows multiple
> applications
>
> > >>>>>> to connect to an ASCOM driver.
>
> > >>>>>>
>
> > >>>>>>> So can you please tell me what settings I can use for "Delay
> before
>
> > >>>>>>> staring dome slew check" and "Settle time after dome stops
> slewing" to
>
> > >>>>>>> ensure that I end up with at least 30 seconds between the end
> of the
>
> > >>>>>>> telescope slew and the start of imaging?
>
> > >>>>>> First, the two parameters only have meaning when you are
> connected to
>
> > >>>>>> a Dome driver. If you are not connected they won't be used.
>
> > >>>>>>
>
> > >>>>>> "Delay before starting dome slew checking"
>
> > >>>>>>
>
> > >>>>>> The number of seconds before APPM will start checking the dome
>
> > >>>>>> driver's slew state. This delay allows the dome driver time to
>
> > >>>>>> initiate dome movement that will be reflected by reading
> "True" from
>
> > >>>>>> the Dome driver's "Slewing" property. If the value is False when
>
> > >>>>>> read, then dome slewing will be considered completed.
>
> > >>>>>>
>
> > >>>>>> "Settle time after dome stops slewing"
>
> > >>>>>>
>
> > >>>>>> The number of seconds to delay slew completion after the Dome
>
> > >>>>>> driver's "Slewing" property reads "False".
>
> > >>>>>>
>
> > >>>>>> -Ray
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>> -----Original Message-----
>
> > >>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
> Behalf
>
> > >>>>>>> Of Shane Ramotowski
>
> > >>>>>>> Sent: Saturday, February 27, 2021 2:16 PM
>
> > >>>>>>> To: main@ap-gto.groups.io
>
> > >>>>>>> Subject: Re: [ap-gto] APPM with Dome Questions
>
> > >>>>>>>
>
> > >>>>>>> OK.I'll wait for the ASCOM folks to add the APIs that you
> want before
>
> > >>>>>>> I try to use "Active" mode again.
>
> > >>>>>>>
>
> > >>>>>>> For the second part of my reply, I guess I did not make it
> clear enough
>
> > >>>>>>> that I was using DeviceHub not allowing APPM to connect to
> the dome,
>
> > >>>>>>> since APPM cannot send the dome to the correct position an
> DeviceHub
>
> > >>>>>>> can. _I am simply trying to understand what I'm doing wrong when
>
> > >>>>>>> setting
>
> > >>>>>>> up "Passive" parameters in the "Dome Settings" box.__
>
> > >>>>>>> _
>
> > >>>>>>> So can you please tell me what settings I can use for "Delay
> before
>
> > >>>>>>> staring dome slew check" and "Settle time after dome stops
> slewing" to
>
> > >>>>>>> ensure that I end up with at least 30 seconds between the end
> of the
>
> > >>>>>>> telescope slew and the start of imaging?Assume that I did not
> change
>
> > >>>>>>> the default telescope slew of 900X.The log entry I posted is
> from a
>
> > >>>>>>> session that used DeviceHub with "Delay before starting dome slew
>
> > >>>>>>> check"
>
> > >>>>>>> set to 30 seconds and "Settle time after dome stops slewing"
> set to 10
>
> > >>>>>>> seconds.You can see that the time between the start of the
> telescope
>
> > >>>>>>> slew and the the start of imaging is about 12 seconds.So,
> clearly, I
>
> > >>>>>>> am not understanding how these two parameters work.
>
> > >>>>>>>
>
> > >>>>>>> Thank you - Shane
>
> > >>>>>>>
>
> > >>>>>>>
>
> > >>>>>>> On 2/27/2021 2:16 PM, Ray Gralak wrote:
>
> > >>>>>>>> Shane,
>
> > >>>>>>>>
>
> > >>>>>>>>>> APPM's "Active mode" sends the telescope's destination
>
> > >>>>>>>>>> coordinates to the dome ASCOM driver. In this
>
> > >>>>>>>>> case, it is the responsibility of the driver or intermediate
>
> > >>>>>>>>>> application to translate the RA/Dec coordinates to the
>
> > >>>>>>>>>> appropriate dome position.
>
> > >>>>>>>>> Hmmm, so how does that work?What part of the ASCOM dome API
>
> > >>>>>>>>> would that
>
> > >>>>>>>>> be?
>
> > >>>>>>>>>
> <https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
>
> > >>>>>>>>>
>
> > >>>>>>>> Again, APPM does not do dome calculations (nor is there a
> plan for
>
> > >>>>>>>> it to do that). IMO, the ASCOM Dome API
>
> > >>>>>>> is missing a way to send scope Ra/Dec/pierside to the Dome
> driver.
>
> > >>>>>>> ASCOM makes such a big deal about
>
> > >>>>>>> abstracting away telescope applications from the hardware,
> but the
>
> > >>>>>>> incomplete Dome API pretty much forces
>
> > >>>>>>> the use of a third-party application.
>
> > >>>>>>>> I think each dome manufacturer should each create their own
> drivers
>
> > >>>>>>>> that should take into account the
>
> > >>>>>>> telescope and mount dimensions. It would have made life much
> easier
>
> > >>>>>>> for each application developer that has
>
> > >>>>>>> had to implement dome coordinate transformations in their
> applications.
>
> > >>>>>>>>>> In "Passive mode" APPM waits for the dome to finish slewing by
>
> > >>>>>>>>> polling the dome's driver (or intermediate application).
>
> > >>>>>>>>>
>
> > >>>>>>>>> That is exactly what I expected.What should I set the two
> passive
>
> > >>>>>>>>> values to to ensure that the imaging doesn't start for,
> say, 1 minute
>
> > >>>>>>>>> after the scope stops slewing?Or am I not understanding the
>
> > >>>>>>>>> meaning of
>
> > >>>>>>>>> those two fields and their documentation in the manual?
>
> > >>>>>>>> To use passive mode the dome driver or application must be
> slaved
>
> > >>>>>>>> to the telescope. In this case APPM just
>
> > >>>>>>> polls the slewing state until dome slewing stops. If slaving
> can't
>
> > >>>>>>> be done, there is an option in APPM to pause
>
> > >>>>>>> after each point, which would allow you to position the dome
> opening.
>
> > >>>>>>>>> The total time between the start of the point's processing and
>
> > >>>>>>>>> start of
>
> > >>>>>>>>> it's imaging is about 12 seconds.Shouldn't that be at least 40
>
> > >>>>>>>>> seconds
>
> > >>>>>>>>> to allow the dome delay and settle times to happen?What am I
>
> > >>>>>>>>> misunderstanding?.
>
> > >>>>>>>> There are no dome messages in your post so I can't tell you what
>
> > >>>>>>>> happened. Are you sure that you had
>
> > >>>>>>> APPM connected to your Dome application?
>
> > >>>>>>>> BTW, the problem might be that you are using the ASCOM
> Device Hub
>
> > >>>>>>>> instead of the older POTH dome
>
> > >>>>>>> handling. The behavior is dome behavior is different in
> Device Hub,
>
> > >>>>>>> and it sounds like the author left out some
>
> > >>>>>>> old functionality.
>
> > >>>>>>>> -Ray
>
> > >>>>>>>>
>
> > >>>>>>>>> -----Original Message-----
>
> > >>>>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
>
> > >>>>>>>>> Behalf Of Shane Ramotowski
>
> > >>>>>>>>> Sent: Saturday, February 27, 2021 11:32 AM
>
> > >>>>>>>>> To: main@ap-gto.groups.io
>
> > >>>>>>>>> Subject: Re: [ap-gto] APPM with Dome Questions
>
> > >>>>>>>>>
>
> > >>>>>>>>> Ray, thanks for the reply, but I don't really see anything that
>
> > >>>>>>>>> will help.
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>>> APPM's "Active mode" sends the telescope's destination
>
> > >>>>>>>>>> coordinates to the dome ASCOM driver. In this
>
> > >>>>>>>>> case, it is the responsibility of the driver or intermediate
>
> > >>>>>>>>>> application to translate the RA/Dec coordinates to the
>
> > >>>>>>>>>> appropriate dome position.
>
> > >>>>>>>>> Hmmm, so how does that work?What part of the ASCOM dome API
>
> > >>>>>>>>> would that
>
> > >>>>>>>>> be?
>
> > >>>>>>>>>
> <https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>> I am definitely returning false fort the CanSlave and Slaved
>
> > >>>>>>>>> properties,
>
> > >>>>>>>>> since there is no hardware-based slaving capability in the dome
>
> > >>>>>>>>> controller.And I don't see way to "send the telescope's
> destination
>
> > >>>>>>>>> coordinates" to the ASCOM driver.
>
> > >>>>>>>>>
>
> > >>>>>>>>> The call that the ASCOM driver receives from APPM is
>
> > >>>>>>>>> "SlewToAzimuth()"
>
> > >>>>>>>>> but I think you are basing that azimuth on the center of
> the dome
>
> > >>>>>>>>> rather
>
> > >>>>>>>>> than the position of the telescope, which can be significantly
>
> > >>>>>>>>> different--consider the initial slew to zenith in which the
> RA axis
>
> > >>>>>>>>> rotates west and level and the DEC axis point strait up. The
>
> > >>>>>>>>> telescope
>
> > >>>>>>>>> is several inches West of the center of the mount.From what I
>
> > >>>>>>>>> understand, if you are going to use SlewToAzimuth(), you
> need to
>
> > >>>>>>>>> consider this.
>
> > >>>>>>>>>
>
> > >>>>>>>>> If you look at ASCOM's DeviceHub, written by Rick and Pete, who
>
> > >>>>>>>>> answer
>
> > >>>>>>>>> most of the dome-related questions posted to the ASCOM
> Driver and
>
> > >>>>>>>>> Application Development Support Forum, it has a whole
> section for
>
> > >>>>>>>>> dome
>
> > >>>>>>>>> and mount geometry in it's setup section to allow slaving.
>
> > >>>>>>>>>
>
> > >>>>>>>>>> In "Passive mode" APPM waits for the dome to finish slewing by
>
> > >>>>>>>>> polling the dome's driver (or intermediate application).
>
> > >>>>>>>>>
>
> > >>>>>>>>> That is exactly what I expected.What should I set the two
> passive
>
> > >>>>>>>>> values to to ensure that the imaging doesn't start for,
> say, 1 minute
>
> > >>>>>>>>> after the scope stops slewing?Or am I not understanding the
>
> > >>>>>>>>> meaning of
>
> > >>>>>>>>> those two fields and their documentation in the manual?
>
> > >>>>>>>>>
>
> > >>>>>>>>> Here is a log excerpt from one of my attempts last night. Under
>
> > >>>>>>>>> Settings->Dome Settings, Passive is selected, "Delay before
> starting
>
> > >>>>>>>>> dome slew checking" is set to 30 seconds and "Settle time
> after dome
>
> > >>>>>>>>> stops slewing" is set to 10 seconds.
>
> > >>>>>>>>>
>
> > >>>>>>>>> 0467221 2021-02-26 20:46:21.965:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=SlewNext
>
> > >>>>>>>>> 0467222 2021-02-26 20:46:22.103:Info, SlewNext, Starting
>
> > >>>>>>>>> Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s,
> Dec: -10°
>
> > >>>>>>>>> 00'
>
> > >>>>>>>>> 00.0")
>
> > >>>>>>>>> 0467223 2021-02-26 20:46:22.105:Info,Slew Next,
>
> > >>>>>>>>> East=True,
>
> > >>>>>>>>> Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
>
> > >>>>>>>>> 0467224 2021-02-26 20:46:22.105:Info, Meridian, Setting
>
> > >>>>>>>>> Meridian Delay to -0.25 (-00h 15m 00.00s)
>
> > >>>>>>>>> 0467225 2021-02-26 20:46:22.144: Info, SlewAsync, Begin
>
> > >>>>>>>>> UnSAFE Slew to RA/Dec:8.501824 / -10.000000 ( 08h 30m 06.56s /
>
> > >>>>>>>>> -10°
>
> > >>>>>>>>> 00' 00.0")
>
> > >>>>>>>>> 0467226 2021-02-26 20:46:22.215:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=PreSlewing
>
> > >>>>>>>>> 0467227 2021-02-26 20:46:25.482:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=Slewing
>
> > >>>>>>>>> 0467228 2021-02-26 20:46:30.722:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=StartSettle
>
> > >>>>>>>>> 0467229 2021-02-26 20:46:30.741:Info, StartSettle, Starting
>
> > >>>>>>>>> Settle wait time
>
> > >>>>>>>>> 0467230 2021-02-26 20:46:30.970:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=WaitSettle
>
> > >>>>>>>>> 0467231 2021-02-26 20:46:32.974:Info, WaitSettle, Settling
>
> > >>>>>>>>> Time Complete
>
> > >>>>>>>>> 0467232 2021-02-26 20:46:33.022:Info, WaitSettle, Finished
>
> > >>>>>>>>> Slew to Point 3
>
> > >>>>>>>>> 0467233 2021-02-26 20:46:33.022:Info, WaitSettle, RA/Dec:
>
> > >>>>>>>>> 8.501833 / -10.000000 ( 08h 30m 06.60s /-10° 00' 00.0")
>
> > >>>>>>>>> 0467234 2021-02-26 20:46:33.022:Info, WaitSettle, HA/Dec:
>
> > >>>>>>>>> -1.329942 / -10.000000 (-01h 19m 47.79s /-10° 00' 00.0")
>
> > >>>>>>>>> 0467235 2021-02-26 20:46:33.226:Info,State Machine,
>
> > >>>>>>>>> Entering
>
> > >>>>>>>>> State=StartImage
>
> > >>>>>>>>> 0467236 2021-02-26 20:46:33.260:Info,State Machine,
>
> > >>>>>>>>> Starting
>
> > >>>>>>>>> Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
>
> > >>>>>>>>> 0467237 2021-02-26 20:46:33.260:Info,State Machine, LST mid
>
> > >>>>>>>>> image=7.1727475 (07h 10m 21.89s)
>
> > >>>>>>>>> 0467238 2021-02-26 20:46:33.260:Info, StartTakeImage, Sequence
>
> > >>>>>>>>> Generator Pro: Binning=1, Subframe Type: 0, Duration=5,
>
> > >>>>>>>>> IsDarkFrame=False
>
> > >>>>>>>>>
>
> > >>>>>>>>> The total time between the start of the point's processing and
>
> > >>>>>>>>> start of
>
> > >>>>>>>>> it's imaging is about 12 seconds.Shouldn't that be at least 40
>
> > >>>>>>>>> seconds
>
> > >>>>>>>>> to allow the dome delay and settle times to happen?What am I
>
> > >>>>>>>>> misunderstanding?
>
> > >>>>>>>>>
>
> > >>>>>>>>> The dome controller and ASCOM driver do handle Slewing property
>
> > >>>>>>>>> correctly, returning TRUE from the time that the
> slewToAzimuth() is
>
> > >>>>>>>>> issued until the dome is stopped at the requested position,
> then
>
> > >>>>>>>>> returning FALSE until the next slew is issuedSometimes,
>
> > >>>>>>>>> DeviceHub or
>
> > >>>>>>>>> SGP will end up issuing more than one slew to get the dome
> to the
>
> > >>>>>>>>> final
>
> > >>>>>>>>> position.The slaving software notices that the telescope has
>
> > >>>>>>>>> moved and
>
> > >>>>>>>>> starts an azimuth slew to where is while the telescope is still
>
> > >>>>>>>>> moving.
>
> > >>>>>>>>> Once the dome arrives at that position, another azimuth slew to
>
> > >>>>>>>>> get to
>
> > >>>>>>>>> where the telescope finally stopped.Last night, the longest
> time
>
> > >>>>>>>>> that
>
> > >>>>>>>>> such multiple slews took was about 20 seconds.That is why I
> set the
>
> > >>>>>>>>> "Delay before starting dome slew checking" to 30 seconds. I
> though
>
> > >>>>>>>>> that
>
> > >>>>>>>>> would make APPM not even check for a dome slew until the
> dome was in
>
> > >>>>>>>>> place and had stopped moving.Instead, it seemed to have made no
>
> > >>>>>>>>> difference: the imaging started almost as soon as the telescope
>
> > >>>>>>>>> arrived
>
> > >>>>>>>>> at its position.
>
> > >>>>>>>>>
>
> > >>>>>>>>> Thanks - Shane
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>> On 2/27/2021 10:06 AM, Ray Gralak wrote:
>
> > >>>>>>>>>> Hi Shane,
>
> > >>>>>>>>>>
>
> > >>>>>>>>>> APPM's "Active mode" sends the telescope's destination
>
> > >>>>>>>>>> coordinates to the dome ASCOM driver. In this
>
> > >>>>>>>>> case, it is the responsibility of the driver or intermediate
>
> > >>>>>>>>> application to translate the RA/Dec coordinates to
>
> > >>>>>>> the
>
> > >>>>>>>>> appropriate dome position.
>
> > >>>>>>>>>> In "Passive mode" APPM waits for the dome to finish slewing by
>
> > >>>>>>>>>> polling the dome's driver (or intermediate
>
> > >>>>>>>>> application).
>
> > >>>>>>>>>> So, it seems that your dome's ascom driver (or intermediate
>
> > >>>>>>>>>> application) may not be correctly indicating
>
> > >>>>>>> when
>
> > >>>>>>>>> the dome is slewing.
>
> > >>>>>>>>>> -Ray
>
> > >>>>>>>>>>
>
> > >>>>>>>>>>> -----Original Message-----
>
> > >>>>>>>>>>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On
>
> > >>>>>>>>>>> Behalf Of Shane Ramotowski
>
> > >>>>>>>>>>> Sent: Friday, February 26, 2021 9:19 PM
>
> > >>>>>>>>>>> To: main@ap-gto.groups.io
>
> > >>>>>>>>>>> Subject: [ap-gto] APPM with Dome Questions
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> Hi gang,
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> I am the proud owner of a brand new (well 2 weeks) Mach2 and
>
> > >>>>>>>>>>> tried to do
>
> > >>>>>>>>>>> my first APPM model tonight.I'm having problems with the dome
>
> > >>>>>>>>>>> control
>
> > >>>>>>>>>>> and hope someone can point in the right direction.
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> My observatory is a ClearSkys (I don't think they are around
>
> > >>>>>>>>>>> anymore) 8
>
> > >>>>>>>>>>> ft dome.The pier is centered and the bottom of the mount is
>
> > >>>>>>>>>>> just about
>
> > >>>>>>>>>>> even with the bottom of the dome.The rotation control is
>
> > >>>>>>>>>>> homemade (my
>
> > >>>>>>>>>>> COVID quarantine project) and works very will with both ASCOM
>
> > >>>>>>>>>>> DeviceHub
>
> > >>>>>>>>>>> and SGP.I'm using SGP for image capture and plate solve.
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> I can't figure out how to set up APPM to control the dome
>
> > >>>>>>>>>>> properly. If I
>
> > >>>>>>>>>>> use "Active" in the "AP Point Mapper - Dome Settings" panel,
>
> > >>>>>>>>>>> APPM seems
>
> > >>>>>>>>>>> to do it's calculations based on the center of the dome
> instead
>
> > >>>>>>>>>>> of where
>
> > >>>>>>>>>>> the telescope is.This is not surprising since I can't seem to
>
> > >>>>>>>>>>> find any
>
> > >>>>>>>>>>> where in the program or the documentation to set the
> mount and
>
> > >>>>>>>>>>> telescope
>
> > >>>>>>>>>>> geometry.I suppose, since APCC knows that I'm using a
> Mach2, it
>
> > >>>>>>>>>>> _could_ already know roughly how far from the center of the
>
> > >>>>>>>>>>> RA/DEC axes
>
> > >>>>>>>>>>> intersection the bottom of my telescope is.But I don't see
>
> > >>>>>>>>>>> anyway that
>
> > >>>>>>>>>>> it could know where the center of my OTA is.I really don't
>
> > >>>>>>>>>>> think it's
>
> > >>>>>>>>>>> using the parameters from 3D view; I haven't set that up,
> but the
>
> > >>>>>>>>>>> default is a much larger diameter telescope than mine.
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>>Anyway, when I use "Active", I end up imaging across the
>
> > >>>>>>>>>>> edge of the
>
> > >>>>>>>>>>> slot because the slot is positioned for the center of the
> mount
>
> > >>>>>>>>>>> instead
>
> > >>>>>>>>>>> of where the telescope is.Most of the images ended up plate
>
> > >>>>>>>>>>> solving
>
> > >>>>>>>>>>> anyway, but sincethe stars are all diffraction spikes, I
> don't
>
> > >>>>>>>>>>> know
>
> > >>>>>>>>>>> the quality of those solutions.The initial slew to
> meridian is
>
> > >>>>>>>>>>> probably the worst because the dome is in the exact opposite
>
> > >>>>>>>>>>> position
>
> > >>>>>>>>>>> than it should be and my slot just goes barely past
> vertical.I
>
> > >>>>>>>>>>> checked the ASCOM logs on the PC and my ASCOM debug screen on
>
> > >>>>>>>>>>> the dome
>
> > >>>>>>>>>>> controller.The dome _is_ slewing to the position that APPM
>
> > >>>>>>>>>>> requests;
>
> > >>>>>>>>>>> that position just doesn't seem to be based on where the
>
> > >>>>>>>>>>> telescope is.
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> Can anyone tell me what I'm missing?Where do I enter the
>
> > >>>>>>>>>>> offsets for
>
> > >>>>>>>>>>> the mount/scope geometer so that APPM can got to the correct
>
> > >>>>>>>>>>> position?
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> So, after trying "Active", I swiched to "Passive" and
> tried with
>
> > >>>>>>>>>>> two
>
> > >>>>>>>>>>> different dome slaving programs: ASCOM Device Hub and SGP.For
>
> > >>>>>>>>>>> "Delay
>
> > >>>>>>>>>>> before starting dome slew checking", I used values
> ranging from
>
> > >>>>>>>>>>> 5 to 30
>
> > >>>>>>>>>>> seconds.For "Settle time after dome stops slewing", I used
>
> > >>>>>>>>>>> values from
>
> > >>>>>>>>>>> 1 to 20 seconds.I didn't see any effect when changing these
>
> > >>>>>>>>>>> settings;
>
> > >>>>>>>>>>> in all cases the the telescope slewed to the next
> position and
>
> > >>>>>>>>>>> started
>
> > >>>>>>>>>>> imaging a few seconds after it got there--many seconds before
>
> > >>>>>>>>>>> the dome
>
> > >>>>>>>>>>> was in position.None of those images solved since the
> dome was
>
> > >>>>>>>>>>> in the
>
> > >>>>>>>>>>> way.Again, I can't figure out what I'm doing wrong--it's like
>
> > >>>>>>>>>>> I'm not
>
> > >>>>>>>>>>> even changing the values.Is there another setting that I'm
>
> > >>>>>>>>>>> missing
>
> > >>>>>>>>>>> that enables these timeouts?
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> I'm sure someone else has successfully done an APPM run
> from an
>
> > >>>>>>>>>>> automated dome!What am I missing?
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> Thanks - Shane
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>> --
>
> > >>>>>>>>>>> Shane Ramotowski
>
> > >>>>>>>>>>> kor@...
>
> > >>>>>>>>>>> https://www.kor-astro.net
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>>
>
> > >>>>>>>>>>
>
> > >>>>>>>>>>
>
> > >>>>>>>>>>
>
> > >>>>>>>>>>
>
> > >>>>>>>>> --
>
> > >>>>>>>>> Shane Ramotowski
>
> > >>>>>>>>> kor@...
>
> > >>>>>>>>> https://www.kor-astro.net
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>>>
>
> > >>>>>>> --
>
> > >>>>>>> Shane Ramotowski
>
> > >>>>>>> kor@...
>
> > >>>>>>> https://www.kor-astro.net
>
> > >>>>>>>
>
> > >>>>>>>
>
> > >>>>>>>
>
> > >>>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>>>>
>
> > >>>> --
>
> > >>>> Shane Ramotowski
>
> > >>>> kor@...
>
> > >>>> https://www.kor-astro.net
>
> > >>>>
>
> > >>>>
>
> > >>>>
>
> > >>>>
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >> --
>
> > >> Shane Ramotowski
>
> > >> kor@...
>
> > >> https://www.kor-astro.net
>
> > >>
>
> > >>
>
> > >>
>
> > >>
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> >
>
> > --
>
> > Shane Ramotowski
>
> > kor@...
>
> > https://www.kor-astro.net
>
> >
>
> >
>
> >
>
> >
>
>

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








--