OK - I was finally able to test Jared's new code - and logs are attached.
In short - first I confirmed the slew/synch centering process was stuck in the same location at around 100 pixels with the normal 25.1.14 code.
Then I tried Jared's modification to the code - and unfortunately it did not help anything. It appeared to behave slightly differently but got stuck at about the same location. Log is attached, ending with 1936.
Then I manually did the routine myself - by using the "Slew to target" in sgp, combined with a right-click plate solve on images that I took manually with the frame and focus tool. In that case it worked perfectly and I was quickly within about 2 arc-seconds of the target. And that is based on an actual plate solve - so it really did work as intended. That log is 2346.
One difference here is that I am using a new camera, a qhyiii174 for the test - and I did see some trailing in the images that were plate solved while centering. This implies it needed to wait a bit after the slew before taking the plate solve image. But even then it should have compensated for some of that motion.
So - was the routine implemented properly in the test code? Is there some other form of offset involved?
In my manual test - in log 2346 - I was aiming for RA 11:00:00 Dec -60:00 and on the first try I landed at 10:59:50, -59:59:19
So in the next slew I aimed for 11:00:10, 60:00:41
and I landed at 10:59:59, -60:00:02
That was an immediate improvement in one move and I was almost exactly on the target.
I then slewed to 11:00:11, -60:00:39
and it landed at 11:00:00, -60:00:01
which is great.
So the concept should definitely work and it avoids syncs - but I'm not sure why the test code didn't work.
Frank
sg_logfile_20160625181936.txt (614.7 KB)
sg_logfile_20160625182346.txt (989.1 KB)