Re: Preventing Pier Crashes


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

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