Preventing Pier Crashes


Alex
 

I have an 1100 with absolute encoders, and I'm having the occasional problem of the mount crashing my camera into my pier during slews. My pier has a fairly wide base, and there are a couple zones near the meridian where the camera will hit the pier. I defined the meridian limits in APCC Pro which define this danger zone, but apparently it isn't being honored. Occasionally when slewing to an object, the path the mount takes will crash my camera into the pier. There must me some setting I'm getting wrong, but I'm as a loss as to what it is.

Can somebody please tell me how to set it up so the mount will never slew to certain positions? I'm now afraid to use the mount without being personally there to abort a slew.

Alex


Ray Gralak
 

Hi Alex,

Are the collision zones you mentioned in counterweight-up or counterweight-down position?

APCC's Meridian Tracking Limits feature is designed to stop *tracking* at an hour angle limit and define mount flip points. If your 1100 has a CP4 its firmware handles counterweight-up slews in a "safe" manner by always moving RA first to a counterweight-down position, then slewing to a target. Additionally, if the target is counterweight-up, then the last slew will be in RA only also. (If your mount has a CP3 controller, then APCC performs these moves instead of the mount firmware.)

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Alex
Sent: Friday, July 23, 2021 11:04 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Preventing Pier Crashes

I have an 1100 with absolute encoders, and I'm having the occasional problem of the mount crashing my camera
into my pier during slews. My pier has a fairly wide base, and there are a couple zones near the meridian where the
camera will hit the pier. I defined the meridian limits in APCC Pro which define this danger zone, but apparently it
isn't being honored. Occasionally when slewing to an object, the path the mount takes will crash my camera into the
pier. There must me some setting I'm getting wrong, but I'm as a loss as to what it is.

Can somebody please tell me how to set it up so the mount will never slew to certain positions? I'm now afraid to
use the mount without being personally there to abort a slew.

Alex


Joe Zeglinski
 

Ray,
 
    I have been away from the APCC for quite a while. Please remind me
- Does the APCC  firmware itself, check whether it is communicating with a CP3, CP4, or CP5 – and handles the “software mode” Limits & Meridian switch points,  itself? Or, does the user have to make  sure the controller is “user configured” in the APCC, as is done for the Keypad?
    I assume it is  automated, to avoid confusion and possible improper mount behaviour.
 
Joe
 

From: Ray Gralak
Sent: Saturday, July 24, 2021 8:21 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Preventing Pier Crashes
 
Hi Alex,

Are the collision zones you mentioned in counterweight-up or counterweight-down position?

APCC's Meridian Tracking Limits feature is designed to stop *tracking* at an hour angle limit and define mount flip points. If your 1100 has a CP4 its firmware handles counterweight-up slews in a "safe" manner by always moving RA first to a counterweight-down position, then slewing to a target. Additionally, if the target is counterweight-up, then the last slew will be in RA only also. (If your mount has a CP3 controller, then APCC performs these moves instead of the mount firmware.)

-Ray


Ray Gralak
 

Joe,

- Does the APCC firmware itself, check whether it is communicating with a CP3, CP4, or CP5 –
and handles the “software mode” Limits & Meridian switch points, itself?
I don't know what you mean by "APCC firmware". Can you clarify that question?

APCC can set mount limits if configured to do so, but when *slewing*, mount limits are not changed in real-time as declination changes. When the mount reaches the target's declination, then the meridian delay and mount limits will be set, provided APCC is configured to do so.

-Ray



-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Joe Zeglinski
Sent: Saturday, July 24, 2021 7:47 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Preventing Pier Crashes

Ray,

I have been away from the APCC for quite a while. Please remind me
- Does the APCC firmware itself, check whether it is communicating with a CP3, CP4, or CP5 – and handles the
“software mode” Limits & Meridian switch points, itself? Or, does the user have to make sure the controller is “user
configured” in the APCC, as is done for the Keypad?
I assume it is automated, to avoid confusion and possible improper mount behaviour.

Joe

From: Ray Gralak
Sent: Saturday, July 24, 2021 8:21 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Preventing Pier Crashes

Hi Alex,

Are the collision zones you mentioned in counterweight-up or counterweight-down position?

