How could least square be larger than minimum circumscribed

There is no "maximum circumscribed fit" - it's either minimum circumscribed (smallest diameter sphere that would envelope all of the points) or maximum inscribed (maximum diameter sphere that would fit inside all of the points).

Check that you have selected the correct fit type for the type of sphere you are measuring. If it's an external sphere (ball), you should be using minimum circumscribed, if it's internal (socket) you should be using maximum inscribed. Also, the maximum inscribed / minimum circumscribed are not as mathematically stable or robust as least squares, especially if you have less than a full 360° of arc. For this reason, minimum circumscribed should not be used for any less than 180° or arc and maximum inscribed should not be used for any less than 90° of arc: https://docs.hexagonmi.com/pcdmis/2020.2/en/helpcenter/index.htm?rhcsh=1&rhnewwnd=0#t=mergedProjects%2Fcore%2F16_const_topics%2FBest_Fit_Type_for_Circle.htm

Neil,

I fixed all those grammer errors...im aware of what all the fits are...ran 5 separate runs both with lst sq and min circ, all slightly twisting the part 1 deg for variance. i know they arent stable but its hard to believe the results were all near identical and there are plenty of pts to use...and its a full 180 deg...at the boarderline of too little but i figured enough.

OK, just checking. A few more questions...

Were you using BF or BFRE to construct the various fits?
Did you include any outlier filtering?
How much of the sphere were you measuring - how many degrees of arc?
What was the total form error?
Do you still have the data and if so, can you share it?

I'll get that data next weekend, appreciate the interest....i ran both BF and recomp, but only ran recomp once as I didn't want the brain damage of re_reading some of my old questions on that...even though I just did, lol. I'll run both next time, the programmer uses BF and I feel we should be defaulting to recomp, he's very good, but I doubt he understands both without learning about them. also, he will often local align to a feature before really taking hit points therefore making bfrecomp less helpful imho. How do you check for form error on a sphere? When I see form I think GDT straightness, flatness, cylindricity, circularity.

If you select circularity for the sphere, it should give you the form error (sphericity), or you can choose profile of a surface but be aware that profile will include size as well as form deviations - unless you are using the geometric tolerance command and select the dynamic profile modifier.

Whenever you construct a new feature from previously measured hits, you should use BFRE. BF should only really be used when constructing new features from existing features that don't have surface data - like constructing a PCD through the centroids of a number of previously measured circles. The reason you should always use BFRE when the inputs are hits is that it will re-compensate based on the geometry being constructed rather than taking the original, pre-compensated hits. By re-compensating, you can effectively cancel out any cosine error the original hits may contain - for example if they were probed slightly off location.

neil.challinor thanks...ill get back to you on this on the weekend.

neil.challinor The shortcomings you describe in post Forum regarding incomplete circles (arcs) when it comes to calculation, that applies to any software - not just PC-DMIS?

Correct. It's an inherent problem with those types of algorithms.