Re: APCC 1.8.3.1: strange behaviour when parking at Park1 position


Roland Christen
 

Our park positions are NOT some fixed position on the gearwheel. They are calculated RA and DEC positions to be a certain distance from the meridian. Any small time error in your computer clock will put them off by the amount of the error (i.e. 1 second of time = 15 arc seconds of park error).

The difference between Park1 and Park5 is only about 10 seconds of time error. Park1 points to the North horizon, as does Park5. If your clock advanced by 10 seconds it can very easily put the scope on the other side. It is most likely a small time error in your laptop or computer that you are using. If you use two computers to control the mount they can cause this kind of problem if one computer's time is slightly different (by 10 seconds) from the other. The keypad is a computer. Your laptop is a computer, etc.

My advice is to never use Park1 for any reason, especially not for parking at the end of a session. It is too close to the counterweight up position, and if your system starts tracking, then within 10 seconds you have tracked past the meridian and are essentially in "forbidden" territory. If you fall asleep the mount can very well continue tracking until the scope tracks into the pier, which could cause damage. Park 2 and Park3 will always work and won't change. Park 4 and Park5 are ok also because it would take 12 hours of tracking before counterweight up condition. With APCC you can also make your own custom Park wherever you like.

If it were up to me I would eliminate Park1 altogether, but I can hear the howls from people who are using it. Park5 is just as good in almost all cases.



-----Original Message-----
From: Yves Laroche <yves.laroche@...>
To: main@ap-gto.groups.io
Sent: Wed, Jun 17, 2020 10:26 am
Subject: Re: [ap-gto] APCC 1.8.3.1: strange behaviour when parking at Park1 position

Hi Ray,

This morning, the mount behaved the same as other night.

APCC was the only software connected, no ASCOM driver.  I parked the mount to Park1 position and the mount slewed at the opposite direction.  I decided to let the slew completed.  The mount parked at Park5 position.  I unparked the mount from that position (Last Parked Position) and park the mount to Park1.  The mount slewed back to Park1 as it should.

There is a logic software problem in this version.  Never see hat kind of behaviour before.

I'm using CP4 controller.

Regards,
Yves



Le 17/06/20 00:18, Ray Gralak <groups3@...> a écrit :
Yves,

I'm saying  if the mount was slewing someplace other than Park 1 then there's not much that could cause that besides a communication error. Park 1 is always the same coordinates (hour angle and dec) so APCC is out of the picture once the commands have been sent unless, like I said, there was a multipart slew bringing the mount out of a cw up position (and only relevant if you have a GTOCP3 since the CP4/5 does that by itself).

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3:  https://www.ccdware.com
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 Yves Laroche
> Sent: Tuesday, June 16, 2020 9:07 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APCC 1.8.3.1: strange behaviour when parking at Park1 position
>
> Not sure I really understand your statement.  I parked the mount manually via APCC.
>
> Yves
>
>
> Le 16/06/20 23:46, Ray Gralak <groups3@...> a écrit :
>
>  Yves,
>
>  If the meridian delay is 0 then you probably mistook a multipart move as going somewhere besides
> Park 1.
>
>  -Ray Gralak
>  Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
>  Author of PEMPro V3:  https://www.ccdware.com
>  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 Yves Laroche
>  > Sent: Tuesday, June 16, 2020 6:20 PM
>  > To: main@ap-gto.groups.io
>  > Subject: Re: [ap-gto] APCC 1.8.3.1: strange behaviour when parking at Park1 position
>  >
>  > Ray,
>  >
>  > The meridian delay set to "0" appeared at 03h16
>  > The park message appeared at 03h28
>  >
>  > There is a 12 minutes difference between both.
>  >
>  >
>  > Regards,
>  > Yves
>  >
>  >
>  > Le 16/06/20 18:36, Ray Gralak <groups3@...> a écrit :
>  >
>  >  [Edited Message Follows]
>  >  [Reason: Removed leading "Also" in first paragraph, which I forgot to remove when I moved the
>  > paragraph to the top.]
>  >
>  >  Yves,
>  >
>  >  APCC can force the mount into a counterweight-up position first which, depending on the start
> position,
>  > might make it seem like it's going the wrong way.
>  >
>  >  If you don't think that's the case, then find in your APCC log where the park started. The meridian
> delay
>  > should be set to "0" before the park is issued by APCC, except if there is a multipart slew. Search for
>  > "meridian" to find places where it can get set.
>  >
>  >  -Ray Gralak
>  >  Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
>  >  Author of PEMPro V3:  https://www.ccdware.com
>  >  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 Yves Laroche
>  >  > Sent: Tuesday, June 16, 2020 1:20 PM
>  >  > To: main@ap-gto.groups.io
>  >  > Subject: [ap-gto] APCC 1.8.3.1: strange behaviour when parking at Park1 position
>  >  >
>  >  > Hi Ray,
>  >  >
>  >  > This morning at the end of my imaging session I parked the mount at Park1 position as usual but
> the
>  > mount
>  >  > was slewing at the opposite direction (Park4 or Park5).  I stopped the slew and re-initiate the Park1
>  > process
>  >  > and the mount went back to the Park1 position as it should.  By chance my system is not
> completely
>  >  > automated else it can be a serious problem. At that time, the ASCOM driver was disconnected.
>  >  >
>  >  > I will sent you the logs on request.
>  >  >
>  >  > Best regards,
>  >  > Yves
>  >  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>
>
>
>
>
>
>




Join main@ap-gto.groups.io to automatically receive all group messages.