Date   

Re: APCC move axis question

Ray Gralak
 

Hi Andy,

Here are my most recent APCC and Driver logs. Not sure if this adds anything to the discussion but here they
are.
Did you try NINA's move buttons again with a lower tracking speed?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Andy Ermolli
Sent: Monday, August 30, 2021 6:08 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Here are my most recent APCC and Driver logs. Not sure if this adds anything to the discussion but here they
are.


Re: GTO vs AE/AEL data #Absolute_Encoders

Jeff B
 

Yes, a great description Roland and thanks.  Now if the encoders are engaged, do they also respond similarly to vibrations induced when manually focusing?  Curious.

Jeff

On Tue, Aug 31, 2021 at 8:39 AM ap@... <ap@...> wrote:

Chris White wrote:

 

  • I've been flipping a coin about going with a Mach2 or an 1100GTO (Non-AE) for a while now, and the coin has not landed yet.  Since I dont expect to get a really big scope (Happy with my 130 and Edge 925) I'm likely leaning towards the M2.  Your description has been helpful to describe the real benefit of Encoders. 

 

Deciding by careful analysis, mathematical simulations, a bit of game theory.  Throw in some non-parametric probability theory to maximize the expected benefits….

 

Then ignore it all and do the obvious:  Both.

 

In all seriousness, unless that’s a magic coin, it’s not like you can get both at once anyway.  Take the one you can get first, use it while waiting on the second, you can always then switch easily as you would not have trouble selling the first if you decided, with that experience, you want the other, or if not, give up your place in line for the other for someone else.  Or by then you might actually want both.

 

Once you go ahead and get on both lists, you can celebrate with a nice dinner where someone will offer desert of Apple Pie or Ice Cream.  You will be prepared for this choice, and quickly say: Both.

 

😊

 

Linwood

 

 

 

 

 

 


Re: GTO vs AE/AEL data #Absolute_Encoders

ap@CaptivePhotons.com
 

Chris White wrote:

 

  • I've been flipping a coin about going with a Mach2 or an 1100GTO (Non-AE) for a while now, and the coin has not landed yet.  Since I dont expect to get a really big scope (Happy with my 130 and Edge 925) I'm likely leaning towards the M2.  Your description has been helpful to describe the real benefit of Encoders. 

 

Deciding by careful analysis, mathematical simulations, a bit of game theory.  Throw in some non-parametric probability theory to maximize the expected benefits….

 

Then ignore it all and do the obvious:  Both.

 

In all seriousness, unless that’s a magic coin, it’s not like you can get both at once anyway.  Take the one you can get first, use it while waiting on the second, you can always then switch easily as you would not have trouble selling the first if you decided, with that experience, you want the other, or if not, give up your place in line for the other for someone else.  Or by then you might actually want both.

 

Once you go ahead and get on both lists, you can celebrate with a nice dinner where someone will offer desert of Apple Pie or Ice Cream.  You will be prepared for this choice, and quickly say: Both.

 

😊

 

Linwood

 

 

 

 

 

 


Re: GTO vs AE/AEL data #Absolute_Encoders

Chris White
 

Great description Roland.  Thank you.  I've been flipping a coin about going with a Mach2 or an 1100GTO (Non-AE) for a while now, and the coin has not landed yet.  Since I dont expect to get a really big scope (Happy with my 130 and Edge 925) I'm likely leaning towards the M2.  Your description has been helpful to describe the real benefit of Encoders. 


Re: Cannot lower AP1100 102 arc min

weems@...
 

Is the mount level in the north-south axis and the altitude adjuster backed all the way out? Trying to understand if it is that you’ve run out of range of movement or if the axis is stuck with a gap between it and the adjuster.

Chip


Re: APCC move axis question

Ray Gralak
 

Hi Andy,

But more to the point, I think what you are saying is if I just sat there, and let APCC keep running, it would
have stopped the fast-tracking before it went counterweight up. It was actually closing APCC that allowed the
collision.

Do I have it right?
Yes, that is correct. However, because of the speed of the mount, the final stopped position would probably be in a slightly
counterweight-up position.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Monday, August 30, 2021 12:49 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray said:

It looks like you disconnected APCC before the mount could reach the limit.
That is very possible. I was in a bit of a panic when I couldn't stop it, and it was 3 rooms away from me.

