Date   

Re: Mach1 problem please assist

Ron Kramer
 

Kit arrived late last night. (UPS error)
Today it was hot in the dome so I just did the RA worm and drive gear. And the side gears)
I hope to test tonight and see if it solves my RA kicking problem. 

I inspected the worm and was in fine shape - EXCEPT I had some very rough area which I don't think matters. It was way over on the very edges of the worm... like the last 2-3 turns were rough. I don't believe this are ever used? 

I greased the entire worm even though it said just the center is all that's needed. Figured it would help ward off corrosion.   The process wasn't scary once the RA box was removed. In fact (I don't recommend this) but I didn't even take my gear off the mount.  RASA 11 + essentials upside down at times.   I forgot about the cords but never turned more than 180.  I actually read the instructions after I was done. (common for me, I like to dig in) then see what I did wrong. 

SOUNDS nice... Will see if the RA hiccups tonight in a guiding test.  if all is good I'll do DEC tomorrow but RA was a primary concern as it would jump and killed every other sub.

Will see tonight.





On Wed, Jun 10, 2020 at 4:33 PM Marj Christen <marj@...> wrote:

Ron,

 

Now that our production staff has returned, the turnaround time for repairs is pretty quick. There is no standard cost for a “ tune up” since it depends on what is involved and if parts have to be replaced.

 

Try regreasing first and contact us again if you can’t resolve the issue.

 

Clear Skies,

 

Marj Christen

Astro-Physics, Inc

11250 Forest Hills Rd

Machesney Park, IL 61115

Phone: 815-282-1513

Fax: 815-282-9847

www.astro-physics.com

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Ron Kramer
Sent: Wednesday, June 10, 2020 1:33 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Mach1 problem please assist

 

I'm about to try to re-grease - I'll see if I can see something during inspection.  Is swapping the worm something easy I can do at home? 
I don't want to do anything complicated. I don't believe I've nicked a gear - I only use park3.  But it has come against the pier during a few 3-4 occasions? Would that do anything?

How much does it cost to send it in for a tune up?  HOW LONG would I be without it?  I'm near in Grand Rapids, MI.
I'll look for a clump of anything in the worm teeth.  If I send it in I don 't want it waiting for weeks/days. What is time frame? 

I ordered the grease, I'll see how that goes.

 

 

On Tue, Jun 9, 2020 at 7:51 PM uncarollo2 <chris1011@...> via groups.io <chris1011=aol.com@groups.io> wrote:

Forget backlash in RA. There is no such thing. RA always tracks so it never reverses. Backlash does not enter into tracking.

 

You may have damaged your worm teeth when you backed off the worm to do a fine balance. You may have forgotten to do it only in the Park3 position. If that's the case, the worm may have a nick in the teeth and it will show up as a repeating pattern once every 6.4 minutes.

 

Rolando

 

 

 

-----Original Message-----
From: Ron Kramer <ronkramer1957@...>
To: main@ap-gto.groups.io
Sent: Tue, Jun 9, 2020 3:30 pm
Subject: [ap-gto] Mach1 problem please assist

My mach1 is about 2.5 years old.  I was getting awesome guiding with a total rms error of .24 arc sec.  

Winter came and went and this spring it's been horrible.  like  1.4.   My image scale is about 1.69 so I lived with that for a while, but lately

the RA is  KICKING in almost a timely fashion.  One of these kicks makes double stars.  Around 1/2 my subs have to be deleted.

Nothing I have tried to far has fixed it.

I will include the log from a couple nights ago to show what I mean. 

I did a new calibration - then a guide assistant for a while... then set recommendations and let it guide a while.
You'll see   RA  kicking like a mule in a rather evenly timed fashion!?!  

I would so appreciate help with this.  Someone in PHD said make sure the mount software/HC doesn't have backlash on.  

I DO NOT USE or own a HC and I don't know of any BackLash setting in APCC pro.  I'm going nuts. 

 

 


 

--




Re: help with AP900 guiding via ASIAir Pro

sgbonnell@...
 

Hi Ray,
I reset the AP900 ASCOM mount settings (AP900 and CP2) and tried it out again.
Same result unfortunately...logs attached.

However, I see that the Mount Type does not get populated in the Log files...I do have AP900 selected in the Telescope set up panel in ASCOM (double and triple checked) but it is not appearing in the logs (as you noticed earlier).   Is this a symptom or cause of my troubles?

thanks for your help in trying to sort this out..
Steve


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

Yves Laroche
 

Ray,

I can assure you that my computer clock was well synchronized.  It's part of my ritual before any imaging session since a long time.  If you read carefully my latest message, I unparked the mount from "Last Parked Position" (It was Park5 instead of Park1) and parked the mount again to Park1 and it worked.  NO possibility here of time issue.

I've just remarked that CP3 is set within ASCOM driver instead of CP4.  I really don't know why but... Is it possible that this setting can raise some problem with the new APCC release???  I will find this out at the end of the incoming night.

Regards,
Yves



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

Nothing has changed regarding Park 1 in a long time in APCC.

-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: Wednesday, June 17, 2020 9:41 AM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APCC 1.8.3.1: strange behaviour when parking at Park1 position
>
> Sorry Rolando and Ray but Park1 position was running well until the latest APCC version.
>
>
> My computer clock is always synchronized. Would you explain me why my mount was badly parked to Park5,
> unparked from the last parked position (Park5 position) and then park to Park1 position again and slewed to
> Park1 as it should.  The mount controller knew exactly where it was pointing all the time else the mount would
> never been able to park at Park1.
>
>
> There is probably a small typo or logical error in the code that cause this behaviour.
>
>
> I'm using this park position since 2002 and all my observatory environment is set according to this park
> position.
>
>
> Ray,  I never missed that warning.  Thanks for pointing this out !!!  However, as a beta-tester, I can't and will
> never accept this kind of response from you.  I've put too much time and efforts to help Astro-Physics
> astronomy lovers to enjoy their hobby.  My two cents.
>
>
>
>
> Yves Laroche
>
>
>
>
>
>
>
>
> Le 17/06/20 12:01, Ray Gralak <groups3@...> a écrit :
>
>
>
> Yves,
>
>
>
> Maybe you missed the warning message in APCC that indicates Park 1 is obsolete and not supported by
> Astro-Physics? (see screenshot below)
>
>
>
> If you need to move the mount to that position maybe try defining an Alt/Az position near, but not exactly at
> Park1 ?
>
>
>
>
>
>
>
> -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: Wednesday, June 17, 2020 8:26 AM
>
> > To: main@ap-gto.groups.io
>
> > 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
>
> >          >  >  >
>
> >          >  >
>
> >          >  >
>
> >          >  >
>
> >          >  >
>
> >          >  >
>
> >          >  >
>
> >          >  >
>
> >          >
>
> >          >
>
> >          >
>
> >          >
>
> >          >
>
> >          >
>
> >          >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
>





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

Ray Gralak
 

Yves,

Nothing has changed regarding Park 1 in a long time in APCC.

-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: Wednesday, June 17, 2020 9:41 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC 1.8.3.1: strange behaviour when parking at Park1 position

Sorry Rolando and Ray but Park1 position was running well until the latest APCC version.


My computer clock is always synchronized. Would you explain me why my mount was badly parked to Park5,
unparked from the last parked position (Park5 position) and then park to Park1 position again and slewed to
Park1 as it should. The mount controller knew exactly where it was pointing all the time else the mount would
never been able to park at Park1.


There is probably a small typo or logical error in the code that cause this behaviour.


I'm using this park position since 2002 and all my observatory environment is set according to this park
position.


Ray, I never missed that warning. Thanks for pointing this out !!! However, as a beta-tester, I can't and will
never accept this kind of response from you. I've put too much time and efforts to help Astro-Physics
astronomy lovers to enjoy their hobby. My two cents.




Yves Laroche








Le 17/06/20 12:01, Ray Gralak <groups3@gralak.com> a écrit :



Yves,



Maybe you missed the warning message in APCC that indicates Park 1 is obsolete and not supported by
Astro-Physics? (see screenshot below)



If you need to move the mount to that position maybe try defining an Alt/Az position near, but not exactly at
Park1 ?







-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: Wednesday, June 17, 2020 8:26 AM
To: main@ap-gto.groups.io
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@gralak.com> 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@gralak.com> 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@gralak.com> 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
> > >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>


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

Roland Christen
 

There is no logic error. Please re-read what i wrote. It is strictly a timing error that occurs when using computer time. All parks are derived from RA/Dec coordinates. Please use Altitude and Azimuth and make your own custom park. Do not rely on Park1, please.

Rolando



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

Sorry Rolando and Ray but Park1 position was running well until the latest APCC version.

My computer clock is always synchronized. Would you explain me why my mount was badly parked to Park5, unparked from the last parked position (Park5 position) and then park to Park1 position again and slewed to Park1 as it should.  The mount controller knew exactly where it was pointing all the time else the mount would never been able to park at Park1.

There is probably a small typo or logical error in the code that cause this behaviour.

I'm using this park position since 2002 and all my observatory environment is set according to this park position.

Ray,  I never missed that warning.  Thanks for pointing this out !!!  However, as a beta-tester, I can't and will never accept this kind of response from you.  I've put too much time and efforts to help Astro-Physics astronomy lovers to enjoy their hobby.  My two cents.


Yves Laroche





Le 17/06/20 12:01, Ray Gralak <groups3@...> a écrit :


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

Yves Laroche
 

Sorry Rolando and Ray but Park1 position was running well until the latest APCC version.

My computer clock is always synchronized. Would you explain me why my mount was badly parked to Park5, unparked from the last parked position (Park5 position) and then park to Park1 position again and slewed to Park1 as it should.  The mount controller knew exactly where it was pointing all the time else the mount would never been able to park at Park1.

There is probably a small typo or logical error in the code that cause this behaviour.

I'm using this park position since 2002 and all my observatory environment is set according to this park position.

Ray,  I never missed that warning.  Thanks for pointing this out !!!  However, as a beta-tester, I can't and will never accept this kind of response from you.  I've put too much time and efforts to help Astro-Physics astronomy lovers to enjoy their hobby.  My two cents.


Yves Laroche





Le 17/06/20 12:01, Ray Gralak <groups3@...> a écrit :


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

Ray Gralak
 

Yves,

 

Maybe you missed the warning message in APCC that indicates Park 1 is obsolete and not supported by Astro-Physics? (see screenshot below)

 

If you need to move the mount to that position maybe try defining an Alt/Az position near, but not exactly at Park1 ?

 

 

-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: Wednesday, June 17, 2020 8:26 AM

> To: main@ap-gto.groups.io

> 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

>          >  >  >

>          >  >

>          >  >

>          >  >

>          >  >

>          >  >

>          >  >

>          >  >

>          >

>          >

>          >

>          >

>          >

>          >

>          >

>

>

>

>

>

>


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





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

Yves Laroche
 

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





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

Ray Gralak
 

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@gralak.com> 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@gralak.com> 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
> >
>
>
>
>
>
>
>







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

Yves Laroche
 

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





Re: APPM support for Platesolve2?

Ray Gralak
 

Hi Gabe,

There are no plans to natively implement platesolve2.

Regarding the SkyX failures please double check you followed the procedure in APCC's help file to setup in SkyX the ability to external software applications to use SkyX. Also, make sure you are running the latest daily update of SkyX.

-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 Gabe Shaughnessy
Sent: Tuesday, June 16, 2020 8:41 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM support for Platesolve2?

Is Platesolve2 support on the roadmap for APPM? I know that it does use Platesolve2 via SGP, but I'd rather
not have SGP as a go between since it's not installed on all my systems and have had issues with it in the
past being stable enough for all night unassisted imaging. I tried TheSkyX's ImageLink, but it kept giving me
errors that it couldn't find a suitable plate solve (either plate-solve or all-sky solve). I had the correct pixel
scale and had synced it earlier using platesolve2 via Voyager.

Gabe


Re: APPM plate solve anomaly

Ray Gralak
 

Great. I'll try to look into this issue next weekend.

-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 Gary Steffens via groups.io
Sent: Tuesday, June 16, 2020 8:18 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM plate solve anomaly

Ray,

You were correct about ASCOM 6.5. I reverted back to 6.4 SP1 and APPM is happily working again!

Thanks again,
Gary


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

Ray Gralak
 

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@gralak.com> 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
>







APPM support for Platesolve2?

Gabe Shaughnessy
 

Is Platesolve2 support on the roadmap for APPM?  I know that it does use Platesolve2 via SGP, but I'd rather not have SGP as a go between since it's not installed on all my systems and have had issues with it in the past being stable enough for all night unassisted imaging.  I tried TheSkyX's ImageLink, but it kept giving me errors that it couldn't find a suitable plate solve (either plate-solve or all-sky solve).  I had the correct pixel scale and had synced it earlier using platesolve2 via Voyager.  

Gabe


Re: APPM plate solve anomaly

Gary Steffens
 

Ray,

You were correct about ASCOM 6.5. I reverted back to 6.4 SP1 and APPM is happily working again!

Thanks again,
Gary


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

Yves Laroche
 

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
>





Re: APPM plate solve anomaly

Ray Gralak
 

Gary,

I think there is a bug in ASCOM 6.5 beta. That would explain why going back to 1.8.2.1 didn't help. Luckily your data is not corrupted by this.

What's happening is that the ASCOM precession object looks like it can be initialized exactly once. For efficiency's sake APCC reuses the same object so all of the plate solves in your screen shot have the same RA/Dec and thus some huge offsets. The behavior is probably not expected but I haven't had a chance to look into this.

-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 Gary Steffens via groups.io
Sent: Tuesday, June 16, 2020 3:42 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM plate solve anomaly

Hi Ray,

Thanks for the reply. I recently installed 6.5, so that is probably the cause. I'll install 6.4 SP1 and will let you
know if that solves the problem.

Gary


Re: APPM plate solve anomaly

Gary Steffens
 

Hi Ray,

Thanks for the reply. I recently installed 6.5, so that is probably the cause. I'll install 6.4 SP1 and will let you know if that solves the problem.

Gary


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

Ray Gralak
 
Edited

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

8601 - 8620 of 79775