Date   

Tripod for MC254 and Mach1

Elenillor
 

 

Wondering about lower vibration options for the above combination.

I am strictly a portable and visual observer. The two tripods I use are an AP Berlebach and an AP 42" portable pier. Both are fine with an AP130 but with the MC245 are quite vibration prone when focusing. Vibration is not a problem when tracking.

 

So wondering if a different tripod would make a large difference in vibration (Eagle, ATS, Losmandy HD or other). The Mach1 is loaded with 60+lbs of counter weights, and the MC254 has a FL of around 3,680mm.

 

Any experience with comparisons of different tripods using similar FL scopes?

 

John


Re: help with AP900 guiding via ASIAir Pro

sgbonnell@...
 

OK, thanks Ray...I'll give it a try...
cheers,
Steve


Re: What is the diameter and thread on the Pasil.4 polar scope?

R Botero
 

Tom 

Some pictures attached. Take these with a pinch of salt (thread is definitely 24tpi) as my 900GTO seems to have a collar on its Pasil and yours may be a direct attachment and I used a calipers instead of a micrometre to measure diameters.

Roberto


Re: What is the diameter and thread on the Pasil.4 polar scope?

R Botero
 

Tom
Do you have the polar scope already? If so, get yourself a thread gauge and measure directly on your unit. You will need one anyway if you are serious about turning threads on your lathe anyway (it will be the only way to test your plug whilst still on the chuck). 

I have a Pasil on an 900GTO and will send you my measurements later (hoping they match the 600). 


Roberto


Re: PEMPro on ASI6200 & QHY600

Ray Gralak
 

Hi Dale,

Oh, I have a QHY600 now. I can help test this.
That would be great!

Again, the only changes are in the polar alignment wizard, where on step 2 you can select the full frame, center 1/2 x 1/2, center
1/3 x 1/3, and center 1/4 x 1/4. I am hoping that selecting a sub-frame will reduce the total allocation of memory required at any
moment. Step 3 seems to be the worst-case, where three images have to be allocated in that step.

Here is the download link:

https://www.siriusimaging.com/PEMProV3/PEMProV3_Release_v3.00.29.exe

-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 Dale Ghent
Sent: Wednesday, June 17, 2020 8:17 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] PEMPro on ASI6200 & QHY600


Oh, I have a QHY600 now. I can help test this.

On Jun 17, 2020, at 10:48 PM, Ray Gralak <groups3@gralak.com> wrote:

Hi Tom,

Any progress on this? I have heard that it was a couple of days away a couple of weeks ago.
PEMPro 3.0.29 was released a couple weeks ago and I am waiting for feedback. The only change required was to
add full support for subframes and binning in the polar alignment wizard. PEC programming did not require any
changes.

-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 Tom Blahovici
Sent: Wednesday, June 17, 2020 3:54 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] PEMPro on ASI6200 & QHY600

Hi
Any progress on this? I have heard that it was a couple of days away a couple of weeks ago.
Thanks, Tom




Re: PEMPro on ASI6200 & QHY600

Dale Ghent
 

Oh, I have a QHY600 now. I can help test this.

On Jun 17, 2020, at 10:48 PM, Ray Gralak <groups3@gralak.com> wrote:

Hi Tom,

Any progress on this? I have heard that it was a couple of days away a couple of weeks ago.
PEMPro 3.0.29 was released a couple weeks ago and I am waiting for feedback. The only change required was to add full support for subframes and binning in the polar alignment wizard. PEC programming did not require any changes.

-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 Tom Blahovici
Sent: Wednesday, June 17, 2020 3:54 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] PEMPro on ASI6200 & QHY600

Hi
Any progress on this? I have heard that it was a couple of days away a couple of weeks ago.
Thanks, Tom



Re: help with AP900 guiding via ASIAir Pro

Ray Gralak
 

Hi Steve,

I'll look into this when I get a chance. In the mean time you might consider reverting to an older version of the driver.

There are links to some of the older versions here (start with 5.21.01 and go earlier if needed):

https://www.gralak.com/apdriver

-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 sgbonnell@outlook.com
Sent: Wednesday, June 17, 2020 12:44 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] help with AP900 guiding via ASIAir Pro

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: PEMPro on ASI6200 & QHY600

Ray Gralak
 

Hi Tom,

Any progress on this? I have heard that it was a couple of days away a couple of weeks ago.
PEMPro 3.0.29 was released a couple weeks ago and I am waiting for feedback. The only change required was to add full support for subframes and binning in the polar alignment wizard. PEC programming did not require any changes.

-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 Tom Blahovici
Sent: Wednesday, June 17, 2020 3:54 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] PEMPro on ASI6200 & QHY600

Hi
Any progress on this? I have heard that it was a couple of days away a couple of weeks ago.
Thanks, Tom


Re: What is the diameter and thread on the Pasil.4 polar scope?

Christopher Erickson
 

Doing a drift align would be a lot less work. (Grin)


-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Wed, Jun 17, 2020, 2:52 PM Tom Blahovici <tom.va2fsq@...> wrote:
Hi
I'd like to make a plug for the place the polar scope goes into the 600e mount. I figure I might as well get some use on my new mini lathe. 
I'm thinking of delrin or brass. Anyways, Once permenantly polar aligned, I should remove the polar scope since it potentially gets in the way or wires. I'd like to if the opening
Thanks, Tom


What is the diameter and thread on the Pasil.4 polar scope?

Tom Blahovici
 

Hi
I'd like to make a plug for the place the polar scope goes into the 600e mount. I figure I might as well get some use on my new mini lathe. 
I'm thinking of delrin or brass. Anyways, Once permenantly polar aligned, I should remove the polar scope since it potentially gets in the way or wires. I'd like to if the opening
Thanks, Tom


Re: PEMPro on ASI6200 & QHY600

Tom Blahovici
 

Hi
Any progress on this? I have heard that it was a couple of days away a couple of weeks ago.
Thanks, Tom


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




7841 - 7860 of 79026