Date   

Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

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


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

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


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

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


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

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?


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

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


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

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.  


Satellite Tracking

Dean Jacobsen
 

Is anyone using their mount for satellite tracking?  I am starting to go through the Horizons manual.  I am interested in amateur radio satellite tracking in particular.
--
Dean Jacobsen
http://astrophoto.net/wp/
Image Gallery - http://astrophoto.net/wp/image-gallery/
Astrobin Image Gallery - https://www.astrobin.com/users/deanjacobsen/ 
Amateur Radio Call Sign - W6DBJ


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

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.  


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

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


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


Re: APPM Questions

Ray Gralak
 

Hi Shane,

How does APPM send the telescope's destination coordinates to the Dome
driver? Does it do that though ASCOM?
Yes, through ASCOM, but as I alluded to, the API is lacking. It does not provide the dome with enough information to calculate position.

In Active mode, APPM first checks if the driver can accept SendToAzimuth and/or SendToAltitude. Assuming it can APPM will convert the telescope's destination RA/Dec to Azimuth/Altitude and issue the dome driver's SlewToAzimuth() and SlewToAltitude() methods.

In Passive mode, APPM does not issue any moves directly to the dome driver. However, APPM monitors the "Slewing" property to determine when the dome has completed movement. APPM also does this in it's Active mode as well.

The problem with the ASCOM Dome interface is that it doesn't provide enough information to the dome driver. What the dome driver needs are:

1) The telescope's destination RA/Dec.
2) The mount's destination pier side.
3) In case of a multiple scope setup, which telescope (or telescopes) to center the dome opening.

-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 Shane Ramotowski
Sent: Tuesday, October 6, 2020 5:37 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Questions

Hi Ray,

I'm currently working on motorizing my dome and am in the middle of
testing my newly written ASCOM driver and want to make sure that I can
support APPM.

How does APPM send the telescope's destination coordinates to the Dome
driver? Does it do that though ASCOM?

This is my first ASCOM driver, so I'm likely missing something or
misunderstanding something, but I don't see any ASCOM methods that would
work for sending telescope coordinates. Is it done though a custom
command in Action(), CommandBlind(), CommandBool(), or CommandString()?
I know about the CanSlave property, but as I understand it, that is for
a hardware (external to DOME driver) solution.

Thanks - Shane

On 10/5/2020 8:56 PM, Ray Gralak wrote:
Tony,

APPM sends the telescope's destination coordinates to the Dome driver that to which APPM is configured. IMO
the Dome driver should be intelligent enough to figure out where the telescope is heading and move the dome
there. I would say it is up to the Dome driver developer to make this work. I would say you should talk to the
NexDome manufacturer to see what suggestions they have.

Also, I have been on and off working on a generic cross-platform dome driver. At the rate it's been going, it may
be months away from when I can complete it, but the intent is to fix some of the bad decisions (in hindsight) made
by ASCOM in the API design. (Then I would have to convince application developers to implement what is
essentially a superset of ASCOM.)

-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 Tony Benjamin
Sent: Monday, October 5, 2020 7:42 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Questions

Ray,

Is my understanding on this whole process more or less correct?:



* as soon as I hit "Start" for the APPM run that first RA/Dec (Zenith) is sent to SGP (assuming I'm using SGP
for dome movement);
* SGP does the math required to figure out what Azimuth to send the dome to (should take like a Nano
second - it is a computer after all); and
* that Azimuth position is then sent to the Nexdome driver which then actually has the dome move?

Is that the way things should work? If so, then I would be guessing that the Nexdome driver may be the real
issue
in all this?





--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net




Re: APPM Questions

Shane Ramotowski
 

Hi Ray,

I'm currently working on motorizing my dome and am in the middle of testing my newly written ASCOM driver and want to make sure that I can support APPM.

How does APPM send the telescope's destination coordinates to the Dome driver?  Does it do that though ASCOM?

This is my first ASCOM driver, so I'm likely missing something or misunderstanding something, but I don't see any ASCOM methods that would work for sending telescope coordinates.  Is it done though a custom command in Action(), CommandBlind(), CommandBool(), or CommandString()?  I know about the CanSlave property, but as I understand it, that is for a hardware (external to DOME driver) solution.

Thanks - Shane

On 10/5/2020 8:56 PM, Ray Gralak wrote:
Tony,

APPM sends the telescope's destination coordinates to the Dome driver that to which APPM is configured. IMO the Dome driver should be intelligent enough to figure out where the telescope is heading and move the dome there. I would say it is up to the Dome driver developer to make this work. I would say you should talk to the NexDome manufacturer to see what suggestions they have.

Also, I have been on and off working on a generic cross-platform dome driver. At the rate it's been going, it may be months away from when I can complete it, but the intent is to fix some of the bad decisions (in hindsight) made by ASCOM in the API design. (Then I would have to convince application developers to implement what is essentially a superset of ASCOM.)

-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 Tony Benjamin
Sent: Monday, October 5, 2020 7:42 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Questions

Ray,

Is my understanding on this whole process more or less correct?:



* as soon as I hit "Start" for the APPM run that first RA/Dec (Zenith) is sent to SGP (assuming I'm using SGP
for dome movement);
* SGP does the math required to figure out what Azimuth to send the dome to (should take like a Nano
second - it is a computer after all); and
* that Azimuth position is then sent to the Nexdome driver which then actually has the dome move?

