When I am running a sequence and it changes targets, a window like this appears while the solving is done to verify the scope is on target. This is the last view of the window I get to see before the process succeeds and automatically dismisses the window. Is there a way to put a delay on this window so I can review the pixel error normally displayed at the bottom? If the setting exists, I can’t seem to find it.
There is not. You can find the information in the logs though… search for “Step 4”
That’d be a good enhancement. That would make it consistent with your other functions. Example, when autofocus runs you have a delay at the end of that process so you can rerun it. The way this works now there’s no opportunity for me to review the pixel error and click that “run again” button.
Not sure, but. wouldn’t it be a workaround to set the “Max Location Error” to “0”?
In that case the Plate Solve allways should “fail” and you can manually decide, if it is ok for you (press “Done”) or not (press “Run Again”).
Best regards
Reinhard
Yeah, I guess. But it also means the sequence will grind to a halt at every target change until I come along and fix it.
And it means I would have to manually reset the error value to something greater than zero in order to proceed.
Kind of a dirty hack but I guess it would work. I still say modifying the software to have consistent behavior across all functions is a better plan.
I agree having a delay before the Plate Solve window goes away would be a help and consistent with how the other windows work. What I find myself doing is after the plate solve is complete and SGPro is going about doing its thing, I search the log file for “Allowable Error” to see what my final error value was. Not a big issue but I just like knowing what the final error was for the plate solve and how close to ideal it was…
Regards,
Mark
This is not really a use case that we will ever design for… when the dialog closes you know that the tolerances you set have been met. How closely they have been met is not of any concern (because if it were, you would have tighter tolerances). In short, we do not really consider use cases that involve casual user observation of an automated process.
That said… a valid use case here (and it may not be that we implement it with a delay) is actually understanding, empirically, what values you can use for tolerances. Different combinations of gear will produce wildly varying tolerance values. I’m not sure a delay is the answer… maybe some easy way to access centering deltas over time so that you can come to understand what kind of accuracy you can expect from your current gear set.
Hey, its fine., I just thought it was a good idea.,
But hey… you got a timer on autofocus! Just sayin!
Either that, or you’ve got a “Run again” button that doesn’t need to be there. Maybe an apologetic message instead? LOL
Just kidding. Your product is good, and I’m gonna pay for it once my trial is up in 9 more days.
True. We added that in for development purposes and decided not to take it out for release, but you’re right… we should remove it to be consistent 
I would still like to consider a method that can help folks determine a better tolerance… have moved this to the feature requests category.
1 Like