APCC's Meridian Tracking Limits feature is designed to stop *tracking* at an hour angle limit and define mount flip
points. If your 1100 has a CP4 its firmware handles counterweight-up slews in a "safe" manner by always moving
RA first to a counterweight-down position, then slewing to a target. Additionally, if the target is counterweight-up,
then the last slew will be in RA only also. (If your mount has a CP3 controller, then APCC performs these moves
instead of the mount firmware.)

-Ray


Joe Zeglinski
 

Sorry, for MY confusion, Ray.
 
    A bit muddle-headed this morning. Of course  APCC is “PC software”. The difference in CP3 versus CP4 firmware, in this regard, had me  briefly woolly-headed.
 
    My concern was the last sentence in your OP reply.
 
If ... your 1100 has a CP4 its firmware handles counterweight-up slews in a "safe" manner by always moving
> RA first to a counterweight-down position, then slewing to a target. Additionally, if the target is counterweight-up,
> then the last slew will be in RA only also.
 
(If your mount has a CP3 controller, then APCC performs these moves  ...  instead of the mount firmware.)
>
> -Ray
        My concern is what would happen IF THE USER specified the wrong CPx model being controlled by his APCC software? 
    Perhaps the APCC is  for some reason, being used with a CP3 at the time, and the user forgot to change the CP ID. Hopefully, APCC figures out the CPx controller model – currently attached to the mount -  during its initialization phase.
 
    There have been times, for example, when I switched my CP4 back to running with an old CP3, for some bug chasing as a comparison, or if m CP4 was out for repairs  a couple of times. I would hate to think that the mount was vulnerable to my pre-set APCC Limits confusion – whether the mount was going to perform the collision avoidance slew “ballet pirouette”, or the APCC would do it in software (anyway) , if I forgot to change the CPx ID,   somewhere in its mount initialization settings.
 
Thanks,
Joe
 
From: Ray Gralak
Sent: Saturday, July 24, 2021 11:00 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Preventing Pier Crashes
 
Joe,

> - Does the APCC  firmware itself, check whether it is communicating with a CP3, CP4, or CP5 –
> and handles the “software mode” Limits & Meridian switch points,  itself?

I don't know what you mean by "APCC firmware". Can you clarify that question?

APCC can set mount limits if configured to do so, but when *slewing*, mount limits are not changed in real-time as declination changes. When the mount reaches the target's declination, then the meridian delay and mount limits will be set, provided APCC is configured to do so.

-Ray


Ray Gralak
 

Joe,

My concern is what would happen IF THE USER specified the wrong CPx model
being controlled by his APCC software?
In APCC you can select the mount type, but you cannot select the controller type. APCC detects the controller by the firmware version returned from the controller. CP4's version strings start with "VCP4". CP5's version strings start with "VCP5", and CP3's are just "V", or "Vx", where "x" is a digit.

That said, in some cases if the user selects the wrong mount then APCC can detect and fix that. For example, Mach2's only come with a CP5, so APCC will automatically select "Mach2" if it detects a CP5. If the user selects "Mach2" as the mount type and a CP5 is not detected the mount type will be changed to a 1100.

I hope this answers your question?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Joe Zeglinski
Sent: Saturday, July 24, 2021 9:24 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Preventing Pier Crashes

Sorry, for MY confusion, Ray.

A bit muddle-headed this morning. Of course APCC is “PC software”. The difference in CP3 versus CP4
firmware, in this regard, had me briefly woolly-headed.

My concern was the last sentence in your OP reply.


If ... your 1100 has a CP4 its firmware handles counterweight-up slews in a "safe" manner by always
moving
> RA first to a counterweight-down position, then slewing to a target. Additionally, if the target is
counterweight-up,
> then the last slew will be in RA only also.

(If your mount has a CP3 controller, then APCC performs these moves ... instead of the mount
firmware.)
>
> -Ray


My concern is what would happen IF THE USER specified the wrong CPx model being controlled by his APCC
software?
Perhaps the APCC is for some reason, being used with a CP3 at the time, and the user forgot to change the CP
ID. Hopefully, APCC figures out the CPx controller model – currently attached to the mount - during its initialization
phase.

There have been times, for example, when I switched my CP4 back to running with an old CP3, for some bug
chasing as a comparison, or if m CP4 was out for repairs a couple of times. I would hate to think that the mount
was vulnerable to my pre-set APCC Limits confusion – whether the mount was going to perform the collision
avoidance slew “ballet pirouette”, or the APCC would do it in software (anyway) , if I forgot to change the CPx ID,
somewhere in its mount initialization settings.