Is that the way things should work? If so, then I would be guessing that the Nexdome driver may be the real issue
in all this?




--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Re: APPM Questions

Tony Benjamin <tonybenjamin@...>
 

Thanks Ray,

I appreciate your patience in this thread. I know its a small niggly thing. Appreciate everything you've done.

Cheers


Re: APPM Questions

Ray Gralak
 

Tony,

APPM sends the telescope's destination coordinates to the Dome driver that to which APPM is configured. IMO the Dome driver should be intelligent enough to figure out where the telescope is heading and move the dome there. I would say it is up to the Dome driver developer to make this work. I would say you should talk to the NexDome manufacturer to see what suggestions they have.

Also, I have been on and off working on a generic cross-platform dome driver. At the rate it's been going, it may be months away from when I can complete it, but the intent is to fix some of the bad decisions (in hindsight) made by ASCOM in the API design. (Then I would have to convince application developers to implement what is essentially a superset of ASCOM.)

-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 Tony Benjamin
Sent: Monday, October 5, 2020 7:42 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Questions

Ray,

Is my understanding on this whole process more or less correct?:



* as soon as I hit "Start" for the APPM run that first RA/Dec (Zenith) is sent to SGP (assuming I'm using SGP
for dome movement);
* SGP does the math required to figure out what Azimuth to send the dome to (should take like a Nano
second - it is a computer after all); and
* that Azimuth position is then sent to the Nexdome driver which then actually has the dome move?

Is that the way things should work? If so, then I would be guessing that the Nexdome driver may be the real issue
in all this?


Re: regreasing old ap 900 gto

Steven Panish
 

Vincent,

The AP grease kit is not on their website, you have to call them for it, but I would think you could also get it from their European distributor.  The kit includes good instructions.  You will also need the "gear mesh" instructions available on the AP website.

The kit includes two kinds of grease, one for the worm and worm gear, and another for all the spur gears.  If you want to use commercially available grease AP could advise you.

Steve

On Mon, Oct 5, 2020 at 3:29 PM CurtisC via groups.io <calypte=verizon.net@groups.io> wrote:
You can buy a grease kit from Astro-Physics. 


Re: APPM Questions

Tony Benjamin <tonybenjamin@...>
 

Think I'm slowly getting a grip on the main issue here. If I'm slewing the scope from within SGP then there is no delay - the scope and dome move together in beautiful harmony. But once an outside party (APPM) is issuing the slew command SGP has to sit idly by until that slew is complete as it doesn't know where the scope/mount is going to end up? Heres the way Jared from SGP put it:

SGP will do “pre-emptive” slews when SGP issues the slew or when the slew comes from the API. If something else is issuing the slew then SGP has to react to it since the slew is done without our notification…what’s worse is that SGP doesn’t know where the slew was commanded to go (we just see RA/Dec changing) so we have to wait until the slew is complete and then we can move the dome accordingly. I’m assuming since APPM talks directly to the mount that it is issuing the slew without SGP’s knowledge.

To enable pre-emptive dome slews without scope slews we’d need to create something on the API side that would allow external applications to send us the coordinates for the slew but not actually do the slew in SGP. Or to allow this now the application could invoke the slew through SGP which would then handle the slaving correctly.

Jared


Re: APPM Questions

Tony Benjamin <tonybenjamin@...>
 

So heres what the dome looks like now with the new APPM ver. It all works and probably won't get any fails. What I would really, really like is to find out who/how can get the dome to move in time with the mount - instead of just sitting there??

https://www.youtube.com/watch?v=5Ao9ko5feII&ab_channel=TonyBenjamin


Re: Mach1 play in RA Axis - did not adjust out with Gear Mesh adjustment

John Davis
 

Hi Rowland - 
   Hope you didn't lose any sleep over this issue!  Thanks for the additional idea and detailed pictures - I just checked and all the screws there were rock-solid tight.  So that's not the source of the play.
   I have just about finished my checks of the hardware and software - got the mount talking to SGP and PHD2 - so I am hoping to get some time under the stars this week to see how the mount is working.  The only issue to solve now is that I'm used to using Polemaster to do the PA and I will need to learn another procedure to do the PA.  But I do have a RPAS so I will see how well that alone does.

  Thanks so much for all the help with debugging this problem.  Even though we haven't found it - I have learned a lot about the mount and have seen how well designed and engineered these mounts are!  

John 


Re: regreasing old ap 900 gto

CurtisC
 

You can buy a grease kit from Astro-Physics. 


regreasing old ap 900 gto

vincent.visonneau
 

Hi

I would like to re-grease my old 900 gto mount.

Is this sort of grease available, i live in France

https://www.mr-bricolage.fr/Basse-goulaine-nantes/technique-graisse-universelle-lithium-tube-150g-3-en-un.html

On AP website, i don't find the method to dissasemble the worm from the gear, is the method the same as this one  (for 1200 gto model https://www.youtube.com/watch?v=R7s2kTzFNF4), perhaps it is a little different for the ap900 gto?

Is there a tips to put back the motor and adjusting the gear mesh?

Regards

Vincent

6041 - 6060 of 79681