Win 7, SGP 2.4.1.4. A few different problems tonight. When I start a sequence, or restart one after a pause, SGP gives me a “ready” message in the bottom left corner, then does nothing for a few minutes. If I touch anything during this time, it crashes. If I leave it alone, I eventually get a message telling me the autoguider has stopped and asks if I want to have SGP restart it. It then restarts it and begins the sequence. It does this even though PhD2 was running just fine until I tried to start the sequence. It seems that SGP stops PhD2, freezes for a while, then reports on it. Downloads of each sub frame has also dramatically increased recently to around a minute from about 15 seconds. Also if I watch the PhD2 graph, it seems that the autoguider is still returning from the dither when the next frame has already begun with the imaging camera. It shouldn’t start the next frame until it has settled at under 1.5 arc seconds for a few seconds. Here is the log.
Couple of guys have had similar problems using PHD2. They went into the Control Panel (in SGP)…clicked on Auto Guide and changed the Settle Option to 2.5 pixels and everything seemed ok after that. They also tried NOT using dither and that also seemed to work.
Also check settings in Equipment Profile Manager under Auto Guider . The Profile Manager may be overriding your Control Panel settings .
I am not really sure. We have not gotten a bunch of complaints like this for the beta (this is the first really). While I can see it really happened in the logs, the socket connection to PHD2 is just bad and I’m not really sure why. When we close it and try again it seems to pick up on the socket just fine. I cannot reproduce this behavior. Starting a sequence with PHD2 guiding or not seems to produce the intended behavior. Maybe you can send your actual sgf file and we can see if it is some combination of settings you have selected.
This is because your image files are enormous and you have the image history option on.
I’m happy to say that the problems are solved. It looks like it was a USB cable or hub problem. When I tried to start a sequence tonight, SGP froze again, only this time telling me it was connecting to the camera. It never unfroze, and I had to restart. This indicated to me that it might be a cable/hub problem, so I unplugged and replugged each device, and it no longer hangs, and no longer stops PhD on beginning a sequence. And as a bonus, my image download times are now back down to less than 20 seconds. This is the first time I have encountered a USB cable problem. I understand they are not uncommon, and will try to upgrade my cables. Thanks once again for your time.
I am having a similar problem. Using 2.4.1.3 if I have PHD2 (v2.5.0) already guiding and I start a sequence, both SGP and PHD2 appear to hang, both title bars say (Not Responding). If I wait approx. 3 mins, they come to life again and SGP gives a popup stating that:
“The auto guider is not running or the connection to it is lost. The sequence will attempt to re-establish the connection and start guiding prior to the first frame. Would you like to force the guider calibration prior to start?”
Yet, even before clicking on ‘no’ PHD2 can be seen to be guiding. I click no and the sequence starts.
This is 100% repeatable. Now if I don’t have PHD2 guiding before starting the sequence, then the sequence starts as it should, again 100% repeatable.
I have the Settle Option to 0.3 pixels
I know what you going to say, can I send a log. Sorry but no, for some reason all the past logs that had this problem are no longer on my drive. I do not remember deleting them, there are just logs from the last week, which were not imaging sessions anyway. Are they time limited and get deleted after a set period?
I seem to be having the same issue. I’ll start PHD2 guiding, then start sequence in SGP, 50% chance it will hang up with a not responding message in the title bar. Haven’t had the patience to wait long enough to see if it comes back as I usually park the mount and restart. I’ll have to try the other suggestions next time. Did save the logs from PHD and SGP from last night. The problem started about 22:57. Seems SGP isn’t getting a response from PHD, even though PHD appears to be guiding. PHD2 2.5 version and SGP 2.4.1.4 version
Later on we see SGP try to make a second connection:
[5/2/2015 10:59:39 PM] [DEBUG] [PHD2 Listener Thread] Attempting to connect to PHD2... [5/2/2015 10:59:40 PM] [DEBUG] [PHD2 Listener Thread] Failed to establish client connection to PHD2 using port 4400: No connection could be made because the target machine actively refused it 127.0.0.1:4400
but nothing in the phd2 log.
I’m not sure what would would cause this behavior, maybe Ken and Jared can take a look.
In my case its almost always the initial target for the night, after that, I can’t seem to remember any issues, everything works fine. And usually if I restart the computer after the issue, it will usually work. Never had this problem with the earlier versions SGP 2.3 series. Very puzzling!
Thanks for taking a look, hopefully tonight I’ll get another testing run, not that there is much I can image under a full moon
Last night I was attempting to string together several targets with just a few subs of each. Other than intermittent clouds, I also experienced a possible issue related to this thread (although this was between targets rather than at sequence start). In my case, SGP completed one target, slewed to new target, centered on new target, then waited for PHD to resume. SGP eventually timed out while waiting for PHD, but actually, PHD was happily guiding away.
The linked logs are rather long, but the event in question started around 10:23, with SGP appearing to give up around 10:28.
Version information: PHD is 2.5, SGP is 2.4.1.4.
Its certainly possible that I am doing something wrong, but I decided to share logs in case it is helpful.
For the life of me, I cannot reproduce any issue that resembles what is being presented here. That said, I cannot deny the number of folks responding to this thread. The only conclusion I can come to is that we are doing things (testing) differently somehow.
Anyhow, I have made some changes that I hope will stabilize the initial connection to PHD2 (and if not at least there is more logging now). Releasing 2.4.1.5 beta in a couple hours.
Tried version 2.4.15, first attempt still ended in a 3 minute hang followed by the msgbox asking if I want to start the guider and force a calibration. Chose no, and then everything worked. Both PHD2 and SGP windows display the not responding message. Phd connection takes place about 9:33:49.
My start up sequence involves starting SGP and acquiring the target, starting up PHD, start guiding, then start the SGP sequence. Not quite ready to start up everything automatically.
Yep, same as Lynn above. I thought the issue was a cable problem, but it isn’t. Win 7, SGP 2.4.1.5. Here are the logs.
Also noticed that once the sequence did start, PhD2 seemed to skip a frame about every 5 frames. I was watching the target, and there would occasionally be an interruption in the red x’s appearing, as if it had missed one frame.
Seems like it only hangs for me if PHD is currently guiding, if its stopped or looping, I just get the Do you want to start the guider/force calibration msgbox. But clouds have rolled it so only did some testing of it.
Well… .thanks for the feedback. I wish I had better news, but the new logging did not provide any new insight and I cannot reproduce the issue in any way so it makes a fix extremely difficult.
Please update if you come across any new patterns or clues.
I appreciate the attempt, Ken. It looks like it will be several nights here before the clouds lift, so I won’t be able to offer any feedback… but, I will continue to follow this thread and update when I am able to get back out.
If you remember, can you expand a bit on the life-cycle of the the PHD2 instance that was running. How long was it running? Had the server been used? Was it a brand new instance of PHD2? etc… any other details like that might prove to be helpful.
️ Just kidding of course. Have you tried 2.4.1.4? I know it’s a long shot but you never know.