Although this might seem simple at first, I don’t think it’s likely to be very useful and would probably cause more trouble than it’s worth. First, the PHD2 check-for-slew option is optional, placed there only because some ASCOM drivers do a poor job of managing state properties like slewing and IsPulseGuiding. Second, automation is more complicated than just having PHD2 try to deduce that guiding would “probably be a good idea now.” Small centering operations, for example, would often be reversed because PHD2 would simply guide the target back to its original location. Focusing operations when using an OAG can also confound guiding, so guiding should normally be paused at those times as well – and the list goes on. After a lot of work in this area, we now have integration packages available that allow use of PHD2 with a number of popular automation packages including MaximDL, CCDCommander, and CCDAutoPilot. And of course SGP and perhaps others already manage the PHD2 guiding operations directly. I think this is a better approach for us.
If you’re convinced you want to do this, you can implement it yourself outside of PHD2. You can write a script that monitors slewing, then start and stop PHD2 guiding as you see fit.
Bruce
--
You received this message because you are subscribed to the Google Groups
"Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-phd-guidi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
If you’re convinced you want to do this, you can implement it yourself outside of PHD2. You can write a script that monitors slewing, then start and stop PHD2 guiding as you see fit.