Recently encountered a new issue w/ SGP 2.6.0.24 and my AP Mach1-GTO w/ CP4.
After a session completes, and SGP parks the mount, the mount goes to its park position, reports parked, but then suddenly reports “unparked” but not tracking.
Saw a post in the AP GTO group about an identical issue, and the explanation given there was that this was due to this change in SGP 2.6.0.24 :
Any park command issued through SGPro will now be followed by a stop tracking command.
The issue appears to be, according to Ray Gralak
Immediately after the park had completed, it looks like SGPro (or some other ASCOM application) read that the park completed but then sent an ASCOM command to disable tracking. Part of disabling tracking is to stop any slews in progress, which requires sending a “Q” command. Unfortunately the “Q” command does double duty in that it will unpark the mount.
From Howard in the AP-GTO group :
Quit does NOT mean “quit tracking.” It stops slews and directional moves (button moves). It also terminates a parked state or a stall condition.
While I understand the “safety/sanity check” nature of forcing tracking to stop after parking, it seems that for any well-behaved mount a parked state is by definition not tracking.
Could we, then, perhaps have this feature/sanity check implemented as an option when this version gets released?
I can remove the command to stop tracking after park. I have never been a fan of it because it is designed to help handle misbehaving mounts (we don’t typically write code to do that and I can’t remember why we did in this case). Anyhow, if the code to help support misbehavior is affecting proper behavior, it’s not an issue to remove it.
Hi Ken,
It gets my vote too. I’m still evaluating SGP (16 days trial remaining) to be used with an AP1200 mount, so I was a little concerned to read the thread on the AP-GTO group that mentioned SGP restarted tracking after parking the mount. I still have lots of SGP set up still to work through / learn, but I’d be pleased to know that ‘Park’ meant park with no tracking.
Regards,
Geof
To be clear, Geof, the AP should not start tracking again. It will (or at least mine has, and the other report in that group is the same) stay where you parked it, not tracking…it will simply report to any ASCOM client that asks (like SGP) that it is Unparked.
As a result, this is a relatively “minor” issue…it doesn’t change the physical behaviour of the mount…it just leaves it in a state different than we expect to find it. Unparked, when we expect Parked.
I have been using SGP with my AP1100GTO for two years. At end of sequence, the scope parks – period. It may be desirable to remove the stop tracking command to avoid an issue with a future update to the AP ASCOM driver or with APCC but, currently, I see no practical implications on the behavior of the parking command.
Yep, that’s what my Mach1 had always done as well…until this latest beta. heh
Now it parks…and then says it’s no longer parked. It doesn’t GO anywhere…it’s stopped, motionless. So you’re right…there’s no real negative implications yet, though as you suggest there may be in future if things change on the ASCOM side.
It’s more just a matter of “Wait…if it’s parked, why does it say unparked?” and then finding out this was the result of a change to SGP having unintended consequences. Figured I’d bring it to their attention, and ask if it might be possible to make it optional behaviour, since it’s clearly there as Ken says “to help handle misbehaving mounts” which, in general, our APs aren’t.
although i think there is evidence that the AP driver is misbehaving, as chris has said that the only thing that should unpark a parked mount is the “unpark” command, and the AP driver is unparking the mount when SGP issues the “Q” command.