So thinking out loud -- if it was moving slower and I disconnected, it would time out (60s I think) and then the
mount would park? But since it was moving fast, it had plenty of time to collide.

And the limits are solely inside APCC, so the mount itself does not enforce them.

And there's no stop-slew because TSX's movement was adjusting the tracking rate, not a slew; i.e. it was
tracking not slewing as far as it was concerned.

In theory I could have, if I knew all this, reset the tracking rate in APCC I suspect. Didn't occur to me.

But more to the point, I think what you are saying is if I just sat there, and let APCC keep running, it would
have stopped the fast-tracking before it went counterweight up. It was actually closing APCC that allowed the
collision.

Do I have it right?

I'm not sure I want to actually try it again to confirm. I think I was lucky the clutches were relatively loose. I
don't know that it would damage the mount, but it might have messed up the relatively light brackets on the
Pegasus.

Anyway, if I have my understanding correct, thank you for persisting to get me there.

And if not... help one more time?

Linwood




Re: APCC move axis question

Andy Ermolli
 

Here are my most recent APCC and Driver logs. Not sure if this adds anything to the discussion but here they are.


Re: GTO vs AE/AEL data #Absolute_Encoders

Roland Christen
 

I have always found that our encoder mounts track more accurately than the same mount with encoders turned off. Theoretically both guiding and the use of a precision encoder can track a precise point in the sky, but they do it in a different way.

With encoders engaged, there is instant feedback to the servo controller to move the axis back to a precise point when the axis has been disturbed (wind, cable drag or other outside force). This is accomplished very rapidly in milliseconds and very accurately down to sub-arc sec levels. In the Dec axis there is another benefit in that every small error is countered whether it requires reversal of direction or not. That means that the axis moves 1 arc second when commanded to move that distance by a single guide command, regardless of direction or reversal.

Without encoders, the RA tracking can indeed be smooth and accurate down to below 1 arc sec by using PEM compensating curve that reduces the periodic error. However, if the axis is disturbed by an external force, even a small one like a dragging cable, the actual path that the scope takes will be slightly off the commanded path. In the Dec axis an external force can move the actual shaft angle by several arc seconds, and the axis will not come back by itself.
But of course having a guider monitor a guide star can detect an error of several arc seconds and bring the star back to zero. But this takes time, depending on the guide exposure time, download speed, etc. Plus, if the star is twinkling, your calculated centroid can very easily jump around several arc seconds, if you take very many fast exposures. Finally, most all mounts have some Dec backlash delay, so if the command to reverse comes along it might take several commands for the axis to actually respond and move the guide star towards zero. During all this time the imaging camera will be taking the exposure in slightly the wrong position.

Bottom line:
With encoder mounts the axes always go to the commanded position within about 0.15 arc sec. If disturbed, they recover very fast to that very same position. Basically this is stiffening the mount to external forces. Guiding then becomes a slow process that updates the mount's axes to nudge it along to keep up with the much slower star drift that may or may not occur.

With non-encoder mounts you have to rely on guiding to close the loop, and this is a slower acting method that also relies on the skies being stable. So, guiding has several functions, not only to compensate for the slow star drift, but also to keep bringing the guide star back to zero when external forces cause it to deviate.

Rolando


-----Original Message-----
From: ap@... <ap@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Sat, Aug 28, 2021 6:53 pm
Subject: Re: [ap-gto] GTO vs AE/AEL data #Absolute_Encoders

@Roger M wrote:
  • I’m looking for solid data of GTO vs AE/AEL. In other words, at what scale and at what seeing quality do you see an improvement with the absolute encoders vs. a fully guided setup?

--
Roland Christen
Astro-Physics


Re: APCC move axis question

ap@CaptivePhotons.com
 

Ray said:

It looks like you disconnected APCC before the mount could reach the limit.
That is very possible. I was in a bit of a panic when I couldn't stop it, and it was 3 rooms away from me.

So thinking out loud -- if it was moving slower and I disconnected, it would time out (60s I think) and then the mount would park? But since it was moving fast, it had plenty of time to collide.

And the limits are solely inside APCC, so the mount itself does not enforce them.

And there's no stop-slew because TSX's movement was adjusting the tracking rate, not a slew; i.e. it was tracking not slewing as far as it was concerned.

In theory I could have, if I knew all this, reset the tracking rate in APCC I suspect. Didn't occur to me.

