Date   

Re: USB and cold weather

 

On the topic of through mount USB3 and USB2. 


USB 2.0 will work just fine, for a number of reasons. Most notably, there is far less communication actually happening between device and host, at a far lower speed, with far less 'protocol' communication. With most devices on the market, this is all you will ever need, and I could not make it fail in testing. 


USB 3.0 is more tricky. As Roland mentioned in the thread, signal will bounce off of interfaces at the frequencies of USB 3.0, echoing in the line. The best way to deal with this is to ensure the least number of interfaces and shortest wire path between powered USB 3.0 ports. In the Mach 2 manual, we make some suggestions for USB 3.0 configurations that I have tested and can confirm to work perfectly. They all come down to having some kind of booster or powered hub right at the connector at the base of the mount, and a powered hub at the top of the mount. The internal cable is very high quality, but no amount of quality can prevent interface reflections. 


An easy way to test your USB 3.0 setup is to get a USB 3.0 hard drive, and set it at the top of the mount. You can then use a USB speed tester program to see what quality of data transfer you get. I used USB Flash Benchmark with very good results. If the test fails, or Windows has a hard time detecting the hard drive, it means that the cables are too noisy to do proper communications and you need to reduce the cable length/connector interfaces between powered USB ports. 


Liam Plybon
Astro-Physics



From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Brian Valente <bvalente@...>
Sent: Monday, January 11, 2021 2:26 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] USB and cold weather
 
>>>....when we had live bands at my bar. 

Howard, you buried the lead here, interesting to know this about you :)



On Mon, Jan 11, 2021 at 12:10 PM Howard Hedlund <howard@...> wrote:
We have had pretty good results with the DeoxIT line of products for contact cleaning and moisture protection.  I first saw DeoxIT D5 many years ago when we had live bands at my bar.  The band roadies swore by the stuff. 
https://caig.com/
The D5 is a great general purpose contact cleaner, and they have several products that create barriers to condensation.  I'm not current on their latest and greatest, but you might want to give their products a look-see.



--
Brian 



Brian Valente


Re: USB and cold weather

 

>>>....when we had live bands at my bar. 

Howard, you buried the lead here, interesting to know this about you :)



On Mon, Jan 11, 2021 at 12:10 PM Howard Hedlund <howard@...> wrote:
We have had pretty good results with the DeoxIT line of products for contact cleaning and moisture protection.  I first saw DeoxIT D5 many years ago when we had live bands at my bar.  The band roadies swore by the stuff. 
https://caig.com/
The D5 is a great general purpose contact cleaner, and they have several products that create barriers to condensation.  I'm not current on their latest and greatest, but you might want to give their products a look-see.



--
Brian 



Brian Valente


Re: USB and cold weather

Howard Hedlund
 

We have had pretty good results with the DeoxIT line of products for contact cleaning and moisture protection.  I first saw DeoxIT D5 many years ago when we had live bands at my bar.  The band roadies swore by the stuff. 
https://caig.com/
The D5 is a great general purpose contact cleaner, and they have several products that create barriers to condensation.  I'm not current on their latest and greatest, but you might want to give their products a look-see.


Re: AP1600 autoguiding gone bad

Howard Hedlund
 

The GTOCP3 can be used with APCC as long as it has the latest V2 ROM chip.  Of course, the GTOCP4 has all the latest bells and whistles, and will take advantage of all the features that APCC can offer.


Re: APCC Pro version update

Ray Gralak
 

Greg,

As I have said several times before, APCC is a .Net application and thus depends on the .Net Framework. If your system has a problematic version of .Net Framework, there may be a bug that needs to be patched. Other apps that were mentioned, like PHD2, are not .Net framework apps.

It could also be that when you first installed and ran APCC, you did not allow APCC to communicate by canceling the firewall popup message. If you do not allow APCC to communicate, it will be blocked.

-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 Greg McCall
Sent: Sunday, January 10, 2021 8:02 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC Pro version update

On Mon, Jan 11, 2021 at 07:11 AM, Ray Gralak wrote:


Which again implies that something is blocking APCC on your computer. There's no difference in APCC's
code between your computer and others that work.

While I agree something is blocking APCC's code and no difference between APCC on each computer
(assuming the same version), APCC must be doing something different to other applications because it behaves
differently on the same computer that has applications that access some version data.

The question is what difference and how were those applications able to be installed or access some OS code to
enable them to reach some external site without an issue?
(or do other applications also have issues?)

I also have other apps that can get version data on two computers that all work except on one of my computers,
APCC doesn't work.

I wonder what the difference is and how to get around it as I set up both computers and keep them both updated
to the same level although they are both different brands of computer and thus, have underlying differences in
the OS configuration. When I get some more time I'll try and poke around more but not being a programmer and
using tools like wireshark way too many years ago, I'm not liking my chances in working it out soon.


Re: APCC Pro version update

Greg McCall
 

