Re: Parking Issue


Ray Gralak
 

Craig,

You should switch to asynchronous parks.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Anderson
Sent: Sunday, January 10, 2021 11:34 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Hi Ray,

I connect to my mount using the serial port. I am not currently configured for asynchronous parks.

-Craig

On Jan 10, 2021, at 1:48 PM, Ray Gralak <groups3@gralak.com> wrote:

The likely case is one of those ASCOM applications is sending something to cause the mount to not complete
the park operation while parking.

Are you both using Asynchronous parks in the AP V2 driver? (you should be).

If the Park operation does not complete within a set amount of time (or check for tracking stopped), you could
issue commands to unpark/start tracking/park the mount again.

This should handle the case when some application sends something to the mount.

Craig, are you also using the network to connect to your mount?

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Anderson
Sent: Sunday, January 10, 2021 10:17 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

I’ve had this problem from time to time at my observatory. When it happens for me, the scope is left not
tracking,
pointing up, and ACP Expert reports waiting for the mount to park. If I send the mount to Park manually in
that
situation, the error clears and the roof closes. I have not noticed the “Park” button in APCC greyed out in my
scenario, and APCC is where I click to park the mount. It seems to be a problem for me more frequently
when
the CloseSpecialRoof script executes, so I make sure to avoid opening or imaging when there’s any chance
of
rain at all. My configuration includes AP1600, APCC Pro, AP V2, ACP Expert, MaxIm DL, SkyRoof, AAG
Cloud
Sensor, and an optical @Park monitor.

-Craig



On Jan 10, 2021, at 11:42 AM, Steve Reilly <sreilly24590@centurylink.net> wrote:

Ray,

Have another look at the screen shot and APCC. Does APCC not have Unpark as
being Active choice and Park greyed out (inactive)?

Mike I purposely left it as is for now in case there was a need for remote
login to investigate. In previous occurrences I could indeed park the mount
via the ASCOM Park command but that doesn't help understand the cause of
this situation and offer any solutions so I left it as is after closing the
roof for safety reasons. I had hoped there might be some procedure to try
before resetting things.

-Steve

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 10:51 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Hi Steve,



This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the ASCOM


driver says it's parking, and APCC says it is parked.

Your screenshot shows the mount is unparked, with tracking stopped,
according to APCC.

There's no way to know for sure what happened from a screenshot, but because
the mount is not parked, the driver cannot indicate that the mount has
completed parking.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center):
https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver:
https://www.siriusimaging.com/apdriver



-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of Steve Reilly
Sent: Sunday, January 10, 2021 6:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Parking Issue

This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the
ASCOM driver says it's parking, and APCC says it is parked. I'm
guessing that ACP gets the information from the ASCOM driver so yes,
it actually isn't parked. This is a rare problem but when it happens,
once long enough to have let rain fall on the equipment, it causes
real problems. The mount must be parked before my roof can close so
using a direct close on moisture reading can't work. I had hoped to
find a solution but I don't see this now. The screen capture shows the


roof closed only because I closed it using the close command in AstroMC and
the mount was already in the Park 4 position and had been since 0623. The
last image had downloaded at 0531 and the shutdown script was executed at
0623 if I remember correctly. It was a brief notification from Windows 10
but those were cleared after reading. Not sure if any record is made of
those.


ACP doesn't have a shutdown record as it seems that is made after it
completes which it didn't. If there is a log somewhere else to backup
this event I'm unaware. Maybe APCC can pinpoint the time as it seems to


show the mount parked?





Anyway the issue remains, the roof was wide opened, scope was in the
Park 4 position, my inline Microswitches wired in series were both
closed (continuity signal to the relay) proving a safe position for
the roof to close, the roof was manually directed to close in AstroMC
which it did successfully, and yet ACP still shows the mount as "Parking"


as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC
show the mount at the parked position whereas ACP shows what I assume is the
position it was prior to being commanded to park.


So the question is, where is the log jam and who is responsible for the


stall? How can I prevent this?





I hopefully will have Good Night System fully configured today but
that only notifies me via smart phone of these failures if I set it up


correctly and I have cell signal. It doesn't correct anything. The system is
still in this "Parking"


phase and I'll leave it like that hoping that Bob Denny or other
person has some idea to tracing the problem. I can stop this and power
everything off and start from scratch with a startup script run but
that only puts me back at square 1 and doesn't identify the problem. Is it


a communication issue where a request is sent and waits forever and if so
why can't there be a reasonable time restriction before another request is
sent or other action is taken?





Wide open to ideas/suggestions.



-Steve





















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