Heads-up on possible abrupt parking problem #APCC #Absolute_Encoders #Mach2GTO


David Johnson
 

I want to describe an issue I’ve had with my Mach2 so that others who might run into it can avoid the frustrations I’ve had.  I want to emphasize that, as with many intermittent issues, it was hard to diagnose and also hard to be sure it’s solved, but, thanks to help from Howard at A-P, I think we have an answer.

I’ll skip some details, but what was happening was that sometimes (and I’d say it was about half the evenings I imaged and randomly occurring), during data acquisition using SGPro and APCC (with tracking correction from an APPM model, although I don’t think that matters), APCC would suddenly just park the mount.  Fortunately, I usually caught this and avoided wasting an entire clear night.  However, you can imagine it was very frustrating because I never knew when it was going to happen, although once it was fixed it never happened again during that night’s work.  This is an important point.

What Howard’s investigation showed was that there was the same amount of time missing (almost three minutes last night, for example) in both the APPC log and the SGPro log.  Once again skipping some details, what I think may have happened is that my MGBox was queried, the system clock for the computer was incorrect and then corrected based on the GPS time from the MGBox, and then APCC thought it had lost communication with the mount for that period of time, which was greater than the default one-minute period,  and did a safety park.  Therefore, once it happens and the clock is correct, it wouldn’t happen again.  An obvious solution is for me to make sure the system clock is correct and/or increase the amount of time before a safety park (although I realize this can increase risk).

I’ll follow-up if the problem persists.  Thanks to Howard and the A-P team for their help with a frustrating problem.


Roland Christen
 

Just to clarify the role that clock time plays: The clock time is only used at the beginning of the session to find a sky object on the RA axis. Once the session has begun, the clock plays no role in pointing or tracking. On the Mach2, the clock time plays no role in the park positions either. So, updating the clock during a session has no benefit whatsoever, and should not be done by external software.

Roland

-----Original Message-----
From: David Johnson <dajohns37@...>
To: main@ap-gto.groups.io
Sent: Mon, Aug 2, 2021 4:20 pm
Subject: [ap-gto] Heads-up on possible abrupt parking problem #Mach2GTO #APCC #Absolute_Encoders

I want to describe an issue I’ve had with my Mach2 so that others who might run into it can avoid the frustrations I’ve had.  I want to emphasize that, as with many intermittent issues, it was hard to diagnose and also hard to be sure it’s solved, but, thanks to help from Howard at A-P, I think we have an answer.

I’ll skip some details, but what was happening was that sometimes (and I’d say it was about half the evenings I imaged and randomly occurring), during data acquisition using SGPro and APCC (with tracking correction from an APPM model, although I don’t think that matters), APCC would suddenly just park the mount.  Fortunately, I usually caught this and avoided wasting an entire clear night.  However, you can imagine it was very frustrating because I never knew when it was going to happen, although once it was fixed it never happened again during that night’s work.  This is an important point.

What Howard’s investigation showed was that there was the same amount of time missing (almost three minutes last night, for example) in both the APPC log and the SGPro log.  Once again skipping some details, what I think may have happened is that my MGBox was queried, the system clock for the computer was incorrect and then corrected based on the GPS time from the MGBox, and then APCC thought it had lost communication with the mount for that period of time, which was greater than the default one-minute period,  and did a safety park.  Therefore, once it happens and the clock is correct, it wouldn’t happen again.  An obvious solution is for me to make sure the system clock is correct and/or increase the amount of time before a safety park (although I realize this can increase risk).

I’ll follow-up if the problem persists.  Thanks to Howard and the A-P team for their help with a frustrating problem.

--
Roland Christen
Astro-Physics


Eric Weiner
 

Very subtle problem. Nice troubleshooting. Thanks for sharing. 


Howard Hedlund
 

