Re: Parking Issue


Steve Reilly
 

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

I do have the zipped log file if that is of any help. It's the usual
files and just the log file for that period and 12.4MBs. I can upload
to Dropbox if you want it.
Go ahead and post the link, but I may not get time to review it until later
today.

For APCC to get into this state, something (an ASCOM client application?)
might have stopped mount tracking in the middle or near the end of the park
operation.

-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 9:07 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Ray,

I do have the zipped log file if that is of any help. It's the usual
files and just the log file for that period and 12.4MBs. I can upload
to Dropbox if you want it.

-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.