True Posistion Calculations in error?

[Chugger]

I have been noticing that there may be an issue with TP calculations when using Datums.

I have a callout on the print that is |TP dia .006 mmc |A|F mmc |

The hole that this called out in my inspection code is CIR_42. It has a nominal dia of .502 + .002.

If I ask for a standard location in X & Y, I get:

DIM LOC_CIR_42= LOCATION OF CIRCLE CIR_42  UNITS=IN
AX   NOMINAL     +TOL       -TOL       MEAS        MAX        MIN        DEV      OUTTOL   
X      11.232      0.005      0.005     11.228     11.479     10.977     -0.004      0.000 #--
Y       6.485      0.005      0.005      6.485      6.736      6.234      0.000      0.000 -#- 

No problem, so far. If I ask for a simple Posiitional callout I get:

DIM LOC_TP_CIR_42= TRUE POSITION OF CIRCLE CIR_42  UNITS=IN
AX   NOMINAL     MEAS       +TOL       -TOL       BONUS       DEV      DEVANG     OUTTOL   
X      11.232     11.228                                      -0.004                      
Y       6.485      6.485                                       0.000                      
DF      0.502      0.502      0.002      0.002      0.002      0.000                 0.000 -#-
TP        MMC                 0.006                 0.002      0.008   -179.706      0.000 --# 

Again, if I look at the measured values for X & Y and the deviations, they match. Now if I add my Primary hole (Cir_76) as Datum feature to the call out, I get:

DIM LOC_42= TRUE POSITION OF CIRCLE CIR_42  UNITS=IN
AX   NOMINAL     MEAS       +TOL       -TOL       BONUS        DEV       DEVANG     OUTTOL   
X      11.232     11.230                                        -0.003                      
Y       6.485      6.485                                         0.000                      
DF      0.502      0.502      0.002      0.002      0.002        0.000                 0.000 -#-
D1      0.502      0.503      0.002      0.002      0.003 CIRCLE CIR_76 AT MMC           
TP        MMC                 0.006                 0.002        0.006   -180.000      0.000 --# 

Why is the measured X location different and why is the TP calculation in error ?

[craiger_ny]

Version?

I am guessing it is simulating a hard gage. We'd need to know what version you are using to answer that though.

[Chugger]

Sorry about that. 3.7 MR3

[Wes Cisco]

The answer is in my attached document and the MMC condition on the datum. If the doc doesn't answer your questions post again and we will try to help.

[Chugger]

Thanks so much. Our main concern was that we have been shipping product that was potentially in error.

If I understand the document, if the hole was out of position, we would still get an out of tolerance indication.

[Wes Cisco]

Yes. Many people, myself included do not like to use MMC on a datum in pc-dmis because it acts as a go/nogo gage as explained in the document. However there are some guru's whose opinion I and many others hold in high esteem who swear the MMC on a datum in 3.7 and above works as described in the document. The math to figure this stuff out is very complex and in most cases it is easier to build a functional gage and then be assured you have functional parts. Fortunately I rarely have MMC on a datum and in 99% of the cases where I do we hold the parts close enough that I can treat the datum as RFS and still have the part check in tolerance for trueposition. HTH

[Peter Warcholyk]

Wes,

Unfortunately, I have many parts that have MMC modifiers on datums.
I don't believe that it calculates out correctly either.

I am running ver3.7mr3, and only have the MMC on the feature itself (when asked for), but tend to ignore it as it pertains to the datums.
Whenever I have tried to select "tp" for a feature, that has a modifier on one or more of the datums, I get ridiculous results.

Best Regards,
ZydecoPete

[Matthew D. Hoedeman]

Or, as in my case, the datum holes are on a taper pin or a straight pin in the fixture and can not be measured in any case, so all you can really do is TP the hole to it's own MMC.

[Jan d.]

I have many TP's with virtual conditions on datums. And I am convinced that they work just fine.

There is a small bug in the software when you have datums with dual virtual conditions. This will be properly handled in the upcoming version of V4.2.

I have nothing to add to what has been said. I also generally report to RFS on my datums. When I am out-of-tolerance, I will re-analyze using the VC on the datums. Sometimes that analysis makes seemingly huge errors evaporate (depending on the datuming scheme). This can be a surprise, when you see that the first time. It seems as if you are accepting a "bad" part. But all you are doing is using the VC as allowed by the print. It ain't your problem, it is probably the engineer that had no idea what he was really putting on the print.

I suggest though that you think real hard about upgrading to V4.1. TP reports in those versions add a lot of cool process information (like clear datum shift info) that can be used to feed your machining process and make better parts!


Jan.