Dave's theory was a good theory, but I'm afraid it wasn't correct.   Here was my response to him sent well after his post, so I repeat:  At the time it was a god theory.   The short-term quick-fix is to simply set the park timer to a larger value.  I suggested 5 minutes.  
Response:

I still think something is causing a restart or an extended timeout of your computer.  Have automatic Windows updates been either turned off or else set to a time when you are not imaging?

  • The timekeeper for the park timer is in the GTOCP5 control box, not the computer or APCC.  APCC simply tells the park timer to start its specified countdown.  After that, the mount counts down its time like an egg timer.  If the timer goes off, the mount parks.  It is APCC’s job to keep resetting the timer before it goes off.  The default timer is set for 1 minute, but APCC generally resets it every 8 or 9 seconds, so the countdown never even gets close to going off.
  • The MGBox ‘s GPS times are consistently off by a couple seconds compared to the PC time throughout the log.  Polling occurs every second.  I never found a discrepancy anywhere close to 2 minutes 48 seconds.
  • After initially setting the time in the GTOCP5, there were no corrections to the mount time sent until AFTER the event, and that was a 1 second correction.  If the PC had corrected its time, an equivalent change would have been sent to the mount within a few seconds.  There was no correction sent to the mount. 
  • Computer time was about 2.9 seconds ahead of the MGBox’s GPS time before the glitch (fancy technical term).  It was about 3.4 seconds ahead after the glitch.  That certainly wasn’t a correction to the time.
I am not an expert using Windows Event Viewer, but I would like to see whether it confirms my suspicions.
HH


Bill Long
 

How is the mount being connected to the PC? USB or Ethernet? If it's USB make sure the hub in device manager has the power savings feature turned off. You can do this for all of the connected hubs down in device manager. This is especially important for users of the ultimate powerbox or similar devices. I've seen all kinds of communication errors happen with that option enabled.

Likewise, you can try using Ethernet and seeing if the issue will reproduce.

Bill


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Howard Hedlund <howard@...>
Sent: Monday, August 2, 2021 4:29 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Heads-up on possible abrupt parking problem #Mach2GTO #APCC #Absolute_Encoders
 
Dave's theory was a good theory, but I'm afraid it wasn't correct.   Here was my response to him sent well after his post, so I repeat:  At the time it was a god theory.   The short-term quick-fix is to simply set the park timer to a larger value.  I suggested 5 minutes.  
Response:

I still think something is causing a restart or an extended timeout of your computer.  Have automatic Windows updates been either turned off or else set to a time when you are not imaging?

  • The timekeeper for the park timer is in the GTOCP5 control box, not the computer or APCC.  APCC simply tells the park timer to start its specified countdown.  After that, the mount counts down its time like an egg timer.  If the timer goes off, the mount parks.  It is APCC’s job to keep resetting the timer before it goes off.  The default timer is set for 1 minute, but APCC generally resets it every 8 or 9 seconds, so the countdown never even gets close to going off.
  • The MGBox ‘s GPS times are consistently off by a couple seconds compared to the PC time throughout the log.  Polling occurs every second.  I never found a discrepancy anywhere close to 2 minutes 48 seconds.
  • After initially setting the time in the GTOCP5, there were no corrections to the mount time sent until AFTER the event, and that was a 1 second correction.  If the PC had corrected its time, an equivalent change would have been sent to the mount within a few seconds.  There was no correction sent to the mount. 
  • Computer time was about 2.9 seconds ahead of the MGBox’s GPS time before the glitch (fancy technical term).  It was about 3.4 seconds ahead after the glitch.  That certainly wasn’t a correction to the time.
I am not an expert using Windows Event Viewer, but I would like to see whether it confirms my suspicions.
HH


David Johnson
 

Maybe an extended timeout is possible, but I can't believe it's rebooting.  If I were to reboot or it were to reboot on it's own, it would have to restart SGP and reconnect the focuser, the camera, the filter wheel, and the mount driver in SGP.  It would also have to reset the camera to be at the same temperature it was at previously through SGP.  SGP definitely does not do this automatically. Even APCC does not start automatically, and I don't have it set up to connect to the mount automatically.  All of these I have to do manually when I restart the computer.

