I need to measure a dimension to the centerline of a radius, but the radius is 2" and only covers an arc of about 25 degrees. Measured on the optical comparator, the radius is nearly nominal, but on the CMM it measures 2.117". This throws my centerline over .100" out of position. How can I create a centerline from points on the radius using the nominal radius? Can I force PC-DMIS to best fit a 2" radius to points on the surface?
steps I use for location and diameter of small arc/radius
At a recent users group meeting this topic was discussed and the following steps were given to achieve both the location and diameter of a small arc/radius
To measure a partial arc/radius:
1. create a "measured" circle
2. edit (F9) the circle and add additional hits and edit the "best fit math type" to "FIXED Radius", edit the NOMINAL DIAMETER, check box to "regenerate hits", when prompted "equal spacing" answer YES
3. ctrl E the feature to execute it and re-capture the measured hit points
4. dimension the "location only" of the fixed radius circle/arc
5. edit dimension tol's to print
6. create an alignment and set origin on fixed radius circle
7. (if using CAD skip this step) F10/Parameters>Probing> enable polar compensation for the active workplane
8. with joystick measure more individual/separate points on arc radius (if using CAD use "vector point" skipping step #7)
9. dimension individual points using the "PR" polar radius function
10. F10/Parameters>Probing> turn
off or disable polar compensation
I have used this method in my travels and it works pretty well, however, I'm not sure that I can say I have ever seen a difference in doing this and scanning the area. I sometimes scan these areas then generate the scan to points and get the polar radius of the points that way.
It seems to correlate rather well with the measured feature option, but, seems to be a little faster IMO.
I work 95% off-line. So using the jog box and taking extra hits is somewhat out of the questions unless I use auto vector points. ctrl+e and recapture all seem to be on-line programming. Is there another procedure for off-line programming.
I tried using an auto circle with 30 hits on 2 small radius, then I also did a scan with 30 hits that were then created into vector points. I created a circle out of them. These were two different radius, one on top, one on bottom. Both types came out extremely lousy.
Reporting out individual points still doesn't give a true position reporting. Is what you are saying is that it is very unlikely that I will ever be able to create a circle out of these hits and get accurate true position results.
I work 95% off-line. So using the jog box and taking extra hits is somewhat out of the questions unless I use auto vector points. ctrl+e and recapture all seem to be on-line programming. Is there another procedure for off-line programming. I tried using an auto circle with 30 hits on 2 small radius, then I also did a scan with 30 hits that were then created into vector points. I created a circle out of them. These were two different radius, one on top, one on bottom. Both types came out extremely lousy. Reporting out individual points still doesn't give a true position reporting. Is what you are saying is that it is very unlikely that I will ever be able to create a circle out of these hits and get accurate true position results.
No, that not what I said at all
these steps were given to me from a B&S AE and work fine ONLINE
you could try to modify them for use offline and test it online
The true pos could be obtained in the step #4
diameter in step #9
Are you saying that the dimension is coming out lousy while offline? If so I am not sure how that is happening, but if you are able to repeat your radius (size) by using one of the methods you described, as well as your X and Y then that should be a pretty accurate indicator.
When I want to verify something of this nature, I usually create a generic circle at the specified print coordinates and set my x, y origin to it. I then get the x and y location of the measured feature from the new origin as well as the graphical comparison. It is a good idea to check your individual points to this known feature using polar radius, because what I have noticed in the past especially depending on the size of the feature is that no matter how many vector points you have, if you construct a circle on them it will still use the average rather than all of your point data and if you start out with the radius (size) in an untrue state the locations will be erroneous every time.
In fact I just had to do this same excercise this morning as I had to prove that a feature was 1mm out of position.
BTW, who in the world would put a true position on a radius? Wouldn't a profile be more suitable? As Jim Jewell said, and many of the apps engineers at Brown and Sharpe will tell you that this is a math problem.
IT IS PERFECT OFF-LINE, ITS WHEN I CHECK IT ON-LINE THAT IT TURNS OUT LOUSY. NEITHER THE TOP TWO COMPARED TO EACH OTHER NORE THE BOTTOM TWO COMPARED TO EACH OTHER ARE CLOSE TO EACH OTHER. THE RADIUS FOR TOP 95 MAY CHECK 127 AND BE OFF LOCATION 32MM ( WHICH IS EXACTLY WHAT THE RADIUS SIZE IS OFF ) BUT THE TOP SCAN RADIUS MAY ONLY BE OF 1mm. SAME RESULTS FOR THE BOTTOM BUT MAY BE OPPISITE AND THE SCAN WILL BE OFF 25mm.
THE POLAR RADIUS IS STUMPING ME. I THINK WHAT IS BEING TOLD FOR ME TO DO IS TO TAKE A VECTOR POINT WITH CAD AND THEN COMPARE THAT VECTOR POINT NOMINAL TO THE ACTUAL POINT? POLAR RADIUS? IS THAT "Prad"?
WHEN I COMPARE ANY OF THE "Prad" OFF-LINE VECTOR POINTS TO ANY OF THE SCANNED HITS I GET A VARIETY OF READINGS. I GUESS TO ME THE "Prad" IS THE ANGLE AT WHICH THE PROBES IJK IS ACTUALLY HITTING THE PART.
FREAK IS SUGGESTING USING THE X-Y OF MY CAD POINTS TO THE X-Y OF MY ACTUALS - THAT SOUNDS OK, BUT IT STILL DOESN'T SOLVE MY TRUE POSITION CALL OUT. IT SOUNDS LIKE I SHOULD TALK TO OUR ENGINEER AND HAVE IT CHANGED TO A PROFILE?
AS YOU CAN TELL, I AM VERY CONFUSED WITH THIS ONE, YOU WOULD THINK IT WAS EARLY MONDAY MORNING FOR ME.
That has complicated written all over it. It does help in comprehending the reasoning behind the exponential error encountered. I take with a grain of salt the Walter M. Stites' contribution. I have no doubt the man very experienced and knowledgeable. However, as a former customer, I became tasked with refuting his programming results (we all make errors at some time or another) on more than one occasion.
