toggle quoted messageShow quoted text
Yes, this seems like a bug and is already on my list to investigate. I have just barely caught up with answering online and private offline questions, looking at logs, etc. This hasn't left me much free time to focus on fixing the issues reported.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of ap@...
Sent: Sunday, August 29, 2021 8:59 AM
Subject: Re: [ap-gto] APCC move axis question
You should disable tracking/pointing correction during polar alignment routines, or you may get a bad polaralignment result.
That's a fair point, but really steps around the core issue.
As a simple example, the NINA control panel has simple N/S/E/W controls. These stop working when pointing
corrections are active. I have no idea if there are other places in other programs that also use move-axis.
Should these in fact be failing when pointing corrections are active?
I just tried a trivial example:
- Opened APCC, initialized (tracking = 0), pointing corrections disabled
- Opened NINA, connected
- Using NINA control slewed N, then S - worked fine, fast (APCC showed it slewing)
- Checked pointing corrections
- Slewed N, S - no motion. Only thing I saw on APCC (or maybe ASCOM V2) was flickering from custom to
sidereal rates as I pushed the button
This itself is hardly an earthshaking issue since I can just use the APCC controls to slew (if my sleep deprived
brain can remember in the wee house), but it does bring with it a concern that other features of NINA or other
software connecting via ASCOM my not work.
Or is everyone pretty sure this is a very isolated case and nothing else uses move axis?
Or are you saying that Move Axis itself, if allowed, would break the pointing model?
PS. Logs available if desired from that brief test.