The recent changes you have made seem to be working: targets load from C2a text schedules, default equipment settings and switches work, etc. Thanks for that!
I had a problem last night where the scope failed to capture the last target after waiting for several hours. I found that the mount had crashed the pier. I had the box in the auto guider settings checked to stop when waiting for next target. Besides stopping PHD2 does SGP stop the mount from tracking? I thought it did but can’t find any indication of that in the log. Perhaps you can give me your take on it, log at:
23:50 - Start 29P-Schwassmann-Wach (wait until 02:50)
29P-Schwassmann-Wach possibly transits and mount continues to track and stops against pier??
02:50 - 29P-Schwassmann-Wach starts and the centering routine, while ASTAP claims to have succeeded in the initial solve is a full 2 hours away from where the mount thinks it is. SGPro notes this and fails the centering routine (and, importantly does NOT sync the mount). This, of course, rules out subsequent recovery attempts from succeeding (they will fail for the same reason)
The only thing I can think to do here (quickly) is to provide an option to ignore this solve coordinates disparity, sync the mount and attempt centering anyhow. This would be at your own risk tho… In your case, I believe it would have worked.
A longer term solution is to allow the mount to stop tracking mid sequence (whilst awaiting next target), then on target start, essentially perform a full restart with blind solve. This is more complex and requires use of a blind solver, etc
That longer term solution sounds like the way to go. Why would you need a blind solve, though? Couldn’t SGP just start tracking then do a slew and center using the target coordinates as already set up?
Plate solvers need semi-accurate hints to function properly and as soon as you stop the mount the driver may or may not continue to calculate the change in RA (in your case RA was off by a full 2 hrs, but I don’t know if that was due to the driver tracking and the mount not actually moving or just not providing positional data when tracking in disabled). I suspect it would be simple enough for SGPro to do it though… Blind solver would then just be a backup if the hint-based solve fails.
I haven’t really fully thought through it though. All this is just off the top of my head.
My mount driver (AP V2) does continue to calculate. So I think it would work just fine on my system. Shouldn’t need the blind solver, except, as you say, a backup. What you suggest doing sounds good to me.
This is a longstanding “gap” in SGPro that I have wanted to cover for quite some time now so I’ll look at adding it early in 4.6. I have essentially locked 4.5 features down now and will only release changes if they address defects. This means that 4.5 is close to release, but it takes a while to document all the new 4.5 features and changhes (which is what I am spending time doing now)