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.
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.
From: Ray Gralak
Sent: Saturday, July 24, 2021 11:00 AM
Subject: Re: [ap-gto] Preventing Pier Crashes
> - 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.