But more to the point, I think what you are saying is if I just sat there, and let APCC keep running, it would have stopped the fast-tracking before it went counterweight up. It was actually closing APCC that allowed the collision.

Do I have it right?

I'm not sure I want to actually try it again to confirm. I think I was lucky the clutches were relatively loose. I don't know that it would damage the mount, but it might have messed up the relatively light brackets on the Pegasus.

Anyway, if I have my understanding correct, thank you for persisting to get me there.

And if not... help one more time?

Linwood


Re: APCC move axis question

Ray Gralak
 

Linwood,

It looks like you disconnected APCC before the mount could reach the limit.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Monday, August 30, 2021 12:23 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

There is no APCC log
Indeed there wasn't, not quite sure how I managed that. My apologies.


Try this one:

https://drive.google.com/file/d/1DsmnAnzYuQTG4H7PgemtZgPg7vQmIbUo/view?usp=sharing





Re: APCC move axis question

ap@CaptivePhotons.com
 

There is no APCC log
Indeed there wasn't, not quite sure how I managed that. My apologies.


Try this one:

https://drive.google.com/file/d/1DsmnAnzYuQTG4H7PgemtZgPg7vQmIbUo/view?usp=sharing


Re: APCC move axis question

Ray Gralak
 

There is no APCC log

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Monday, August 30, 2021 12:05 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

* Use the APCC log zipper and post your ASCOM and APCC logs and the time at which this occurred.



They were in the first note with the steps to reproduce. Here's the link again:



https://drive.google.com/file/d/1qRbHdXwLP3dG3EStSiHlwnBJopgsLWh4/view?usp=sharing






Re: APCC move axis question

ap@CaptivePhotons.com
 

  • Use the APCC log zipper and post your ASCOM and APCC logs and the time at which this occurred.

 

They were in the first note with the steps to reproduce.  Here’s the link again:

 

https://drive.google.com/file/d/1qRbHdXwLP3dG3EStSiHlwnBJopgsLWh4/view?usp=sharing

 

 


Re: APCC move axis question

Ray Gralak
 

Use the APCC log zipper and post your ASCOM and APCC logs and the time at which this occurred.

 

-Ray

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Monday, August 30, 2021 11:16 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

 

Ray wrote:

 

> >But it got "stuck" and just kept going even when TSX and then APCC was disconnected.

 

> It didn't get "stuck". The mount did what it was commanded to do by TSX.

 

> The TSX bug is that it does not restore the tracking rate to sidereal when the move button is released in TSX.

 

Ah... that makes sense, so it was "tracking" at basically a slew rate.

 

And in a subsequent note:

 

> If the mount doesn't get a "stop slew" command, it will continue to slew until it hits one of the limits. If no limits were set, then the last limit occurs at the meridian when the scope is completely under the mount and the counterweight is pointing straight up.

 

I have "Enable Meridian Tracking Limits" set, I thought, to be the meridian.  I would have expected it to stop at counterweight level, not sticking way up?

 

Is this configuration not correct for that?  I have yet to put in any customized limits, but was expecting the settings below to prevent a track to counterweight up (apparently there is no setting to prevent a slew to counterweight up?).

 

So… if the issue is that it was tracking not slewing, should not this have prevented it?

 

 

 


Re: APCC move axis question

ap@CaptivePhotons.com
 

Ray wrote:

 

> >But it got "stuck" and just kept going even when TSX and then APCC was disconnected.

 

> It didn't get "stuck". The mount did what it was commanded to do by TSX.

 

> The TSX bug is that it does not restore the tracking rate to sidereal when the move button is released in TSX.

 

Ah... that makes sense, so it was "tracking" at basically a slew rate.

 

And in a subsequent note:

 

> If the mount doesn't get a "stop slew" command, it will continue to slew until it hits one of the limits. If no limits were set, then the last limit occurs at the meridian when the scope is completely under the mount and the counterweight is pointing straight up.

 

I have "Enable Meridian Tracking Limits" set, I thought, to be the meridian.  I would have expected it to stop at counterweight level, not sticking way up?

 

Is this configuration not correct for that?  I have yet to put in any customized limits, but was expecting the settings below to prevent a track to counterweight up (apparently there is no setting to prevent a slew to counterweight up?).

 

So… if the issue is that it was tracking not slewing, should not this have prevented it?

 

 

 


