Just found this bug, while practicing on a recent APCC-Pro install: (ver. 1.02) using ASCOM-V2 driver ( 5.06.04), on my AP-900 CP3 (V-Beta chip - May 16, 2014) – I fortunately have it indoors for testing right now. I wanted to get some practice on using the APCC, as well as to find any operational inconsistencies. My CP3 Beta V-chip firmware was next to being the final version, so maybe it explains the following situation.
After running tests for most of the day, I discovered that if you issue any standard Park command (e.g. Park-2), the AZ and ALT were each just one arc-second short of being correct. For example, the CP3 reports (AZ = 89:59:59 and ALT = -00:00:01) . I didn’t think that it mattered, since it didn’t, back when I was running just using the ASCOM driver.
However, if you shutdown the APCC session, and reply with OK, just when the CP3 is at these coordinates – only one arc-second shy of being “precisely orthogonal” - the Virtual Display saves the OTA position in Park-2 as being UNDER the mount, at the north side. I read that the APCC would not allow going to a negative ALT angle, but it does, when the CP3’s low angular precision, reports it that way. Doesn’t take much drift in the encoders to get into this situation. Perhaps the Park angles need to be rounded up to zero and 90 degree multiples.
Then later - when you restart APCC, the OTA is shown starting from UNDER the mount, and stays there even as sidereal tracking has moved the scope into positive angles, away from Park-2. The 3D View doesn’t correct itself, since you started from an odd position, and it could be a valid orientation, if the scope fits. The display just continues tracking from there.
Likewise, in this situation, issuing a Park-3, the OTA goes North, but reverses the OTA, pointing down at the ground and cutting right through the pier ! It is very difficult to correct this anomaly. However, all the coordinate displays in all boxes of APCC, and those in ASCOM panel agree and are correct. The mount slews parks normally – it’s just that you can’t believe the 3D display with that kind of startup condition.
Perhaps the standard Park Positions should be rounded to positive angles after a park, so the 3D display would save the “intended” correct scope position. Luckily, while the 3D View shows a collision, the actual mount & scope is not really crashing – but it is a false indication for a remotely operated telescope. It is just a result of a “program shutdown” conditional anomaly.
I found a work-around for this problem. After issuing a Park-2, I immediately unparked the mount again, and let the mount “drift” for a few minutes, into a slightly positive ALT-AZ angles, before shutting down the APCC app itself – with the mount still tracking. This then at least saved the “coordinates” with the scope at approximately the correct Park-2 position, and resumes from it, at the next APCC launch. Of course, the mount is not really parked at Park-2 (or any of the other three orthogonal Alt-Az coordinates), but close enough. So, when you resume the next APCC session, “from Last Parked position”, the 3D View startup now looks correct.
Otherwise, using APCC is a pure joy to use, even though the 3D display is a bit scary right now, requiring an awkward shutdown procedure – if you use the standard Park positions.