Center Here and Slew Here Fail

I am running SG Pro Version with the following equipment and software:
William Optics FLT-132 refractor
QSI 583wsg CCD camera
Astro-Physics 1200 GTO Mount with CP4 controller
APCC Pro Version
AP Driver V2 5.20.09
PinPoint Version 6.1.5
PHD2 Version 2.6.6

A couple of months ago I upgraded from SG Pro Version to Since then, the Center Here and Slew Here functions, which ran flawlessly with the old version, no longer work. When I initiate a Center Here operation, SG Pro appears to perform the prescribed steps of taking and plate-solving a reference frame, slewing the scope to its new position, and plate-solving a validation frame, and then repeating the process until the image is centered within the required tolerances. However, the validation fails because the slew is never actually performed, so the object remains in its original position.

For the same reason, the Slew Here operation also does not work - SG Pro thinks the slew is being performed, but it is not.

Ordinary plate solves, not involving Center Here, still work. Plate Solves performed in connection with meridian flips also still work. So apparently the problem is not with plate solving per se, but that the slew command is not being sent to (or not being received) by the mount.

I took a couple of screen shots to illustrate the behavior described above. Note that although Step 3 proclaims that the validation frame was successfully solved, the window showing the list of attempts indicates that the validation was unable to achieve results within the allowable margin of error. Here are the links:

And here are the links to a couple of relevant log files:

I haven’t looked through your logs, but most likely it’s either that your driver/mount has sync turned off or that a model is saved and therefore a new sync point will just make a small change to the model.
An easy fix would be to set SGP to target/scope offset.

Thank you. I’ll try it.

I tried your suggested fix and it did not work. The relevant log and screenshot are attached.

In my Astro-Physics V2 driver, Sync is set to RCAL, but this has always been the case, and Center Here worked fine before the installation of version Nor have I ever set up a pointing model.

If there is no fix for this, I am contemplating reinstalling version, if that is possible.

Thank you

Jerry L. Floyd

(Attachment sg_logfile_20190503195553.txt is missing)

Sorry, I forgot that the log file would be rejected. Here is my dropbox link:

Thank you


@bazarov You are welcome to try, but I have doubts that regressing the version of SGPro will do anything to correct this situation. SGPro asks the mount to move, it does something for about 1.5 sec and then reports that it is done. It is certainly possible that I am wrong and something is happening that I don’t understand… BUT changing the version of SGPro will not affect that observation. The issue seems to be happening when you are close to your target… I see a successful attempt when you came from some distance away.

The suggestion that @Xplode gave is valid and your logs show that you still had this setting set to “sync”.

[05/04/19 23:29:16.877][DEBUG] [Telescope Thread] Telescope: Sync behavior set to "Sync"...

Setting this to “Target Offset” might not be the end fix, but it will tell you if the problem originates with a sync issue with your mount. Ultimately, an answer will be easier to find if you have the AP mount logs to look at side by side… What the mount does exactly when SGPro asks it to do stuff is not exposed in detail to SGPro.

1 Like

You are right – reverting to 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

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

For the Meridian flip the file is APCC_log_excerpt_20190702MeridianFlip.docx. The Dropbox link is

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 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:

  1.  Reinstall a previous version of APCC and/or the driver, but this is hardly a satisfactory solution for the long run.
  2.  Ditch APCC and using only the A-P ASCOM driver.  However, I find APCC in general useful and would prefer to keep it.
  3.  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.


Jerry L. Floyd


Hi Jerry,

I assume you have a GTOCP4 controller? If so, it sounds like your mount firmware might be out of date. The latest is “VCP4-P01-13”. What version are you running? (It shows in both the driver and APCC).


Hi Ray - Yes, I do have a GTOCP4. I’m at home and can’t connect right now - I’ll try to get up to my observatory in the next couple of days and check on that.

  • J. L. FLoyd

I have this happen from time to time and in my case it is backlash. So…try this. Slew to your target but before you CENTER nudge your mount both N and W until the star moves. I use the manual mode in PhD2 to both move the mount and watch for star movement. Once the star moves…go back to SGP and elect CENTER - in my case with the backlash removed, I get the solve pretty quickly. Hope this helps.

It also helps to do this before I calibrate my mount using PhD2.

Clear skies!

Thank you, I’ll try that.


@Nikonshooter, sorry I don’t think that’s the problem here. I think Jerry is running out of date firmware, which is the reason the mount does not understand the final short move started by the Astro-Physics specific command :M_S#.


rgralak - you are probably right. My guess is that his Astro Physics mount does not have the ton of backlash my Atlas Pro EQ/AZ mount does but his problem sounded so familiar just thinking it was worth a try. The “Centering” process often involves moving the mount E and S…when that happens backlash renders the subsequent nudges ineffective and the failure to move the mount during a solve just repeats itself or until the gear slop has been taken out but multiple nudges. I run two Atlas Pro mounts at a time and have had this problem with both. I thought sending them off to be hypertuned would help but it didn’t. So in my case N and W nudges are needed as soon as I get a Centering report that shows the same error or nearly the same error. As soon as I do the nudges - I can then select Centering and walla…problem solved for me. I have to do this also when I have to calibrate my mount in PhD2.

Hi Ray - you are correct in thinking that I’m running out-of-date firmware - just checked and it’s VCP4-P01-00, must be the original firmware that came with the GTOCP4. I’ll try to update it when I can download the latest - A-P requires me to enter a username and password for the download and I don’t seem to be able to find those in the documentation, and they haven’t yet responded to my request to send it to me via email. I haven’t been keeping track of firmware updates - obviously that’s something I’ll have to rectify. Thanks very much for your help.