Re: APCC move axis question

Andrea Lucchetti
 

The behavior seems the same I reported last year with my Mach2. Will try to go back to see the details if helpful

On Mon, 30 Aug 2021 at 20:11, ap@... <ap@...> wrote:

Correct.  As below.

 

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of George via groups.io
Sent: Monday, August 30, 2021 1:59 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

 

Be sure that you've configured SkyX through ASCOM mount and not through Astro-Physics (their proprietary drivers).

 

Regards,

 

George

 

George Whitney

Astro-Physics, Inc.

Phone:  815-222-6538 (direct line)

Phone:  815-282-1513 (office)

Email:  george@...

 

-----Original Message-----

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of ap@...

Sent: Monday, August 30, 2021 12:56 PM

To: main@ap-gto.groups.io

Subject: Re: [ap-gto] APCC move axis question

 

Just for clarity, the movement was fast, not was not tracking, it was moving at a pretty good fast slew rate.

 

I'm a bit unclear on the definition of a slew vs any other move.  The move axis may not be considered a slew.

 

But it got "stuck" and just kept going even when TSX and then APCC was disconnected. 

 

 

 

-----Original Message-----

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak via groups.io

Sent: Monday, August 30, 2021 1:53 PM

To: main@ap-gto.groups.io

Subject: Re: [ap-gto] APCC move axis question

 

> Nope, but if APCC is configured correctly the Emergency Stop Window should have opened.

 

Oh, nevermind, if it wasn't a slew then the emergency stop window will not open automatically.

 

However, you could open the emergency slew window and be ready to stop it.

 

-Ray

 

> -----Original Message-----

> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf

> Of Ray Gralak

> Sent: Monday, August 30, 2021 10:50 AM

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

> Subject: Re: [ap-gto] APCC move axis question

>

> > But having said that... even if this is a TSX invoked mess, should the mount ever sit there continuously

> > slewing without APCC being aware of it, presenting the ability to stop?   Shouldn't an ASCOM and APCC

> > disconnect from the mount make it stop?

>

> Nope, but if APCC is configured correctly the Emergency Stop Window should have opened.

>

> -Ray

>

> > -----Original Message-----

> > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf

> > Of ap@...

> > Sent: Monday, August 30, 2021 10:25 AM

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

> > Subject: Re: [ap-gto] APCC move axis question

> >

> > But having said that... even if this is a TSX invoked mess, should the mount ever sit there continuously

> > slewing without APCC being aware of it, presenting the ability to stop?   Shouldn't an ASCOM and APCC

> > disconnect from the mount make it stop?

> >

> > (I should note all this happened pretty fast, so if there's a (for

> > example) 60 second timeout, I got nowhere

> near

> > it.  But it did sit there long enough that the RA clutch slipped

> > about 20 degrees, the DEC just a bit.  Not sure what would happen if they had been really tight, it was pushing on a Pegasus power box.

> >

> > It was like the mount was slewing but APCC didn't seem to know it.

> >

> >

> > -----Original Message-----

> > From: ap@...

> > Sent: Monday, August 30, 2021 12:19 PM

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

> > Subject: RE: [ap-gto] APCC move axis question

> >

> > Ray:

> > > I believe there is a known problem with some versions of SkyX

> > > (it's not a problem with the driver or

> APCC).

> >

> > > What is the exact version of SkyX that you are using?

> >

> > 32 bit 10.5.0 build 12978

> >

> >

> >

> >

> >

>

>

>

>

>

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Re: APCC move axis question

ap@CaptivePhotons.com
 

Correct.  As below.

 

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of George via groups.io
Sent: Monday, August 30, 2021 1:59 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

 

Be sure that you've configured SkyX through ASCOM mount and not through Astro-Physics (their proprietary drivers).

 

Regards,

 

George

 

George Whitney

Astro-Physics, Inc.

Phone:  815-222-6538 (direct line)

Phone:  815-282-1513 (office)

Email:  george@...

 

-----Original Message-----

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of ap@...

Sent: Monday, August 30, 2021 12:56 PM

To: main@ap-gto.groups.io

Subject: Re: [ap-gto] APCC move axis question

 

Just for clarity, the movement was fast, not was not tracking, it was moving at a pretty good fast slew rate.

 

I'm a bit unclear on the definition of a slew vs any other move.  The move axis may not be considered a slew.

 

