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. An occasional error will not cause APCC to switch to serial. It requires multiple failures in a row. And even if it does switch, APCC will not repeat a failed command. This seems to be an unfortunate, intermittent failure on your network. -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 12:04 PM To: main@ap-gto.groups.io Subject: Re: [ap-gto] Parking Issue
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
-----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-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 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
|
At this point I'm trying to move on and get a script registered in Win 10 64 bit that would alert me via smart phone and GNS app but Windows doesn't want to register the script even tough I'm using the SysWow64 version of cmd.exe..... it's, well just hair pulling......and Google is no friend here.
-Steve
toggle quoted messageShow 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 3:18 PM To: main@ap-gto.groups.io Subject: Re: [ap-gto] Parking Issue 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. An occasional error will not cause APCC to switch to serial. It requires multiple failures in a row. And even if it does switch, APCC will not repeat a failed command. This seems to be an unfortunate, intermittent failure on your network. -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 12:04 PM To: main@ap-gto.groups.io Subject: Re: [ap-gto] Parking Issue
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
-----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-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 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
|