In my occurrence, Cone Nebula had a finish time of around 03:03, which SGPro correctly stopped the last frame before then, my next target was not until 03:28 but PHD continued to guide resulting in a lost guide star (Because a house got in the way) and then aborted the rest of the sequence.
Surely the correct behaviour would be to pause guiding until the next target starts?
Link to Logs
Useful Info
OS: Microsoft Windows 10 Pro
Ver: 3.1.0.425
.NET: 4.8
What you suggest makes some sense. I would go further; I would stop tracking and guiding until the next target is due, otherwise one (could) hit end stops/meridian etc and end up in no-man’s land? In my case, I would park my mount - but not all mounts can do this.
I also think it would be a good idea for SGP to have PHD2 “Stop Capture” and disable telescope tracking while waiting for the next target. When the next target starts, its just like starting a new sequence, anyway.
Charlie
In 3.1.0.429 SGPro will attempt to pause the guider if it detects a wait state. If it is not successful for some reason, SGPro will also ignore guide star lost messages during wait states. We will pay more attention here when we start to focus on the notion of “continuous imaging” modes. For 3.1, this should suffice.
I’m not entirely sure that this will work on IOptron mounts, as they always (CEM60, CEM40 & CEM25P) come up with a message stating that the mount is parked or not tracking and if one wants to activate it. In addition, when the mounts are parked, they need to be unparked before they can slew again. Having such a message pop up in the middle of the night, would make things difficult 
Just my 5 Cents
Just a minor note – you may be using “Pause Guiding” in a generic sense but there is a behavior difference in PHD2 between “Pause Guiding” and “Stop Capture.” Since SGP is waiting for a new target, I believe using “Stop Capture” is a better fit to the circumstance.
Charlie
I’m not sure how this relates here. SGPro does not park (or otherwise modify) the mount’s state between targets.
Yes, this is what I meant by “suffice for now”. In the very near future, I will implement a proper stop, but due to how certain parts of code are shared here a stop would badly break the first target in a sequence. I need to “unshare” that code and test… was just providing something useful in the meantime that didn’t break everything.
I took some time today to properly separate some shared code and the auto guider is now properly stopped (as opposed to pausing) when waiting for target start time. This will be in 3.1.0.430.
Happy New Year @Ken
Important FYI related to this topic. Version 431 still has this functionality, but it is OFF by default. You can enable it in the auto guider tab in the control panel.