But it got "stuck" and just kept going even when TSX and then APCC was disconnected. 

 

 

 

-----Original Message-----

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak via groups.io

Sent: Monday, August 30, 2021 1:53 PM

To: main@ap-gto.groups.io

Subject: Re: [ap-gto] APCC move axis question

 

> Nope, but if APCC is configured correctly the Emergency Stop Window should have opened.

 

Oh, nevermind, if it wasn't a slew then the emergency stop window will not open automatically.

 

However, you could open the emergency slew window and be ready to stop it.

 

-Ray

 

> -----Original Message-----

> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf

> Of Ray Gralak

> Sent: Monday, August 30, 2021 10:50 AM

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

> Subject: Re: [ap-gto] APCC move axis question

>

> > But having said that... even if this is a TSX invoked mess, should the mount ever sit there continuously

> > slewing without APCC being aware of it, presenting the ability to stop?   Shouldn't an ASCOM and APCC

> > disconnect from the mount make it stop?

>

> Nope, but if APCC is configured correctly the Emergency Stop Window should have opened.

>

> -Ray

>

> > -----Original Message-----

> > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf

> > Of ap@...

> > Sent: Monday, August 30, 2021 10:25 AM

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

> > Subject: Re: [ap-gto] APCC move axis question

> >

> > But having said that... even if this is a TSX invoked mess, should the mount ever sit there continuously

> > slewing without APCC being aware of it, presenting the ability to stop?   Shouldn't an ASCOM and APCC

> > disconnect from the mount make it stop?

> >

> > (I should note all this happened pretty fast, so if there's a (for

> > example) 60 second timeout, I got nowhere

> near

> > it.  But it did sit there long enough that the RA clutch slipped

> > about 20 degrees, the DEC just a bit.  Not sure what would happen if they had been really tight, it was pushing on a Pegasus power box.

> >

> > It was like the mount was slewing but APCC didn't seem to know it.

> >

> >

> > -----Original Message-----

> > From: ap@...

> > Sent: Monday, August 30, 2021 12:19 PM

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

> > Subject: RE: [ap-gto] APCC move axis question

> >

> > Ray:

> > > I believe there is a known problem with some versions of SkyX

> > > (it's not a problem with the driver or

> APCC).

> >

> > > What is the exact version of SkyX that you are using?

> >

> > 32 bit 10.5.0 build 12978

> >

> >

> >

> >

> >

>

>

>

>

>

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Re: APCC move axis question

Roland Christen
 

If the mount doesn't get a "stop slew" command, it will continue to slew until it hits one of the limits. If no limits were set, then the last limit occurs at the meridian when the scope is completely under the mount and the counterweight is pointing straight up.

All of our software automatically has a "stop slew" command, but 3rd party software we have no control over can have a situation where no "stop slew" command is sent. As you found out.

Rolando


-----Original Message-----
From: ap@... <ap@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Mon, Aug 30, 2021 12:25 pm
Subject: Re: [ap-gto] APCC move axis question

But having said that... even if this is a TSX invoked mess, should the mount ever sit there continuously slewing without APCC being aware of it, presenting the ability to stop?  Shouldn't an ASCOM and APCC disconnect from the mount make it stop?

