SGP Beta looses connection to mount

TL;DR version: SGP is the only program that stops talking to my mount sometimes.

Long version: I’m running the latest (Beta) version of SGP, so I am not looking for support so much as I am reporting this issue in the hopes it can be looked at / asking what additional info you need from me? (however please note that I have had this issue occur in the prior version of SGP, I just haven’t reported it because I thought it was possibly a cable / hub issue but I replaced those).

PC: ASUS laptop running Windows 8.1 all windows updates installed (I’m likely going to bite the bullet finally and upgrade to Win10 in the near future).

Equipment list:
Mount- Orion Atlas Hypertuned, using the shoestring astro USB cable. Using EQMOD latest version and ASCOM latest version.

Main camera ZWO 1600-mmcool
Filter wheel EFW (zwo) 8 slot
Moonlight Focuser
ASI291 mini guider cam
Polemaster

The guide camera get’s plugged into the USB hub that’s part of the 1600, the filter wheel as well. Then the USB 3 from the 1600 goes into one of the two usb 3 ports on my laptop.

The other usb port from the laptop goes into a new usb 3 hub (https://smile.amazon.com/dp/B00WE65I5K/ref=cm_sw_em_r_mt_dp_U_dSFTCbJ9CQJ4K) Atolla 4 port USB 3 It’s a $10 hub because I basically end up replacing it every year or two cause of field wear. That’s connected to the laptop with a USB 3 extension cable that’s 6’ long. From the hub I have the Polemaster, the Moonlight Focuser, and the Shoestring Astro cable to the mount.

In operation I know that SGP has lost it’s connection to the mount because I will try to center on a target, so either I command a slew (the rarest occurrence), or most often I command or the sequence commands a “center on target” and the platesolve route runs. When this happens SGP will solve the initial frame, attempt to move the mount 1 to x number of times. When the mount connection get’s lost the next place solve frame will have the exact same or extremely close Number of pixels off-target counts. That is usually how I tell that this error has happened, that the center sequence window is showing me 2 or more tries to move the mount but the pixel counts did not change.

When things are working correctly SGP usually has things centered up within 3-5 moves at most.

Since I’m planning on upgrading this laptop to Win10 I’m likely just going to wipe it completely and start over, install win 10 from scratch and then download and install ASCOM and the rest since this is now my dedicated astro PC. However before I do that if there are any log files etc that would be helpful in troubleshooting please let me know and I will grab them off.

Also worth noting is that SGP is the only program that seems to have this issue, or at least the only program that I have noticed it with. I have used Stellarium with Stellarium Scope with no issues. I use PHD2 for guiding and have never had any issues with PHD2 loosing the mount connection. I have also tried the trial version of Prism with this setup and had no issues. I also occasionally use SharpCap Pro and Firecapture with this setup, they display mount position and let you slew and no issues there.

Thank you in advance!

Your problem description does not match the title. The problem you describe is that the mount will not center. Is there an actual error message that states the mount connection is lost, either in SGP or in the log file? The log file is essential to work through the problem (either the ASCOM one or SGP’s). It is too soon to assume what is at fault. For instance, are you using a pointing model in EQMOD? That has been the cause of more than one issue in this forum as it can fight attempts to sync.

One of the symptoms is that the mount fails to center, there after SGP won’t pass any commands to the mount (won’t slew, won’t center, can’t use what I call the nudge buttons). That is why I titled the post the way I titled it.

When I get home from work I’m happy to provide a log from my last session, I have not looked at the log yet, I am describing the symptoms.

Please explain “fight attempts to sync”, as the pointing model should be accepting the new sync input points to the model in EQMOD. I could see this potentially being at issue for initial pointing, but I don’t see how that would play into the commands not reaching the mount at all, especially things like a slew command (incorrect pointing model should mean that the scope would just point at the wrong point).

As described other software, such as PHD2, Stellarium Scope, etc will all continue to issue commands to the mount when this condition occurs with SGP.

I recall some other forum posts that established that if EQMOD has a model, the centering process in SGP would not center properly if using the sync method.
I have a Paramount and the same happens with a TPoint model. The workaround is not to use the ‘sync’ method, but a target offset method (in centering options in SGP). It then works perfectly.
Not all mount APIs implement the nudge buttons (e.g. my PMX does not support them). Do the nudge buttons work otherwise from SGP?
SGP issues ASCOM commands and it relies on the ASCOM interface. SGP basically issues the same commands to ASCOM, irrespective of the mount (that’s the purpose of ASCOM after all). The general command logic is the same in each case and so, one would expect to see more widespread reports. The mount ASCOM driver is the most complicated to implement and while that does not rule out SGP having a gremlin, it would be instructive to see what the driver believes it is being told by SGP and EQMOD.
What I cannot tell you is how that then affects subsequent operation. Relating to my PMX, if the ASCOM driver gets an exception from TheSkyX API it disables that particular ASCOM method, but the other methods still work. I have to go into the ASCOM driver settings and re-enable the features. Other apps may still work but take into account that not all applications use all the ASCOM methods (e.g. I don’t think PHD2 issues slew or park commands) Something similar may be happening in your case. What on the surface may seem very simple can be subtle and difficult to nail down.

@rottielover Will definitely need logs to troubleshoot.

Also, please note that SGPro / EQMOD users will often have a variety of problems… Enough so that we have attempted to create a section in the help file to address common scenarios. Have a look here: http://www.mainsequencesoftware.com/Content/SGPHelp/UsingEQMODwithSGPro.html

This is what’s jumping out in the log files to me, it appears from the first solve thru to the last attempt.

[04/12/19 21:12:48.402][DEBUG] [Center Scope Thread] Error in auto center update thread, Thread was being aborted.

Otherwise the log looked clean. Ultimately decided to bite the bullet last night and I wiped the laptop completely, installed Win10 from scratch and re-installed everything.

Clouds rolled in around midnight but I did not have any repeats of the issue from 9-11 and I had it center on about 12 targets.

I noticed that platesolving is a lot faster now! Not sure what else I may have had going on, but it’s certainly looking like the wipe and fresh install of everything helped a lot.

Did you get this resolved? I seem to have pretty much the same kit as you and have the same issue - guiding is fine but SGPro is dropping the connection to the mount. I checked the EQMod logs and cant see any error in there and PHD2 guides fine so I assume its an SGPro error. This only started happening a couple of weeks ago. Im on 3.1.0.479