SGP (3.2, 32 bit) could not seem to get communication back from my other programs last weekend. I was using a computer that had worked with SGP many times before without any problems.
It connected to everything as it should (I thought). It autofocused. It could slew to the target, and stop in the general location from what I saw. However, when I “Centered,” it would go through the first line of he centering routine, slew a touch, and then just wait, displaying the message that it was “Waiting for Equipment to idle.” The only way out was a Ctrl-Alt-Delete/Task Manager/End SGP. Finally got tired of messing with that, and decided to just do without the Plate Solve/Center. Centered using Cartes Du Ciel and nudging. And started taking pictures.
Except, although the guide camera definitely had stars, and selected them, and was running, and guiding well, SGP just kept waiting for the guider to respond that it was ready. Again the only way out was Ctrl-Alt…
In other words, SGP did not appear to get word back from the auxiliary programs (AP Mount interface, and PHD2 ) that it was ready to go.
Reinstalled SGP, rebooted computer, and all that. No improvements. Then the clouds came and made it all a moot point for that night!
I had the same thing happen with mine. Since it seems like you won’t be able to use the scope for a while, I’ll send in a log. PHD2 recently got an update, too, by the way.
Well, I am back in the desert, and trying this again.
Still have the same problem.
I tell it to slew to a target, it slews and stops. It returns control of the program (SGP) to me.
I tell it to center, it goes to Step 1(Determine reference…) and jumps to Step 2 (Slew to…) and just sits there, with the strip moving across repeatedly, showing it is slewing. IN fact is it not slewing (it was already there). I press "abort " after a bit, and it just continues to flash that stripe across. The only way out is usually Ctrl/Alt/Del task manager / cancel SGP. (It once aborted using the abort button. i have waited five minutes after abort, and got nowhere.
That’s fine… whatever way works best for you. You can actually post logs straight from SGPro, but sounds like maybe there is no internet?
In any case, the logs came across fine and what it looks like to me is that there might be a problem with the observatory (or observatory driver). In the logs you attached, it shows that the observatory is slaved to the telescope and, upon start, the telescope slews without problem, but when the observatory attempts to follow, it never reports that it is done. We really should have a timeout here with a reasonable error message and I’ll see to that.
Resolving the problem may require assistance from the driver’s author, but essentially, start with the basics:
Check all the relevant connections and cables
Uninstall the driver, then re-install it
If the issue is still present:
Collect ASCOM trace logs for the observatory (and product specific logs of they exist).
Send them the part of the log where SGPro asks the observatory to follow the scope (normal slew).
In the SGPro logs, it looks like this:
[06/08/23 21:29:13.690][DEBUG][Telescope Thread][CE;] Telescope: Calling Observatory Slave Slew
[06/08/23 21:29:13.692][DEBUG][Telescope Thread][CE;] DestinationSideOfPier Received from telescope as pierWest
[06/08/23 21:29:16.449][DEBUG][Telescope Thread][CE;] Scope reports it is done with synchronous slew, verifying...
[06/08/23 21:29:16.627][DEBUG][Telescope Thread][CE;] Telescope: Observatory is reporting slewing
[06/08/23 21:29:17.643][DEBUG][Telescope Thread][CE;] Telescope: Observatory is reporting slewing
[06/08/23 21:29:18.663][DEBUG][Telescope Thread][CE;] Telescope: Observatory is reporting slewing
[06/08/23 21:29:19.682][DEBUG][Telescope Thread][CE;] Telescope: Observatory is reporting slewing
I have contacted Astro Physics, and spoken with George about it. He suggested that first step is to update to the newest control chip (for the internal electronics of the scope). It is on the way, and I will install it this weekend.
Using a different session manager, I did have a successful evening last Friday night. The scope slewed, centered with plate solve, meridian flipped, and all that. But I prefer to get SGP working with it, since I like the interface better. In other words, with a different session manager, the ASCOM driver did work correctly.
After updating the control chip, I will get back to you as to progress.
Ok, thanks for letting us know. SGPro can be pretty hard on drivers. Because it is a multi-threaded application where it runs the sequence, communicates with equipment and updates the UI all on different threads it can sometimes expose situations where a driver is expecting to be queried only in a serial manner which can produce results like this. I am not implying that this is the issue only that it has happened more times than I can remember. If you remove all the complexity of threading, we are left with a simple statement:
When the observatory is slewing, SGPro will directly query an ASCOM property named Observatory.Slewing. and that property (from the driver) is continuously stating that it is still slewing.
BUT… if SGPro is indeed at fault here, the ASCOM trace log will show this almost immediately as they detail all these property queries and show what the driver is responding with… If it shows a bunch of queries showing that the driver still thinks it’s slewing, then it is a driver / hardware issue. If it shows no such query then it could be that SGPro had gotten itself into a state where it is no longer talking to the driver, but is not aware of a disconnect.
If you are inclined to grab trace logs for the observatory, you can find guidance here:
I thought I sent a message the other night…But I do not see it, so I shall re-do it…
Before I had a chance to update the chip, or anything else, I started the system, and was going to use another session manager to get started. But it needed a plate solve, and I could not get it to solve. So I went back to SGP to get a plate solve, and it did. Great.
And, since I was here in SGP, I told it to go center on the target I was looking for that night. Fully expecting a failure after the slew. And, it slewed, stopped, took its pictures, solved, and acted as if everything was back in the olden days (three months ago) when everything worked right.
In other words, it is working fine now. But, I never figured out why. I had not (yet) done anything different.
Thanks for the help, and sorry for the bother.
Alex