I'll try to set it to five minutes for the Safety Park tonight and see what happens.


Ray Gralak
 

Hi David,

Howard is correct. APCC does not cause a safety-park. It's the controller that causes a safety park when APCC does not communicate with it for a period of time. Since both APCC and SGPro show gaps in their logs, it is possible that Windows was frozen temporarily. This can be caused by hardware or software and may be challenging to track down. Here is one link to start researching a solution:

https://answers.microsoft.com/en-us/windows/forum/all/windows-10-randomly-hangsfreezing/18047716-41d4-49dd-a7c0-f15e874a36c8

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Johnson
Sent: Monday, August 2, 2021 6:23 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Heads-up on possible abrupt parking problem #Mach2GTO #APCC

Maybe an extended timeout is possible, but I can't believe it's rebooting. If I were to reboot or it were to reboot on
it's own, it would have to restart SGP and reconnect the focuser, the camera, the filter wheel, and the mount driver
in SGP. It would also have to reset the camera to be at the same temperature it was at previously through SGP.
SGP definitely does not do this automatically. Even APCC does not start automatically, and I don't have it set up to
connect to the mount automatically. All of these I have to do manually when I restart the computer.

I'll try to set it to five minutes for the Safety Park tonight and see what happens.


David Johnson
 

Set the Safety Parking time-out to five minutes last night, and it worked fine.  That doesn't necessarily prove anything, since this problem didn't always happen before.  Anyway, I'll update if it happens again.  Meanwhile, here is a result from the last couple of nights:

https://www.astrobin.com/yxbb24/



Howard Hedlund
 

Nice Iris!  I'm glad you had a good night of imaging.

HH


Tom Blahovici
 

Windows updates frequently resets the USB selective suspend to on. This is in the advanced power settings in the windows control panel.
If the computer is not used interactively then the usb connection will be put in a low power state and it is effectively off. This could be a reason if you are using a usb connection.
Tom


David Johnson
 

I made the USB power management change suggested.  I could see how this might create an issue with the connection between the control box and the computer, but I don’t see how this could explain the almost 3 minute gap in both the APCC and SGP log files.


Bill Long
 

It wouldn't explain those events at all. It's only a config change intended to prevent communication drop outs for USB devices and hubs. I would look in the windows event logs during the times you know there's a gap in the logs and see what was going on with the system.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of David Johnson <dajohns37@...>
Sent: Tuesday, August 3, 2021 11:52 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Heads-up on possible abrupt parking problem #Mach2GTO #APCC #Absolute_Encoders
 
I made the USB power management change suggested.  I could see how this might create an issue with the connection between the control box and the computer, but I don’t see how this could explain the almost 3 minute gap in both the APCC and SGP log files.


David Johnson
 

I'm still having intermittent problems with my Mach2 parking itself.  Today, I was running it inside, just as a test, and it parked itself after several hours of tracking fine, while the driver was connected to Stellarium.  The driver display was strange:



I tried to Unpark, and here is the result.  As you can see, it acts likes it will unpark, but it doesn't and I don't get any kind of error message or other indication of what is wrong.  The only way I can fix the problem is closing and then restarting APCC.  As you can imagine, this is very frustrating when it happens during a night of automated astrophography.  I want to emphasize that this happens out of the blue when I am not doing anything with the mount or the software and after it seems to be tracking fine for some time.


George
 

David,

 

It seems strange that you have COM3 as a virtual port.   How do you have them set up?

 

Regards,

 

George

 

George Whitney

Astro-Physics, Inc.

Phone:  815-222-6538 (direct line)

Phone:  815-282-1513 (office)

Email:  george@...

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of David Johnson
Sent: Thursday, August 19, 2021 3:24 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Heads-up on possible abrupt parking problem #Mach2GTO #APCC

 

