I had four hours of imaging with 2.5.1.10 and early this morning I had what appears to be an altercation between PHD socket and SGP. The log file ends at this point and the machine locked up and would not respond to remote desktop. There was not sequence terminate etc.
I’ll also dig out other logs too. At this point I am not entirely sure of the problem. I have not had a crash of this nature since leaving Maxim
Any ideas. The NUC still responded to a press off the power button, which executes a shutdown.
I don’t really see anything telling in the logs. The PHD2 socket did fail… not indication of why. SGPro was unable to reconnect with it so it shut the guiding sub-system down… After this, the timed error message was issued because the camera did not respond with the image in a timely manner. Not a lot to go on…
I agree - there is nothing in the other logs too. All the logs generated by ASCOM traffic from SGP stopped at the same point but some other logs continued. It may have been a PC issue. I’ll connect a monitor directly to the NUC next time and see what it is doing - as the remote desktop would not connect I had no visual clues before shutting down with the power button.
The PHD2 log you attached does not appear to cover the period we need to see… specifically May 5th. The PHD2 log you attached is from May 3rd.
On the 5th, we need to see PHD2 coverage over this period:
[05/05/2016 02:20:14] [DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Post-Wait: Guiding
[05/05/2016 02:20:24] [DEBUG] [PHD2 Listener Thread] Attempting to connect to PHD2…
[05/05/2016 02:20:25] [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
[05/05/2016 02:20:29] [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
[05/05/2016 02:20:32] [DEBUG] [PHD2 Listener Thread] Could not etablish a connection to PHD2! Aborting…
Nothing much to see, the log simple ends just before at 2:18
I did a 6-hour run last night with no crashes though I saw some anomalies with PHD2 (is this as intended?):
I was having issues with passing clouds and finding a star after the meridian flip and so I aborted SGP and manually intervened with PHD2 and picked a better guidestar. I resumed the sequence. SGP strangely instructed PHD2 to disconnect the camera etc and then reported it was trying to restart the guider. After a little while I aborted the SGP sequence and resumed and this time, it instructed PHD2 to connect (which it did) I think the timing was around 00:13. The rest of the night went without a hitch. It almost seems the connection to PHD2 is working like a toggle.
@buzz I reviewed the logic here and determined it was very strongly oriented toward starting a sequence and not so much for resuming a sequence. I reworked the guider startup logic to be a bit friendlier in 2.5.1.13.
