The 2+ hour session last night was designed to just capture two targets and solve/correct normally. The early part of the log shows other activities (PHD2 polar alignment check) so can be ignored. On the first target acquisition the plate solve apparently worked although I could not see the results at that time.
On the second target (NGC7331) it simply did not proceed during stage 2 but did not crash. I can’t interpret the log (attached). I waited for a few mins before pausing sequence.
I reverted to manual checks and pointed the scope myself via ‘solve’ etc.
I reset the schedule after unclicking target 1 (which was complete). I restarted (see log file). Again the plate solve 2 failed on stage 2 reporting ‘image preview opened’.
The other most surprising event was that I found the setting ‘flip guide calibrations’ and believed that that setting would take effect after any mount flipping. To my astonishment it took immediate effect and completely corrupted the guiding instantly. I was able to correct this effect by re-flipping the control. It is therefore not clear to me why the control works in only real-time because I might not have been there.
This is a bug fixed in the 2.5.2 beta. We will not be addressing it in 2.5.1 (really just due to time constraints and that 2.5.2 is very close to release).
I guess I’m not sure what this means. If you are referring to a the button labeled “Flip Calibration Data”, you should expect this to happen immediately because this is standard Windows UI behavior one assumes when dealing with buttons. For dealing with options, one would expect a checkbox toggle.
There seems to be some misunderstanding here. SGPro will take care of auto flipping your calibration data during a flip… you don’t need to do anything (or be present at all). This button really does not have much purpose any longer. If it helps at all, I have changed the title of the area housing these buttons to “Guider Actions”.
From the help docs:
Allows you to manually flip the calibration data of your auto guider
Ken - many thanks for your explanation of events.
1 - the bug. This was a basic operation so the good news is that failure wasn’t my fault. It would be useful for me to know what to do to avoid the circumstance (what-ever it was) re-happening…
2 - the guiding is down to me. I misunderstood something else here. I edited this para a few minutes later but should have deleted most of it. Some options are still not understood by me.
Generally I wish I could interpret the logs better! Still can’t see how far off the first ‘goto’ was, even though the plate solved.
I’m afraid upgrading to 2.5.2 is the only way to prevent it right now (the error is timing related so it can or cannot happen to anyone at any time).
Yes, this would be nice. Unfortunately sequencing with a multi-threaded application is mildly complex. Understanding of the logs by end users was never one of our goals (though some have taken to them like a fish in water). We did, however create user-facing logs via the notification system. This is a much more readable log (but of course, also lacks in its description of errors).
