Pier Crash - need help diagnosing #ASCOM_V2_Driver


Joel Short
 

I have an AP1100GTO CP4 and use the ASCOM driver for mount control, with SGP and PHD2.  Last night I had a pier crash and it is really puzzling as to what happened and I could use some help figuring it out.  The guide star was lost around 11:10pm and for some reason SGP recovery didn’t work properly. The really strange thing is that the scope was on the EAST side of the pier pointing down at the ground, but pointing on the west side of the pier. If the scope was tracking properly it would have just continued moving west, so something strange happened to to cause the scope to crash into the EAST side of the pier. Another strange thing is that the AP1100 ASCOM driver reported that the scope was parked this morning.
 
I also have Mount Watcher activated to shut down the mount if it gets too far past the meridian or too far CW up. That failed as well. I really have no clue what caused this.  Here is a link to the ASCOM_V2_Driver log.  Any ideas as to what happened would be appreciated.  
joel


Roland Christen
 

It appears that the scope tracked past the meridian and continued until it was past the west side upside down. Apparently you do not have the limits turned on, so there is nothing that would stop the mount from continuing on its way.

Since the scope is now underneath the mount, I strongly suggest that you return the RA axis by either slewing or manually (clutches loose) bring the RA axis back, in counterclockwise rotation, to counterweight down position. Place the scope in Park3 and re-start the mount from Park3.

If you continue to rotate the RA axis clockwise, you will most likely twist the internal motor-encoder cables, which will eventually damage them if you allow the mount to rotate clockwise past the lowest point again and again.

I strongly urge you to NOT turn off the internal limits so that the mount cannot continue past the meridian indefinitely, especially if you are not there to catch the problem.

Roland Christen
Astro-Physics Inc.



-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 1:11 pm
Subject: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

I have an AP1100GTO CP4 and use the ASCOM driver for mount control, with SGP and PHD2.  Last night I had a pier crash and it is really puzzling as to what happened and I could use some help figuring it out.  The guide star was lost around 11:10pm and for some reason SGP recovery didn’t work properly. The really strange thing is that the scope was on the EAST side of the pier pointing down at the ground, but pointing on the west side of the pier. If the scope was tracking properly it would have just continued moving west, so something strange happened to to cause the scope to crash into the EAST side of the pier. Another strange thing is that the AP1100 ASCOM driver reported that the scope was parked this morning.
 
I also have Mount Watcher activated to shut down the mount if it gets too far past the meridian or too far CW up. That failed as well. I really have no clue what caused this.  Here is a link to the ASCOM_V2_Driver log.  Any ideas as to what happened would be appreciated.  
joel


Joel Short
 

Thanks Roland.  I have already brought the mount back with a CCW rotation, and restarted the mount just to make sure the motors and everything still worked properly (which it does).  But I'm having trouble conceptualizing how the mount and telescopes got into the position they did.  My target (Sh2-132) had crossed the meridian at 10:10pm and a pier flip occurred successfully. Everything was fine until 11:10pm when the guide star was lost. So if the mount had simply kept on tracking the pier crash would have occurred on the other side of the pier.  

I do not use APCC and it was my understanding that the ASCOM driver does not have limits available.  A year or two ago I had a pier crash and at that time I argued that limits are a basic necessity and should be included with the ASCOM driver itself.  At that time I started using Mount Watcher to prevent the mount from tracking too far past the meridian and I had tested it to make sure it worked, but for some reason it did not prevent this event.  

I don't believe that this would have happened if the guide star had not been lost, which started a cascade of events that led to this.  However I though I had protections in place to prevent it.  


Roland Christen
 


But I'm having trouble conceptualizing how the mount and telescopes got into the position they did.  My target (Sh2-132) had crossed the meridian at 10:10pm and a pier flip occurred successfully. Everything was fine until 11:10pm when the guide star was lost. So if the mount had simply kept on tracking the pier crash would have occurred on the other side of the pier. 
It looks like the pier flip did not occur and the mount continued with counterweight up position. It's possible that the program that sent the pier flip command did not actually send it to the driver, or the driver did not receive it. You should check the driver log at the time you think the flip command was sent and see if it was received.

The CP4 has the ability to have limits set without using APCC.

Rolando

-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 2:21 pm
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

Thanks Roland.  I have already brought the mount back with a CCW rotation, and restarted the mount just to make sure the motors and everything still worked properly (which it does).  But I'm having trouble conceptualizing how the mount and telescopes got into the position they did.  My target (Sh2-132) had crossed the meridian at 10:10pm and a pier flip occurred successfully. Everything was fine until 11:10pm when the guide star was lost. So if the mount had simply kept on tracking the pier crash would have occurred on the other side of the pier.  

I do not use APCC and it was my understanding that the ASCOM driver does not have limits available.  A year or two ago I had a pier crash and at that time I argued that limits are a basic necessity and should be included with the ASCOM driver itself.  At that time I started using Mount Watcher to prevent the mount from tracking too far past the meridian and I had tested it to make sure it worked, but for some reason it did not prevent this event.  

