|
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
|
|
|
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-proAuthor 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
|
|
|
Mike Dodd
On 1/10/2021 10:51 AM, Ray Gralak wrote: Hi Steve,
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. Steve.... What happens if you click the Park button in the ASCOM driver when the mount is in that situation? Does the driver flash "PARKING" and does the mount move to the specified park position? Just a thought.... --- Mike
|
|
|
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
toggle quoted message
Show quoted text
-----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-proAuthor 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
|
|
|
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
toggle quoted message
Show quoted text
-----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-proAuthor 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
|
|
|
Steve, > Have another look at the screen shot and APCC. Does APCC not have Unpark as > being Active choice and Park greyed out (inactive)? That's not the park status. See this portion of your screenshot: 
-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 8:43 AM > To: main@ap-gto.groups.io > Subject: Re: [ap-gto] Parking Issue > > 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 > > > > > > > > > > > > >
|
|
|
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-proAuthor 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
|
|
|
Thanks Ray, I do indeed stand corrected. But then why is the option to unpark active? That’s confusing. -Steve
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak Sent: Sunday, January 10, 2021 12:15 PM To: main@ap-gto.groups.io Subject: Re: [ap-gto] Parking Issue Steve, > Have another look at the screen shot and APCC. Does APCC not have Unpark as > being Active choice and Park greyed out (inactive)? That's not the park status. See this portion of your screenshot: 
-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 8:43 AM > To: main@ap-gto.groups.io > Subject: Re: [ap-gto] Parking Issue > > 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 > > > > > > > > > > > > >
|
|
|
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.
Ray,Have another look at the screen shot and APCC. Does APCC not have Unpark asbeing Active choice and Park greyed out (inactive)?Mike I purposely left it as is for now in case there was a need for remotelogin to investigate. In previous occurrences I could indeed park the mountvia the ASCOM Park command but that doesn't help understand the cause ofthis situation and offer any solutions so I left it as is after closing theroof for safety reasons. I had hoped there might be some procedure to trybefore resetting things.-Steve-----Original Message-----From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray GralakSent: Sunday, January 10, 2021 10:51 AMTo: main@ap-gto.groups.ioSubject: Re: [ap-gto] Parking IssueHi 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 becausethe mount is not parked, the driver cannot indicate that the mount hascompleted parking.-Ray GralakAuthor of PEMProAuthor of APCC (Astro-Physics Command Center):https://www.astro-physics.com/apcc-proAuthor 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 andthe mount was already in the Park 4 position and had been since 0623. Thelast image had downloaded at 0531 and the shutdown script was executed at0623 if I remember correctly. It was a brief notification from Windows 10but those were cleared after reading. Not sure if any record is made ofthose.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 APCCshow the mount at the parked position whereas ACP shows what I assume is theposition 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 isstill 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 sowhy can't there be a reasonable time restriction before another request issent or other action is taken?
Wide open to ideas/suggestions.
-Steve
|
|
|
toggle quoted message
Show quoted text
-----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-proAuthor 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
|
|
|
Steve, I do indeed stand corrected. But then why is the option to unpark active? That's confusing. It could be that what I mentioned in my previous post: one of the ASCOM applications might have sent a command around the time the park operation was about to complete, putting APCC in an inconsistent state. Which version of APCC are you using? -Ray Gralak Author of PEMPro Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-proAuthor 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:39 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue
Thanks Ray,
I do indeed stand corrected. But then why is the option to unpark active? That's confusing.
-Steve
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 12:15 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue
Steve,
Have another look at the screen shot and APCC. Does APCC not have Unpark as being Active choice and Park greyed out (inactive)?
That's not the park status. See this portion of your screenshot:
-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 8:43 AM To: main@ap-gto.groups.io Subject: Re: [ap-gto] Parking Issue 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
|
|
|
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-proAuthor 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@...> 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
|
|
|
I just checked the driver and I am set for Asynchronous parks (checked). That part about resending I've proven when I see this condition and the mount is in the park position and issued the park command using the ASCOM driver. Re-running the shutdown script in ACP does not seem to work after it's in limbo. I tried that this morning and it simply just sat there saying Parking the Mount.........
I just initiated Park in the driver and it parked as expected, then ran the shutdown script in ACP. While ACP may not have a means to check and resend the park command after a timeout the device I was looking at, Dragonfly, seems to have that ability. We'll see I guess as I'm likely to get one for the new observatory in the spring when I install the dome and get it all set up. It would be nice to find a way to ensure this doesn't happen with the roll off roof which will still be in service after the dome is installed.
-Steve
toggle quoted message
Show quoted text
-----Original Message----- From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak Sent: Sunday, January 10, 2021 1:49 PM To: main@ap-gto.groups.io Subject: Re: [ap-gto] Parking Issue 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-proAuthor 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@...> 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
|
|
|
Craig, I do have the special close script but that’s only used in weather events and I’ve seldom had that problem but it could have the two times I’ve seen this as both time it did rain hours later. This incident was during a normal shutdown at the end of imaging session timed by sunrise in ACP. I can, or have before, hit the park command in the ASCOM driver and it would /did park and finish closing the roof. In this instance not knowing if the active scenario was of any troubleshooting value I simply closed the roof using my roof controller. -Steve
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Craig Anderson Sent: Sunday, January 10, 2021 1:17 PM 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
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
|
|
|
Steve, This is not a problem in APCC. It looks like a network error. The command to park the mount did not reach the mount for some reason: 0366449 2021-01-10 06:28:32.100: Debug, Command Thread, TX = ':KA#' 0366450 2021-01-10 06:28:32.101: Debug, Web Send, --> http://169.254.0.28/cmd.cgi?CMD=%3AKA%23 Timeout(msecs)= 100 0366451 2021-01-10 06:28:32.101: Exception, Web Send, The operation has timed out -Ray Gralak Author of PEMPro Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-proAuthor 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 10:22 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue
This should do it
https://www.dropbox.com/s/v8y72py2yi58xoz/ApccZip-Steven_Reilly-2021-01-10-1
20444.zip?dl=0
-Steve
-----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
|
|
|
Hi Ray,
I connect to my mount using the serial port. I am not currently configured for asynchronous parks.
-Craig
toggle quoted message
Show quoted text
On Jan 10, 2021, at 1:48 PM, Ray Gralak <groups3@...> 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@...> 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
|
|
|
toggle quoted message
Show quoted text
-----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@...> 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@...> 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
|
|
|
Ray,
I’ll make the change to asynchronous park for tonight’s imaging run, and test the CloseSpecialRoof script to see if it behaves better with that setting. Thanks for the tip.
-Craig
toggle quoted message
Show quoted text
On Jan 10, 2021, at 2:42 PM, Ray Gralak <groups3@...> wrote:
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@...> 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@...> 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
|
|
|
Understood yet the mount was in the Park 4, my normal park position, after
an all-night imaging run. ACP was attempting to execute the park command and
shutdown the observatory. I have yet to move the mount other then the park
command issued manually by me via the driver to clear the system hang
waiting since 0623 this morning. The park command had to have been issued
as my last image was that of NGC3718 at 0531 EST.
-Steve
toggle quoted message
Show quoted text
-----Original Message----- From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak Sent: Sunday, January 10, 2021 2:08 PM To: main@ap-gto.groups.io Subject: Re: [ap-gto] Parking Issue Steve, This is not a problem in APCC. It looks like a network error. The command to park the mount did not reach the mount for some reason: 0366449 2021-01-10 06:28:32.100: Debug, Command Thread, TX = ':KA#' 0366450 2021-01-10 06:28:32.101: Debug, Web Send, --> http://169.254.0.28/cmd.cgi?CMD=%3AKA%23 Timeout(msecs)= 100 0366451 2021-01-10 06:28:32.101: Exception, Web Send, The operation has timed out -Ray Gralak Author of PEMPro Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-proAuthor 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 10:22 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue
This should do it
https://www.dropbox.com/s/v8y72py2yi58xoz/ApccZip-Steven_Reilly-2021-0
1-10-1
20444.zip?dl=0
-Steve
-----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
|
|
|
Should have mentioned that this is a CP4 and I do use the ETHERNET
connection but the computer is in the observatory so I'm guessing it is
seeing the IP address of the CP4 and if that failed for some reason it would
have gone to the serial connection but that also doesn't seem to have been
an issue as far as I can see.
-Steve
toggle quoted message
Show quoted text
-----Original Message----- From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak Sent: Sunday, January 10, 2021 2:08 PM To: main@ap-gto.groups.io Subject: Re: [ap-gto] Parking Issue Steve, This is not a problem in APCC. It looks like a network error. The command to park the mount did not reach the mount for some reason: 0366449 2021-01-10 06:28:32.100: Debug, Command Thread, TX = ':KA#' 0366450 2021-01-10 06:28:32.101: Debug, Web Send, --> http://169.254.0.28/cmd.cgi?CMD=%3AKA%23 Timeout(msecs)= 100 0366451 2021-01-10 06:28:32.101: Exception, Web Send, The operation has timed out -Ray Gralak Author of PEMPro Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-proAuthor 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 10:22 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue
This should do it
https://www.dropbox.com/s/v8y72py2yi58xoz/ApccZip-Steven_Reilly-2021-0
1-10-1
20444.zip?dl=0
-Steve
-----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
|
|
|
