2.4.0.2633 (downloaded tonight). 11"SCT, lost the guide star during a focus run. This is the first time I’ve used 2.4 during a focus run, and it looks like it auto-resized after the stars became donuts, and then things went way out of focus, and eventually went into recovery mode. The log is here:
This happened about 9:50pm. A couple things I noticed about recovery mode. First, since this happened during a focus run, all of the SGP controls became unavailable. So I think manual intervention to save the day becomes impossible - all you can do is close SGP and restart it? Second, after a minute or two, for some reason SGP decided to initiate a slew back to the target (M1),even though it was already imaging M1 at the time. The platesolve failed because the reference frame “does not exist,” which confuses me because it did exactly that platesolve to start the sequence. The platesolve dialog then disappeared. Third, the focus run appeared to continue, even while it was awaiting recovery. The focuser kept moving, the images kept being taken, etc.
For the rest of tonight’s run I’ve gone back to 2.3 to get around the SCT focuser issue, but I’ll look into this again next time out.
AF with that much FL (and a central obstruction) is dicey and is something that we would like to take a look at for 2.5. I’ll take a look at the logs, but I can almost guarantee AF came off the rails immediately. I don’t recall any recovery during AF… unless maybe you are using things like pause / settle guider during AF. Are you using those options?
Well, it’s not ideal, but you can abort the recovery. Then if the AF graph is still up, you can hit “cancel” on that and AF will return the focuser to the original position. When asked if you want to run end of sequence functions, uncheck the box and your sequence will be in a paused state.
This is expected and done to precisely recenter your target before continuing. Not sure why you had the failure. Will take a look at the logs for that. What I do know is that centering and AF cannot run at the same time so a failure here is imminent.
This is likely just a path to recovery that we had not considered. We can find out when it happens and shut AF down. Actions involving the camera are mutually exclusive.
Yes, I use the option to settle the guider between focus frames. In my situation - OAG on long focus SCT with mirror flop - AF runs are when I’m most likely to lose the guide star. I think that focus accuracy benefits from letting the guider settle between exposures, but on the next moony/hazy night I’ll try some comparisons to be sure of that. Thanks for the info about how to abort.
BTW, I’ve usually had good success with AF runs before now. You’re certainly right that it’s a challenge with an SCT, especially one with moving mirrors, and never a sure thing, but I’d guess I had 90% success. Given how few unattended AF runs occur during a night, that puts it fairly low on the long, long list of things that can tank my imaging run. The extended focus capability in 2.4 does change the odds, though.
I think I have this mostly repaired. It is a series of cascading errors that is very difficult to produce in a test environment. What happened here is that during AF, PHD2 sent a star lost message (using an OAG?) because the guide star was a now possibly in the shape of a donut. SGPro is programmed to try and recover from star lost so it did this… in parallel with AF (bad). AF continued to run… it does not care if recover is running.
Now, star lost messages are ignored during AF (to accommodate for star bloating and OAGs). If the star is truly lost, the sequence will recover after AF is done when the next light frame continues. I think this one fix will address everything you saw simply by virtue of never letting the first condition exist.