XactMeasure versus GeoTol accuracy- comparative study of results

I would need you to send me a copy of the program (.prg & .cad files) to confirm but I do not expect there to be large discrepancies between 2018 & 2023.2 - providing everything has been programmed correctly.  By that I mean, THEO values matching the CAD nominals for all features, a fully constrained alignment BEFORE measuring anything that gets reported later and no partially constrained alignments mid-program (this breaks the alignment chain and can lead to strange behaviour), datums referenced at MMB/LMB must have been previously dimensioned - see "Determining the Size of the Material Boundary" on the following help page: How PC-DMIS Solves and Uses Datums

Speaking off the cuff:  XactMeasure was replaced for a reason. 

If your customer is going to hold "functionally obsolete" software methods over current released revisions of that same software, they better be able to affirm the suspect results are truly bad. 

As a metrologist for 24 years: when in doubt, hit the granite and affirm nonconformance via conventional or other measurement methods, before rejecting! You don't want to tarnish your personal integrity or reputation.

Also, if GD&T rev applicability is the subject of the nonconformance, you might want to escalate the disagreement up to your site's big wigs and explain you've got a contract dispute arising.

Good Morning Neil,

Neil Challinor said:

By that I mean, THEO values matching the CAD nominals for all features

The CAD is reference only so for every feature I have to run a location first and adjust nominals to print, then run the GeoTol.

Neil Challinor said:

a fully constrained alignment BEFORE measuring anything that gets reported late

I may get their Engineers to correct this at least but most features are ABC with A plane defined by flatness, B is position MMC from A-C MMB, and C has no geometric definition.  To follow print as it currently stands, I've already lost and would like to find out if XactMeasure can do this as GeoTol is not happy.  I don't get a Datum does not constrain error like some FCFs from another customer that doesn't understand common datums (A | B-C | B), but I know it is treating datums as 0.  Further D and E datums have no constraints other than linear dimensions.  Their Engineers don't understand the necessities of PCDmis but I would have figured their Quality Lab would have chimed in by now.

DR LokiZ said:

Their Engineers don't understand the necessities of PCDmis but I would have figured their Quality Lab would have chimed in by now.

It's not a requirement that's specific to PC-DMIS, it's how material boundaries on datums are supposed to be calculated according to the standards.  The following extract from the help file details where you can find the information in either ISO or ASME. 

Thank you.  That was the section I was looking for.  I need ASME Y14.5-2009 § 4.9 for them but the bridge was easily made.  I knew it was there in -1982 and -1994 (weakly) but the intent was there.

I would go a little further...

Both Xact and GeoTol have the same problem.  They create an internal alignment system that is only applicable to the reported dimension in order to show the features in the best possible light.  In the real world you can't do that because it doesn't work (looking at if from a mating part perspective).

I like some of the stuff they are trying to do but there are some problems they simply haven't addressed yet.  For example, you can't shift datum features one way to suite on specific set of features then do something completely different for something else.  These shifts only show up in the dimensions and not other things.  Their 'solution' of the simultaneous evaluation dimension addresses some of the issues but not all of them.  This crap didn't even work properly prior to GeoTol which shows how much interest they have in being correct.

If there is anyone out there relying on this stuff I think you are nuts.  This will surely cause problems....