You are right – reverting to 3.0.0.7 did not help. Center Here and Slew Here still do not work. Auto-centering in both versions seems to fail in the same way.
Worse yet, the failure of auto-centering causes meridian flips to fail. That is, SGP performs the meridian flip slew, but the subsequent auto-centering operation fails, so that the sequence aborts.
I looked through the A-P logs which cover the time periods involved in the Center Here and Meridian Flip operations. They are enormous, especially the APCC logs. It appears that sometime after initialization, the driver hands off logging operations to APCC, so that the latter’s output constitutes the exclusive record of the operations of interest here.
On 7/2/2019, at time 00:50:12.282, SGP determined that a Meridian Flip was needed. Sync behavior at that time was OFFSET. The slew was duly performed and SGP took a verification frame, plate-solved it, determined that an auto-center was needed, and issued an “Auto center slewing scope to match reference…” command. After capturing and plate-solving another verification frame, SGP declared that “Total Error > Allowable error: 607.8 > 50.0”. It performed the auto-centering operation twice more, with similar results (604.0 the second time, no total error recorded for the third), with similar results, then wrote the entry “Unable to achieve results below allowable error (50 px) in 3 attempts!” followed by other dire declarations, culminating with the message “Sending Notification: Error - Failed to meridian flip, aborting sequence.”
Examining the APCC log for the same time period, I found that at 00:51:54.249, it reports an “:M_S#” command, which I think is a slew. (The A-P command reference lists only an “:MS#” command, but I assume M_S is just a variant. The :MS# command is defined as “Slew to the most recently defined RA and DEC coordinates in RA-DEC mode. The most recently defined coordinates were logged as RA 18:03:53.2 and DEC -22*58:59, the approximate coordinates of M20, which happened to be my target at the time.) Shortly thereafter, at 00:51:54.350: the entry “Exception, ProcessQAC: ComPort Read error. Sent=:M_S#, The operation has timed out.” appears. Subsequently, at 00:51:54.351: the message “Error, mySlewStarted, No response from mount” is recorded.
I find this sequence repeated twice more, with the ProcessQAC message occurring at 00:52:37.431 and 00:53:21.006. I haven’t been able to find a reference for “ProcessQAC” yet, but “The operation has timed out” seems straightforward enough.
I found the same sequence of messages recorded in connection with a “Center Here” operation I had initiated earlier, 07/01/19 20:59:41.040.
The SGP entries for the both the Center Here and Meridian Flip operations are recorded in sg_logfile_20190701201024.txt. The Dropbox link is https://www.dropbox.com/s/r1mksdsqyqb0v4w/sg_logfile_20190701201024.txt?dl=0
The APCC log file covering the same time period, at over 97 MB, is too huge to be useful here, so I made excerpts for the relevant time periods. The excerpt for the Center Here operation is APCC_log_excerpt_20190702_CenterHere.docx; the Dropbox link for it is https://www.dropbox.com/s/ncd0advb5r3udyh/APCC_log_excerpt_20190702_CenterHere.docx?dl=0
For the Meridian flip the file is APCC_log_excerpt_20190702MeridianFlip.docx. The Dropbox link is https://www.dropbox.com/s/1hwkm7pgutq7h6h/APCC_log_excerpt_20190702MeridianFlip.docx?dl=0.
I’m not entirely sure what to make of all this. The SGP log entries are clear enough, but the APCC log entries, though voluminous, don’t seem to provide much enlightenment on the reason for the error, which appears to be a timeout. Consulting the APCC driver manual (APV2_ASCOM_Driver_5.20.xx.pdf), Section 2.2, I found a timeout setting for the APCC Virtual Port, about which the manual says
Timeout: the number of milliseconds to wait before retrying a command. Usually the mount will respond in less than 100 milliseconds so we recommend you start with 100 or 200 msecs. If you experience timeouts try increasing the timeout. A higher timeout value will decrease the responsiveness of the driver if there are communications problems. When the COM port is one of APCC’s virtual ports command/response exchanges between the driver and APCC usually require a much higher timeout (1000-5000 msecs). APCC optionally can set the timeout in the appropriate range but if you experience timeouts then check that this setting is set appropriately. This is required for now because if APCC’s user interface becomes very busy it cannot get to receiving and responding to driver requests until the user interface completes its update. This is planned to be addressed in a future version of APCC (which is currently 1.5.x).
I checked the timeout for my setup and found that it was already set to 1000 ms. I reset it to 5000 ms and found that the only effect was to prevent the Meridian Flip slew from being performed at all.
From this experience I have tentatively concluded that APCC and SGPro may not be 100% compatible at present. However, the problem only appeared after I updated both APCC and the A-P ASCOM V2 driver (to version 1.7.1.1 and 5.20.09, respectively) on 3/30/2019, so prior versions apparently were compatible. In any case, as far as I can tell, the source of the problem is not in SGP but in the Astro-Physics control software – APCC and/or the A-P ASCOM V2 driver. Guess I’ll contact the APCC folks and see what they have to say.
It appears that there are several possible alternatives open to me for resolving the issue:
-
Reinstall a previous version of APCC and/or the driver, but this is hardly a satisfactory solution for the long run.
-
Ditch APCC and using only the A-P ASCOM driver. However, I find APCC in general useful and would prefer to keep it.
-
Ditch SGPro and use some other software for image capture, but I don’t know what that would be. I find the obvious alternatives, such as MaxIm DL and The_SkyX Camera Add-on, unsatisfactory for various reasons which I won’t go into here.
If you have any other suggestions, I’d like to hear them.
At this point I am leaning toward trying option #1, and if that doesn’t work, option #3. In the long run, I’m hoping a future update to the A-P control software will make the problem go away.
Thanks for your help and please accept my compliments on a product which, while not perfect, at least has proven imaginative, versatile and very cost-effective.
Cordially,
Jerry L. Floyd