I don't believe that this would have happened if the guide star had not been lost, which started a cascade of events that led to this.  However I though I had protections in place to prevent it.  


Joel Short
 

It looks like the pier flip did not occur and the mount continued with counterweight up position. It's possible that the program that sent the pier flip command did not actually send it to the driver, or the driver did not receive it. You should check the driver log at the time you think the flip command was sent and see if it was received.
The pier flip definitely happened.  Images before and after are flipped.  I suck at reading logs.  According to the SGP log the meridian flip was called for at 22:08:03  (about 1min after the target crossed).  I tried looking at the ASCOM  driver log at that time but I don't know what I'm looking for and didn't see anything obvious one way or the other.

The CP4 has the ability to have limits set without using APCC.
Good to know.  I'll have to figure out how to do that.  With the understand that I generally do not track past the meridian but do a flip within 30min past, do you have a recommendation for what values to set for limits?

Thanks again Roland, I always appreciate knowing that the owner is active on this forum and willing to share your wealth of knowledge.
joel


Howard Hedlund
 

Hi Joel,

Please send me your ASCOM log file from last night.  I'm going to make an educated guess here:  Do you use Park 2 as your park position?


Roland Christen
 

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened.

Roland



-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 3:21 pm
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

It looks like the pier flip did not occur and the mount continued with counterweight up position. It's possible that the program that sent the pier flip command did not actually send it to the driver, or the driver did not receive it. You should check the driver log at the time you think the flip command was sent and see if it was received.
The pier flip definitely happened.  Images before and after are flipped.  I suck at reading logs.  According to the SGP log the meridian flip was called for at 22:08:03  (about 1min after the target crossed).  I tried looking at the ASCOM  driver log at that time but I don't know what I'm looking for and didn't see anything obvious one way or the other.

The CP4 has the ability to have limits set without using APCC.
Good to know.  I'll have to figure out how to do that.  With the understand that I generally do not track past the meridian but do a flip within 30min past, do you have a recommendation for what values to set for limits?

Thanks again Roland, I always appreciate knowing that the owner is active on this forum and willing to share your wealth of knowledge.
joel


Joel Short
 

Please send me your ASCOM log file from last night.  I'm going to make an educated guess here:  Do you use Park 2 as your park position?
The ASCOM log was linked to in the original post, but here it is again:  ASCOM LOG.  
Actually I use Park 5.

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened.
Interesting.  I did have another target that was supposed to begin at 02:00, but I thought the imaging sequence ended around 00:35 with an abort.  Perhaps that flip tried to happen again at 02:00.
joel


Roland Christen
 

Howard will check your log. It will show all the commands that were sent.

Rolando



-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 3:54 pm
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

Please send me your ASCOM log file from last night.  I'm going to make an educated guess here:  Do you use Park 2 as your park position?
The ASCOM log was linked to in the original post, but here it is again:  ASCOM LOG.  
Actually I use Park 5.

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened.
Interesting.  I did have another target that was supposed to begin at 02:00, but I thought the imaging sequence ended around 00:35 with an abort.  Perhaps that flip tried to happen again at 02:00.
joel


Roland Christen
 

If the second object was almost but not quite at the meridian, the mount would have acquired it with scope on the west side, then continued tracking until the scope was under the mount. That's assuming no further flip command was sent. It would explain the position of the scopes in the morning.

Rolando



-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 3:54 pm
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

Please send me your ASCOM log file from last night.  I'm going to make an educated guess here:  Do you use Park 2 as your park position?
The ASCOM log was linked to in the original post, but here it is again:  ASCOM LOG.  
Actually I use Park 5.

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened.
Interesting.  I did have another target that was supposed to begin at 02:00, but I thought the imaging sequence ended around 00:35 with an abort.  Perhaps that flip tried to happen again at 02:00.
joel


Roland Christen
 

Hi Joel,

Ray Gralack looked at your ASCOM log and discovered that the mount was sent a sync to a negative Dec number (-55 Dec instead of +55). Doing so caused the scope to subsequently dive under the mount when the park command was sent.

If your command program had been connected to APCC instead of the mount directly thru the driver, then that errant sync would have been flagged and prevented from getting thru. It's one of many safety features of APCC. You would also be able to set limits easily, so that pier crashes would not occur. The basic APCC is all you need to protect those delicious scopes on that mount, Pro version is optional.

Rolando


-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 3:54 pm
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

Please send me your ASCOM log file from last night.  I'm going to make an educated guess here:  Do you use Park 2 as your park position?
The ASCOM log was linked to in the original post, but here it is again:  ASCOM LOG.  
Actually I use Park 5.

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened.
Interesting.  I did have another target that was supposed to begin at 02:00, but I thought the imaging sequence ended around 00:35 with an abort.  Perhaps that flip tried to happen again at 02:00.
joel


Joel Short
 