On Mon, Jan 11, 2021 at 07:11 AM, Ray Gralak wrote:
Which again implies that something is blocking APCC on your computer. There's no difference in APCC's code between your computer and others that work.
While I agree something is blocking APCC's code and no difference between APCC on each computer (assuming the same version), APCC must be doing something different to other applications because it behaves differently on the same computer that has applications that access some version data.

The question is what difference and how were those applications able to be installed or access some OS code to enable them to reach some external site without an issue?
(or do other applications also have issues?)

I also have other apps that can get version data on two computers that all work except on one of my computers, APCC doesn't work.

I wonder what the difference is and how to get around it as I set up both computers and keep them both updated to the same level although they are both different brands of computer and thus, have underlying differences in the OS configuration. When I get some more time I'll try and poke around more but not being a programmer and using tools like wireshark way too many years ago, I'm not liking my chances in working it out soon.


Re: AP1600 autoguiding gone bad

Greg Bradley
 

Update:
turns out my tpoint us giving me a bum polar alignment.
I used Pempro polar alignment wizard to check the polar alignment as I was getting a lot of drift.

my polar alignment was waaayyy off. Corrected it using Pempro and got some imaging done.

I’ll have to check into what happened with tpoint being so off.

Tume to switch to APCC. Does it work with CP3 or only CP4? Is there hone switch upgrade available for the AP1600?

Greg


Re: USB and cold weather

Dominique
 

So I protected (DIY with foam) all USB3 contactors and tonight, with still 30 ° F I have no problems with my QHY294c and my complete installation as described.
I will try to improve his protections even further.
Dominique


Re: USB and cold weather

Micheal Fields Jr
 

All my hubs are 12v powered.  And I have been only using one hub until the test.


Re: USB and cold weather

Micheal Fields Jr
 

That was just an experiment to see what would break first.   The idea being that if the worse case senario works but it still doesn't work through the mount, then I have isolated the problem.   Also as Roland mentioned, maybe having extra power and signal integrity before it goes through the mount and after it goes through the mount will provide a more stable situation.  So that is why I experimented indoors with using two hubs.  That is not how I have been doing it up until then.  I was just testing ideas. 


Re: Parking Issue

Steve Reilly
 

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

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

























Re: Parking Issue

Ray Gralak
 

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

























Re: APCC Pro version update

Ray Gralak
 

Hi Marcelo,

Also APCC is able to connect to the internet and get weather data from openweathermap.org.
Sorry, but APCC does not directly connect to openwathermap.org. That is done through a separate ASCOM driver running in its own application space.

And just to test, I made the test with other applications like SharpCap and PHD2 and both are able to show if
there are new versions available.
Which again implies that something is blocking APCC on your computer. There's no difference in APCC's code between your computer and others that work.

-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 Marcelo Figueroa via groups.io
Sent: Sunday, January 10, 2021 11:58 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC Pro version update


I just noticed the same issue, the box to show the latest available version of APCC Pro is blank (and I made sure
that APCC Pro is in the list of applications allowed by the windows firewall).

Also APCC is able to connect to the internet and get weather data from openweathermap.org.

And just to test, I made the test with other applications like SharpCap and PHD2 and both are able to show if
there are new versions available.


Re: Parking Issue

Steve Reilly
 

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

















Re: Parking Issue

Steve Reilly
 

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

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

















Re: APCC Pro version update

Marcelo Figueroa
 


I just noticed the same issue, the box to show the latest available version of APCC Pro is blank (and I made sure that APCC Pro is in the list of applications allowed by the windows firewall).
 
Also APCC is able to connect to the internet and get weather data from openweathermap.org. 
 
And just to test, I made the test with other applications like SharpCap and PHD2 and both are able to show if there are new versions available.
 


Re: Parking Issue

Craig Anderson
 

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

On Jan 10, 2021, at 2:42 PM, Ray Gralak <groups3@gralak.com> 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@gralak.com> wrote:

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

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

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

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

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

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


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

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

-Craig



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

Ray,

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

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

-Steve

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

Hi Steve,



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


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

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

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

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



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

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


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


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


show the mount parked?





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


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


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


stall? How can I prevent this?





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


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


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


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





Wide open to ideas/suggestions.



-Steve



























Re: Parking Issue

Ray Gralak
 

Craig,

You should switch to asynchronous parks.

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

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

Hi Ray,

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

-Craig

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

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

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

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

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

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

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


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

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

-Craig



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

Ray,

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

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

-Steve

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

Hi Steve,



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


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

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

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

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



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

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


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


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


show the mount parked?





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


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


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


stall? How can I prevent this?





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


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


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


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





Wide open to ideas/suggestions.



-Steve






















Re: Parking Issue

Craig Anderson
 

Hi Ray,

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

-Craig

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

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

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

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

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

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

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


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

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

-Craig



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

Ray,

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

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

-Steve

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

Hi Steve,



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


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

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

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

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



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

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


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


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


show the mount parked?





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


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


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


stall? How can I prevent this?





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


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


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


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





Wide open to ideas/suggestions.



-Steve




















Re: Parking Issue

Ray Gralak
 

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
















2841 - 2860 of 78398