Thanks,
Joe

From: Ray Gralak
Sent: Saturday, July 24, 2021 11:00 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Preventing Pier Crashes

Joe,

- Does the APCC firmware itself, check whether it is communicating with a CP3, CP4, or CP5 –
and handles the “software mode” Limits & Meridian switch points, itself?
I don't know what you mean by "APCC firmware". Can you clarify that question?

APCC can set mount limits if configured to do so, but when *slewing*, mount limits are not changed in real-time as
declination changes. When the mount reaches the target's declination, then the meridian delay and mount limits will
be set, provided APCC is configured to do so.

-Ray


Alex
 

On Sat, Jul 24, 2021 at 05:21 AM, Ray Gralak wrote:

Hi Alex,

Are the collision zones you mentioned in counterweight-up or counterweight-down position?

It can happen in a counterweight down position. For instance, last night, I was imaging m16 in the south on the east side of the meridian. Clouds rolled in right before reaching the meridian so I decided to call it a night and I parked the mount (park position one). The RA axis was essentially in the correct position so it only had to move a small amount to put the RA in the park 1 position. The DEC had to swing the scope from pointing south to pointing north. As it made this transition, the camera swung down as the scope rotated around and as it approached the zenith, the camera crashed into my pier as it protrudes too much for the scope to safely reach the zenith.

What I want to do is define this zone of death so the scope will never attempt to slew through this zone.

Alex


Ray Gralak
 

It can happen in a counterweight down position.
Can you post a few pictures from different angles of this scenario?

At present, I don't think there is a software solution. You might be able to first slew to park 3 before doing another slew or parking to park 1.

BTW, are you using Park 1 to fit the setup under a roll-off roof?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Alex
Sent: Saturday, July 24, 2021 5:45 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Preventing Pier Crashes

On Sat, Jul 24, 2021 at 05:21 AM, Ray Gralak wrote:

Hi Alex,

Are the collision zones you mentioned in counterweight-up or counterweight-down position?

It can happen in a counterweight down position. For instance, last night, I was imaging m16 in the south on the east
side of the meridian. Clouds rolled in right before reaching the meridian so I decided to call it a night and I parked the
mount (park position one). The RA axis was essentially in the correct position so it only had to move a small amount
to put the RA in the park 1 position. The DEC had to swing the scope from pointing south to pointing north. As it
made this transition, the camera swung down as the scope rotated around and as it approached the zenith, the
camera crashed into my pier as it protrudes too much for the scope to safely reach the zenith.

What I want to do is define this zone of death so the scope will never attempt to slew through this zone.

Alex


Alex
 

On Sat, Jul 24, 2021 at 07:43 PM, Ray Gralak wrote:
It can happen in a counterweight down position.
Can you post a few pictures from different angles of this scenario?
Ok, here the scope was at park position 1 and I've only slewed in dec.  As you can see, if I were to proceed any further vertically, the camera is hitting the pier.  You can see I've added some foam tape to that corner as this has happened before.  Perhaps I can somehow cut that corner off the pier plate.  I'd have to do the opposite corner as well as I have the same problem on the other side of the pier.



At present, I don't think there is a software solution. You might be able to first slew to park 3 before doing another slew or parking to park 1.
Sure, that would work if I'm manually controlling the scope.  I don't know a way of doing that if using SGP.  I've had SGP send the scope into the pier as well.

BTW, are you using Park 1 to fit the setup under a roll-off roof?
Yea, my roof is at a slight angle and a bit higher on the park position 1 side.  Why it's possible to close the roof while in park position 4, the clearance is very tight.  I feel much more comfortable using park position 1 as I have another inch or two clearance on that side.  Also, if the scope was to start tracking from park 1 while the roof was closed for some reason, it's the counterweight bar hitting the roof, not the scope.
 
Alex
 


Christopher Erickson
 

If it were me, I would be refabbing those pier plates to eliminate the conflict.

"My advice is always free and worth every penny!"

-Christopher Erickson
Observatory Engineer
Summit Kinetics
Waikoloa, Hawaii


