Possible bug on autofocus trigger settings

(Beta 13, PHD2 2.4.1.g) My sequence did not start up correctly and went into recovery mode - I shall dig out the log files to look into it. That may result in another post.

Anyway, I aborted the recovery mode (after some time) and got PHD to calibrate and ran autofocus with my Lum filter.
In my autofocus settings, I have AF enabled for before sequence start but not for resume. I hit Resume on the Sequencer window and it started to autofocus. That suggests that either, this is not a true resume (as the sequence never got off the ground) and the button is wrongly labelled, or the AF trigger is not reading the run sequence / resume sequence status correctly.
When I’m done for the night I will recovery the log files and post them if you need them.

Actually this might be expected behavior. Assuming that the sequence never officially started the first time, when you tried the second time it makes sense to me that the AF would run per your settings. What happened at the start of the first attempt? Why did it immediately go into recovery mode?

Joel, Looking through the logs, SGP lost contact with PHD2. The PHD2 debug log shows it was carrying on, regardless. This was a timed sequence for 18:30 -
PHD2_DebugLog_2015-02-18_171552.txt (1.2 MB)
sg_logfile_20150218171606.txt (473.7 KB)

Around 18:31, SGP could not get any response from PHD and kept trying. I was having cofffee and came back much later. PHD and SGP seemed to be confused, not clear where it stems from. It seemed to not sure if it was still trying to calibrate or guiding. Once I set it going, it has worked fine with the resumed sequence, dither etc.

buzz,

I took a look at the logs and first off, I don’t think there was any loss of communication between SGP and PHD2. Although there are lots of lines in the log saying
PHD2 Error - No messages received from PHD2 for 10 seconds...
I don’t think this really meant there was any loss of communication, and this is likely a red herring.

It looks like the actual cause of recovery mode was that SGP timed out waiting for PHD2 to start guiding. I’m not sure what timeout period SGP uses (I’m guessing it is 5 minutes based on the events in the SG log), but in your case PHD2 took longer than that to complete calibration so SGP timed-out and went into recovery.

[18/02/2015 18:31:55] [DEBUG] [Sequence Thread] PHD2: Attempting to start guiding, waiting for PHD2 settle done message.

[18/02/2015 18:36:55] [DEBUG] [Sequence Thread] PHD2 Failed to receive settle done message from PHD2 (timeout)

Shortly thereafter PHD2 calibration completes, guiding starts, and settling completes:

[18/02/2015 18:37:27] [DEBUG] [PHD2 Listener Thread] PHD2: Settle done received: 0

Then recovery kicks in

[18/02/2015 18:37:55] [DEBUG] [Recovery Sequence Thread] Something bad has happened... attempting to recover the sequence (attempt 1)...

Andy

Thanks for that Andy. I think I get another clear night on Saturday. I’ll monitor things more closely and see what is happening before trying to read too much into events.

I do think there is a possible SGP issue that Ken and Jared should look into (premature timeout) so I hope they see this thread.
Andy

Right now, if we don’t get a message from PHD for more than 10 seconds, we try to force it by sending a get status message. Is this bad?

I wouldn’t say that is bad. Perhaps not necessary, but not bad per se. For example if guiding is stopped, PHD2 will not be sending any GuideStep messages, and no matter how many times you ask it, it will always say “stopped”. When it starts again it will tell you (LoopingExposures, GuideStep, etc.) If you are unable to detect a dropped TCP connection to phd2 due to limitations of the socket API in .NET, then sending a status request as a “ping” is not a bad idea.

The part I was hoping you would look at is unrelated to that I think. Specifically, I was referring to how SGP sent method:guide at 18:31:55, and phd2 took more than 5 minutes to start guiding because calibration took a long time (and eventually succeeded after more than 5 minutes). The timeout values passed to method:guide refer to the settling time, but if calibration is needed the total time can be substantially longer as it was in this case. PHD2 will always send a SettleDone event some time after method:guide so I think you can rely on SettleDone to determine whether method:guide succeeded or failed. Having a 5 minute timeout value in SGP does not add anything IMO. If you wanted to have a safety net against a hypothetical PHD2 bug where phd2 failed to send SettleDone after method:guide, then you could implement a timeout, but I think it should be more conservative, like 15 minutes or more.

So to summarize: what I would do is:

  • use get_app_state as a “ping” to detect dropped phd2 connection (e.g. user closes phd2) assuming .NET cannot detect a closed TCP connection
  • rely on SettleDone for result of guide
  • implement a very long timeout like 15 minutes or more to protect against hypothetical phd2 bug where phd2 never sends SettleDone. But this may be overkill: the contract for guide is to always send SettleDone, it would be a major bug in PHD2 if it failed to do that.

Hope that helps,
Andy

Andy and Ken - thanks for the quick turnaround in Beta 14 (I never like using a version13! ).
To my original post on autofocus triggers- I think there is a quirk that has carried over to Beta 14

My sequence started up fine, connected to equipment, slewed, centered, calibrated PHD, settled Autofocused, settled and started the first 20 minute SII sub. About 10 minutes in, a cloud passed over and I hit Pause, Abort (without running end of sequence settings) and waited for the cloud to go over. I also stopped PHD2.

Once the cloud had passed, I started up PHD2 myself and resumed the sequence. SGP immediately started an autofocus routine, even though I did not have autofocus on resume enabled.

Is that supposed to happen? I aborted the autofocus routine and continued imaging. I have the logs if you need them:

@buzz

This has been corrected.

thanks for that Ken - the 5 minute-15 minute extension on PHD2 calibrating is useful too. I often use longer guider exposures (around 8 seconds) to reduce the effect of seeing on guiding a good mount with low PE. I think I will ask the PHD2 guys if it is possible to have two exposures - one for calibration and the other for guiding - after all Maxim, when it calibrates the guider, only looks at the endpoint position of a star after a multiple second guiding command.

@Ken I think Beta 15 went a step too far. I’m running a sequence over several nights and started it all up again tonight and carried on with the exposures. I have ‘autofocus on sequence start’ enabled but after connecting, slewing, centering, and guider settling it did the first exposure and did not run the autofocus first.(around 18:47)

The log file is here:

Do you need to check Auto Focus on Resume, as the sequence was originally started on a previous night?

Nigel

Nigel - it has not been necessary in the past versions. I have been building up exposures on one target since October, when I fire up the PC and run SGP and hit run sequence, it has worked flawlessly in this regard and autofocused before carrying on with next exposure (the button on the sequencer after all says ‘run sequence’ not ‘resume’)
The behavior seems to have changed between beta 14 and 15 - I had an issue in beta 14 that the AF was firing up after an abort/resume when ‘AF on resume’ was disabled -it may be that in fixing this, it is accidentally preventing AF triggering for a ‘run’ sequence. (AF is triggering correctly for temperature changes though in beta 15).
I think this will be easy to verify / fix in due course. I suspect Ken and Jared are rather busy at the moment.

@buzz, When you say that you started it all up again, I assume this means that you started SGPro and re-opened the sequence (meaning you did not leave the sequence open from the night before). Is this correct? The logs seem to indicate this is true, but I am just making sure.

@Ken, yes absolutely. I shut down my PC after each session (and store my sequence at the SGP prompt) and when I power it up for the next session and open SGP, I load the sequence and hit ‘run sequence’ in the sequencer