Hi Jared and Ken,
I was imaging tonight and some clouds come through briefly and recovery mode started at 2:20:27 am. I’m not sure why but recovery mode aborted at 2:24:19. I have it set to keep trying every 10 minutes for 90 minutes, so I’m wondering why it aborted right away. Here’s the log:
http://adgsoftware.com/ap/misc/sg_logfile_20151015183641.zip
and here is the PHD2 debug log in case you want it:
http://adgsoftware.com/ap/misc/PHD2_DebugLog_2015-10-15_183614.txt
Thanks,
Andy
Hi Ken and Jared,
I imaged again last night and clouds forced recovery mode a couple times and SGP 2.4.3.8 was able to recover each time. I would still like to understand why recovery mode aborted 2 nights ago though. Do you see anything in the 2015-10-15 logs from my OP?
Andy
Andy,
Looks like PHD2 wasn’t able to communicate with SGP at the end of your log. Something happened and SGP received:
[10/16/2015 2:24:14 AM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Post-Wait: LostLock
[10/16/2015 2:24:14 AM] [DEBUG] [Sequence Thread] PHD2: Requested unpause, but PHD2 reports it is not in a paused state
[10/16/2015 2:24:14 AM] [DEBUG] [Sequence Thread] Checking PHD2 state…
[10/16/2015 2:24:14 AM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Pre-Wait : LostLock
[10/16/2015 2:24:14 AM] [DEBUG] [Sequence Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}
I don’t know what that means, but it decided since PHD2 didn’t work it would park the mount.
Chris
Chris,
Thanks for looking at it. I’m not seeing the loss of communication you are referring to. Maybe Jared or Ken could comment?
Andy
Andy,
Maybe we are talking about different things… if so please clarify. The logs you posted show recovery mode ending due to success, and then show the sequence continuing.
[10/16/2015 2:24:14 AM] [DEBUG] [Recovery Sequence Thread] Recovery: Settling is successful…
[10/16/2015 2:24:14 AM] [DEBUG] [Recovery Sequence Thread] Sequence recovery was successful!
[10/16/2015 2:24:14 AM] [DEBUG] [Sequence Thread] Sequence recovery was successful (CenteringAndGuiding)!
[10/16/2015 2:24:14 AM] [DEBUG] [Sequence Thread] ------------- Starting capture frame for event[0] -------------
Ken, that’s right, it says it succeeded but if you look a little further down to [10/16/2015 2:24:19 AM] you’ll see it aborting and running the end of sequence options (camera warm-up, park scope, stop phd2, etc.)
Andy
Ah yes… that is the current logic
Sequence fails, recover
Recovery is good, resend capture event
Sequence failed again
SGPro determines something is more wrong than it can fix because it just
recovered fine minutes ago
Terminates sequence
Thanks Ken.
Sorry, I am having some trouble parsing what you said there. What was it that failed and prevented recovery from running for the 90 minutes? Are you saying it was because there were two failures within five minutes? Does that mean recovery can only work if the clouds clear in less than 5 minutes? How does this relate to the settings I had of “try every 10 minutes for 90 minutes”?
Recovery mode has generally been working great for me, allowing me to image unattended even when a temporary cloud interrupts the sequence. I am hoping to understand what went wrong here to see if it can be improved or if there is anything I can change on my end (or in PHD2) to avoid this situation next time, or perhaps this is an issue with the beta?
Andy
No, recovery has always worked this way.
It doesn’t. This has nothing to do with the situation.
Basically, before attempting to take a single exposure, your sequence failed, recovered successfully, reattempted the frame and failed again. The logic here is that SGPro just recovered successfully and the sequence failed again immediately afterward so it is likely not a recoverable scenario (this sounds like it’s not true for your case, but that is our current thought process). Seems like you just barely recovered and then had bad timing with more clouds and junk. Imaging though sucker holes is not super fun.