On Tue, Oct 6, 2020 at 05:13 PM, uncarollo2 <chris1011@...> wrote:
Ray Gralack looked at your ASCOM log and discovered that the mount was sent a sync to a negative Dec number (-55 Dec instead of +55). Doing so caused the scope to subsequently dive under the mount when the park command was sent.
Thanks Ray and Roland.  The target (Sh2-132) has a Dec of +55.  My guess is that after the guide star was lost and then 45min later re-acquired, SGP tried to plate solve and re-center on the target.  But for some reason issued a -55 Dec instead of +55.  This is well beyond my understanding of why that would have happened.  
joel


Konstantin von Poschinger
 

Hi Joel,

is there a log file in SGP. There it will be documented.

Konstantin


Konstantin v. Poschinger

Hammerichstr. 5
22605 Hamburg
040/8805747
0171 1983476

Am 07.10.2020 um 00:37 schrieb Joel Short <buckeyestargazer@...>:

On Tue, Oct 6, 2020 at 05:13 PM, uncarollo2 <chris1011@...> wrote:
Ray Gralack looked at your ASCOM log and discovered that the mount was sent a sync to a negative Dec number (-55 Dec instead of +55). Doing so caused the scope to subsequently dive under the mount when the park command was sent.
Thanks Ray and Roland.  The target (Sh2-132) has a Dec of +55.  My guess is that after the guide star was lost and then 45min later re-acquired, SGP tried to plate solve and re-center on the target.  But for some reason issued a -55 Dec instead of +55.  This is well beyond my understanding of why that would have happened.  
joel


Joel Short
 

Looking at the SGP log file, after the guide star was re-acquired by PHD2 SGP attempted to take and image and plate solve to determine where the mount was.  The primary plate solver failed (ASTAP), so the blind solver attempted to solve the reference image (ANSVR - local astrometry.net).  The solve came back as successful, but almost all of the parameters were incorrect.  The Dec was -54.9, the RA was 16 (should have been 22), the camera angle was 302 (should be 0 or 180).  The pixel scale was correct.  Then after the "successful" solve, SGP issue a move to go to the target (+55 Dec, +22 RA).  Which of course resulted in the craziness.
joel


Eric M
 

"The CP4 has the ability to have limits set without using APCC."

How is this done? I don't see anything in the CP4 manual about it.


Joel Short
 

On Tue, Oct 6, 2020 at 10:50 PM, Eric M wrote:
"The CP4 has the ability to have limits set without using APCC."

How is this done? I don't see anything in the CP4 manual about it.
I'm curious about this too.  I couldn't find any way to do this either.  
joel


Eric M
 

Can anyone comment on Rolando's statement on setting limits on the CP4 without APCC? Is this possible? It would be incredibly useful in case of a computer crash or software glitch.


Roland Christen
 


Can anyone comment on Rolando's statement on setting limits on the CP4 without APCC? Is this possible? It would be incredibly useful in case of a computer crash or software glitch.


Roland Christen
 


"Can anyone comment on Rolando's statement on setting limits on the CP4 without APCC? Is this possible? It would be incredibly useful in case of a computer crash or software glitch"

Answer:
I am working on it. We have a software command now that will set the limit at 5 degrees past the meridian in the CP4. It's a simple command that can be sent via the AP Terminal Command Interface. The command will also be in the new release of the keypad software. At the present time we are debating whether to make the 5 degree window variable, but it has not yet been decided.

There are caveats, however. In a non-encoder mount this limit depends on the hour angle being correct, so if the user does a bad recal (example: recal on Vega when pointing at Betelgeuse), then the hour angle is thrown off course, and this will affect the where the limit is applied. Another example is entering 2:00:00 for time when it really is 1400 hours and the entry should have been 14:00:00. Or entering -6 for time zone when it should have been +6. None of this is an issue for one of our Absolute Encoder mounts, such as the Mach2, because the limit is tied to an actual encoder angle that is invariant, regardless of mistakes in time, date, location or recal entries.

So, if you have your whits about you and are certain that the mount is set up correctly, then sending the limit command will indeed stop the mount at 5 degrees past the meridian. If not, then we will get lots of customer service calls with mounts that don't appear to track (because they are past the limit) and the user has no clue that this is the reason (because he forgot that the limit was set).

Rolando


-----Original Message-----
From: Eric M <eric.marlatt@...>
To: main@ap-gto.groups.io
Sent: Mon, Oct 26, 2020 8:20 am
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

Can anyone comment on Rolando's statement on setting limits on the CP4 without APCC? Is this possible? It would be incredibly useful in case of a computer crash or software glitch.


Jeffc
 

On Oct 26, 2020, at 8:54 AM, uncarollo2 <chris1011@aol.com> via groups.io <chris1011=aol.com@groups.io> wrote:

So, if you have your whits about you and are certain that the mount is set up correctly,
For the non-encoder mounts, could this command have a “manual verify” feature?

Eg after mount startup a slew is done and if it stops then the user knows the command is setup properly. If it doesn’t stop then the user can stop it.
But yes.. I can also see where even this “verify” seems like an opportunity for lots of support calls/emails.

-jeff