The scope was at 0 degrees altitude, still trying to track. PHD2 was still active (with the sun up). I manually shut off the mount power, went to the observatory to see what happened. The dome was closing. I manually shut off remaining power, except for dome, just to stop any potential errant actions.
I had set the end time for the sequence to be altitude locked at ~30 degrees which SGP said was to happen at 2:42. At 2:37:04.752, the target is past the specified end time because the end time of the next frame and the specified end time are the same (5m exposures). So it goes to find the next event and re-evaluates the previous target which is not active, finds no valid targets and aborts. SGP goes into post-sequence but then it just keeps checking the dome position until 5:57 when it initates end of sequence actions and parks the telescope. That was about the time I got there and cut the power as related above. Why did it wait so long?
Fortunately, the scope hadn’t been driven into the deck.
This is a tough one to explain… mostly because SGPro only ever has part of the story. In my eyes, there are 2 issues here:
Issue 1: The reported issue, a long delay in end of sequence actions
Issue 2: The “emergency timeout notification” that should have fired at 3:07am did not do so
Issue 1
It seems like an attempt to talk to the camera at the end of the sequence hung. Specifically, SGPro asked if it had a cooler and if it was on, but seems to have hung there. This prevented subsequent actions from running. I don’t know why this happened or even if it could ever be created again, but there are 2 things of interest and I am sure that 0 of them are related:
The camera underwent an image abort from the guider-error restart feature. This was the last thing the camera did before end of sequence.
At 20:12, the focuser started reporting crazy (error) temperatures. Sometimes things like this can point to general errors with USB traffic.
In any case, I think the “fix” here is to isolate as many parts of the end of sequence actions from each other. Here, the queries to the camera can no longer prevent any downstream action on failure.
I do not know why the hang to the camera resolved itself at 5:57. That is bizarre to me and almost like something was asleep until you arrived.
Issue 2
A bug… emergency timeout notifications were broken in that the resultant notification from a timeout would only send the local notification and would not be sent to any configured external notifications, Email, GNS, etc). This is fixed.
These changes are being tested now and will be released shortly.
Thanks for the analysis, Ken. I have had issues with a powered USB control hub that, for some reason, loses power causing the camera hang. I’m thinking that probably happened. I need to fix that darned thing. It’s a connector issue, I think. The crazy temps get reported because I have a Robofocus and those are raw temps. I have not been able to get the temps to convert at all even though the Robofocus calibration works for their control program. SGP usually gives 0.0 (because of the crazy value, I presume). I’ve been using the RF server to get the temps but will go back to the basic driver unless I can get it working through to SGP.
I gave you a tough one, here. Sorry about that but thanks for coding around my problems.