On Sat, Jul 24, 2021 at 10:46 PM Alex <groups@...> wrote:
On Sat, Jul 24, 2021 at 07:43 PM, Ray Gralak wrote:
It can happen in a counterweight down position.
Can you post a few pictures from different angles of this scenario?
Ok, here the scope was at park position 1 and I've only slewed in dec.  As you can see, if I were to proceed any further vertically, the camera is hitting the pier.  You can see I've added some foam tape to that corner as this has happened before.  Perhaps I can somehow cut that corner off the pier plate.  I'd have to do the opposite corner as well as I have the same problem on the other side of the pier.



At present, I don't think there is a software solution. You might be able to first slew to park 3 before doing another slew or parking to park 1.
Sure, that would work if I'm manually controlling the scope.  I don't know a way of doing that if using SGP.  I've had SGP send the scope into the pier as well.

BTW, are you using Park 1 to fit the setup under a roll-off roof?
Yea, my roof is at a slight angle and a bit higher on the park position 1 side.  Why it's possible to close the roof while in park position 4, the clearance is very tight.  I feel much more comfortable using park position 1 as I have another inch or two clearance on that side.  Also, if the scope was to start tracking from park 1 while the roof was closed for some reason, it's the counterweight bar hitting the roof, not the scope.
 
Alex
 


Ray Gralak
 

At present, I don't think there is a software solution. You might be able to first slew to
park 3 before doing another slew or parking to park 1.
Sure, that would work if I'm manually controlling the scope. I don't know a way of doing
that if using SGP. I've had SGP send the scope into the pier as well.
It sounds like SGP cannot handle the scope's "dead zone." So, even if a way to avoid a slew collision is made available, some slews that SGP issues could fail and ruin your session. The best solution may be to address the mechanical issue that can cause a collision.

-Ray


M Hambrick
 

Hi Alex

I am not yet using APCC to control my mount, but I will relate the behavior that I have observed on my 1100 GTO (Non-AE) with the Keypad controller. When I first got the mount I set up safe zone limits for my particular imaging train. In doing so I mistakenly thought that this would prevent any pier crashes during slewing, but this is not the case. The safe zone limits will only prevent you from selecting a catalog object to go to that is outside the safe zone. If you select an object that is inside the safe zone, the mount will slew to it according to the slewing instructions that are programmed into the keypad, and depending on the geometry of your imaging train, you can get a pier crash.

Mike


Ray Gralak
 

Mike,

Was the pier collision you mention in a counterweight-down, or counterweight-up position? If it was counterweight-down, do you recall the circumstances?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of M Hambrick
Sent: Saturday, August 7, 2021 12:53 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Preventing Pier Crashes

Hi Alex

I am not yet using APCC to control my mount, but I will relate the behavior that I have observed on my 1100 GTO
(Non-AE) with the Keypad controller. When I first got the mount I set up safe zone limits for my particular imaging
train. In doing so I mistakenly thought that this would prevent any pier crashes during slewing, but this is not the
case. The safe zone limits will only prevent you from selecting a catalog object to go to that is outside the safe
zone. If you select an object that is inside the safe zone, the mount will slew to it according to the slewing
instructions that are programmed into the keypad, and depending on the geometry of your imaging train, you can
get a pier crash.

Mike


M Hambrick
 

Hi Ray

FYI I was not running APCC when this happened.

Luckily there was no actual pier crash because I was there watching the scope and mount and pressed the stop button on the keypad. Unfortunately I do not recall the exact circumstances or objects, but I am pretty sure that the counterweights were down.

Mike


Eric Dreher
 

Even not running APCC, pier crashes are not impossible.

The following happened about two weeks ago.  I was at the scope, setting up RD to observe activities from inside my home, with a NUC atop my rig.  I'm completely portable, so I need to PA every time I'm photographing.

Using SharpCap, I was slewing my scope to the 90 deg move needed when it just kept on going.  The driver emergency stop was completely non-functional and useless as I watched my Mach1 pier crash for the first time.  I jumped up and disconnected the power cable from my CP4 and started from scratch.

The first thing I checked was my cables.  As soon as I touched the CAT5 at the CP4, it literally fell out of the RJ45 connector.  Apparently I hadn't double-checked the physical connection when plugging in the cable earlier, and it had lost connection at the perfect time to start the slew but not allow it to stop when I released the driver "handset"button.

Things happen.  Never say never.  Cable duplicates are a must to have on-hand.  The CAT 5 wasn't defective, but it couldn't gone bad just the same, and with the same results.

Yes, I do have spare motor cables, as well as everything else.