I'm still having intermittent problems with my Mach2 parking itself.  Today, I was running it inside, just as a test, and it parked itself after several hours of tracking fine, while the driver was connected to Stellarium.  The driver display was strange:



I tried to Unpark, and here is the result.  As you can see, it acts likes it will unpark, but it doesn't and I don't get any kind of error message or other indication of what is wrong.  The only way I can fix the problem is closing and then restarting APCC.  As you can imagine, this is very frustrating when it happens during a night of automated astrophography.  I want to emphasize that this happens out of the blue when I am not doing anything with the mount or the software and after it seems to be tracking fine for some time.


Ray Gralak
 

Hi David,

 

The blank fields in the driver’s window imply that driver is not communicating with APCC, or that APCC was not communicating with the mount.

 

I can take a look if you use the APCC log zipper utility to zip the APCC and AP V2 driver logs and provide a dropbox, google driver, or other link to this zip file.

 

-Ray

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Johnson
Sent: Thursday, August 19, 2021 1:24 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Heads-up on possible abrupt parking problem #Mach2GTO #APCC

 

I'm still having intermittent problems with my Mach2 parking itself.  Today, I was running it inside, just as a test, and it parked itself after several hours of tracking fine, while the driver was connected to Stellarium.  The driver display was strange:



I tried to Unpark, and here is the result.  As you can see, it acts likes it will unpark, but it doesn't and I don't get any kind of error message or other indication of what is wrong.  The only way I can fix the problem is closing and then restarting APCC.  As you can imagine, this is very frustrating when it happens during a night of automated astrophography.  I want to emphasize that this happens out of the blue when I am not doing anything with the mount or the software and after it seems to be tracking fine for some time.


David Johnson
 


Roland Christen
 

The driver being blank is an indication that you lost communication with the mount. Happened to me when my USB connection failed. When this happens in APCC the handshake is interrupted and the mount automatically parks itself to avoid slowly tracking the scope into the pier (thus avoids pier crash).

Rolando



-----Original Message-----
From: David Johnson <dajohns37@...>
To: main@ap-gto.groups.io
Sent: Thu, Aug 19, 2021 3:23 pm
Subject: Re: [ap-gto] Heads-up on possible abrupt parking problem #Mach2GTO #APCC

I'm still having intermittent problems with my Mach2 parking itself.  Today, I was running it inside, just as a test, and it parked itself after several hours of tracking fine, while the driver was connected to Stellarium.  The driver display was strange:



I tried to Unpark, and here is the result.  As you can see, it acts likes it will unpark, but it doesn't and I don't get any kind of error message or other indication of what is wrong.  The only way I can fix the problem is closing and then restarting APCC.  As you can imagine, this is very frustrating when it happens during a night of automated astrophography.  I want to emphasize that this happens out of the blue when I am not doing anything with the mount or the software and after it seems to be tracking fine for some time.

--
Roland Christen
Astro-Physics


David Johnson
 

Why doesn’t APCC doesn’t tell me there is a communication error when I ask it to park?  Please watch the video.


David Johnson
 

Also, if the driver window is blank because there is no communication with the mount than why is the APCC window still showing the correct mount position?


John Upton
 

David,

   Something in the video is very strange. You seem to have configured APCC to connect directly to the virtual COM port rather than the physical COM port. Note that the physical connection says you are using COM33 and the virtual port is listed as COM3. This is the opposite of what is shown in the APCC User Guide. My APCC is configured to use (TCP Primary and) COM4 which then allows the V2 driver to connect to Port 21. (I followed the setup as in the User Guide.)

   I don't know exactly what happened to get into the configuration you have but I suspect it is related to your communications issues.

   Maybe Ray or a much more experienced APCC user than I can figure out what is wrong and point you to a solution. It might be as easy as to simply select COM3 in the Primary Port box dropdown in the Connection group box just above (assuming the virtual ports are properly configured).


John