(I should note all this happened pretty fast, so if there's a (for example) 60 second timeout, I got nowhere near it.  But it did sit there long enough that the RA clutch slipped about 20 degrees, the DEC just a bit.  Not sure what would happen if they had been really tight, it was pushing on a Pegasus power box.

It was like the mount was slewing but APCC didn't seem to know it.


-----Original Message-----
From: ap@...
Sent: Monday, August 30, 2021 12:19 PM
To: main@ap-gto.groups.io
Subject: RE: [ap-gto] APCC move axis question

Ray:
> I believe there is a known problem with some versions of SkyX (it's not a problem with the driver or APCC).

> What is the exact version of SkyX that you are using?

32 bit 10.5.0 build 12978








--
Roland Christen
Astro-Physics


Re: APCC move axis question

Ray Gralak
 

But it got "stuck" and just kept going even when TSX and then APCC was disconnected.
It didn't get "stuck". The mount did what it was commanded to do by TSX.

The TSX bug is that it does not restore the tracking rate to sidereal when the move button is released in TSX.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Monday, August 30, 2021 10:56 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Just for clarity, the movement was fast, not was not tracking, it was moving at a pretty good fast slew rate.

I'm a bit unclear on the definition of a slew vs any other move. The move axis may not be considered a slew.

But it got "stuck" and just kept going even when TSX and then APCC was disconnected.



-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak via groups.io
Sent: Monday, August 30, 2021 1:53 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Nope, but if APCC is configured correctly the Emergency Stop Window should have opened.
Oh, nevermind, if it wasn't a slew then the emergency stop window will not open automatically.

However, you could open the emergency slew window and be ready to stop it.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of Ray Gralak
Sent: Monday, August 30, 2021 10:50 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

But having said that... even if this is a TSX invoked mess, should the mount ever sit there continuously
slewing without APCC being aware of it, presenting the ability to stop? Shouldn't an ASCOM and APCC
disconnect from the mount make it stop?
Nope, but if APCC is configured correctly the Emergency Stop Window should have opened.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of ap@...
Sent: Monday, August 30, 2021 10:25 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

But having said that... even if this is a TSX invoked mess, should the mount ever sit there continuously
slewing without APCC being aware of it, presenting the ability to stop? Shouldn't an ASCOM and APCC
disconnect from the mount make it stop?

(I should note all this happened pretty fast, so if there's a (for
example) 60 second timeout, I got nowhere
near
it. But it did sit there long enough that the RA clutch slipped
about 20 degrees, the DEC just a bit. Not sure what would happen if they had been really tight, it was
pushing on a Pegasus power box.

It was like the mount was slewing but APCC didn't seem to know it.


-----Original Message-----
From: ap@...
Sent: Monday, August 30, 2021 12:19 PM
To: main@ap-gto.groups.io
Subject: RE: [ap-gto] APCC move axis question

Ray:
I believe there is a known problem with some versions of SkyX
(it's not a problem with the driver or
APCC).

What is the exact version of SkyX that you are using?
32 bit 10.5.0 build 12978
















Re: APCC move axis question

George
 

Be sure that you've configured SkyX through ASCOM mount and not through Astro-Physics (their proprietary drivers).

Regards,

George

George Whitney
Astro-Physics, Inc.
Phone:  815-222-6538 (direct line)
Phone:  815-282-1513 (office)
Email:  george@...

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of ap@...
Sent: Monday, August 30, 2021 12:56 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Just for clarity, the movement was fast, not was not tracking, it was moving at a pretty good fast slew rate.

I'm a bit unclear on the definition of a slew vs any other move. The move axis may not be considered a slew.

But it got "stuck" and just kept going even when TSX and then APCC was disconnected.



-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak via groups.io
Sent: Monday, August 30, 2021 1:53 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Nope, but if APCC is configured correctly the Emergency Stop Window should have opened.
Oh, nevermind, if it wasn't a slew then the emergency stop window will not open automatically.

However, you could open the emergency slew window and be ready to stop it.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of Ray Gralak
Sent: Monday, August 30, 2021 10:50 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

But having said that... even if this is a TSX invoked mess, should the mount ever sit there continuously
slewing without APCC being aware of it, presenting the ability to stop? Shouldn't an ASCOM and APCC
disconnect from the mount make it stop?
Nope, but if APCC is configured correctly the Emergency Stop Window should have opened.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of ap@...
Sent: Monday, August 30, 2021 10:25 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

But having said that... even if this is a TSX invoked mess, should the mount ever sit there continuously
slewing without APCC being aware of it, presenting the ability to stop? Shouldn't an ASCOM and APCC
disconnect from the mount make it stop?

(I should note all this happened pretty fast, so if there's a (for
example) 60 second timeout, I got nowhere
near
it. But it did sit there long enough that the RA clutch slipped
about 20 degrees, the DEC just a bit. Not sure what would happen if they had been really tight, it was pushing on a Pegasus power box.

It was like the mount was slewing but APCC didn't seem to know it.


-----Original Message-----
From: ap@...
Sent: Monday, August 30, 2021 12:19 PM
To: main@ap-gto.groups.io
Subject: RE: [ap-gto] APCC move axis question

Ray:
I believe there is a known problem with some versions of SkyX
(it's not a problem with the driver or
APCC).

What is the exact version of SkyX that you are using?
32 bit 10.5.0 build 12978







8581 - 8600 of 89102