Re: APPM with Dome Questions


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

>

>

>

>

 

Join main@ap-gto.groups.io to automatically receive all group messages.