Re: Mach2 tracking below custom horizon


Luca Marinelli
 

Hi Ray,

In light of this, is it a better option to choose “Bounce back and stop tracking” in APCC rather than “Stop Tracking” when the limit is reached so the mount is never in “forbidden” territory even if the application turns tracking on again?

Thank you,

Luca

On Jan 21, 2021, at 7:58 PM, Ray Gralak via groups.io <groups3=gralak.com@groups.io> wrote:



the Western horizon), shouldn't APCC not allow that command to take place? What's the point of horizon limits in
APCC if any application can tell the mount not to abide by them?
Tracking must be enabled (an ASCOM "rule") to allow certain actions, including to slew the mount out of horizon limits.

APCC cannot pre-determine what the client application will do when enabling tracking, so it must allow it.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
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 Luca Marinelli
Sent: Thursday, January 21, 2021 2:04 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Mach2 tracking below custom horizon

I'll run the test Dale suggests but I ask a more fundamental question. A big reason why I use APCC instead of
just the AP ASCOM driver is to provide a layer of safety in the operation of the mount to prevent pier crashes. If a
third party application issues a command that is unreasonable (for example, start tracking when the OTA is below
the Western horizon), shouldn't APCC not allow that command to take place? What's the point of horizon limits in
APCC if any application can tell the mount not to abide by them?

Best,

Luca




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