"Default" Math Vs "Legacy"?

Or HI-JACKED!

I want 12,000,000 bitcoin & 2 Oz Mid-Self Sativa
Or this thread gets it!

If the Customer gives you Datum bonus, and your Datum bonus is enough to allow your Datum to shift enough to give you a zero deviation on your feature, then that's what you get. If you or your customer doesn't like it, then remove the Datum bonus.
Judging by this post, I'm fairly positive your customer doesn't trust you, not your software

SingularitY is correct. The whole point of adding material modifiers to datums is to allow datum shift and, if there is enough datum shift available, then the position will fully optimize to achieve a zero result.​

I think more correctly, the topic I'm trying to bring to discussion is:

"New Math" performs a best fit calculation, if you are giving direction to a set-up machinist, I would consider using "legacy".

What are your feelings?

To​ Cumofogabriel 's point, yes, absolutely. If you are looking to provide information for process adjustment then using legacy in the way you have done will negate any datum shift and let the machinist know what corrections may be required in order to improve results. But, as I said, it is not verifying the callout in accordance with ASME Y14.5 as the designer intended.
​
The reason for my taking offence at your initial post was that you didn't explain this might be what you were attempting to do, you just launched straight in with what I perceived to be an attack on the geometric tolerance command. Since I've personally invested the last four years helping to develop, test release and support the "new math", I tend to take those kind of comments a little personally.

I tend to use legacy as much as possible as machinists want to know where a feature is without using best fit or MMC or LMC. The need pure XYZ coordinates to make the part. Final inspection programs are a different animal and I will use whatever the software has available, I do not use XactMeasure unless it absolutely necessary as it has burnt me more than once.

The way PC-DMIS expresses datum shifts by reducing measured values is stupid, IMO. Would have been much better to add to the tolerance, rather than subtracting from the measured values.

In those rare occasions, where PC-DMIS can calculate in tolerance vs out of tolerance conditions correctly for characteristics with datum modifiers (no software can out of the box), one can report twice, one with datum shifts active (to determine red vs green), and once with datum modifiers inactive to provide real data.

I don't think I would fault PC-DMIS in this instance (unless they erred-which I have not seen any evidence) as the "Datum shift" is the ASME standard. It's not Hexagon's fault that the standard requires "interesting" things like datum shift rather than merely adding bonus tolerance.

I really struggle to see why people have issue with Datums shifting and changing the measured values. This is the intent of the callout. It's mimicking the function of the mating parts. If you have 2 concentric bores that are .500in long and 8in apart, I doubt you would want the true position of one bore to the other without Datum bonus unless the tolerance is much larger otherwise. This screams functional gage and PC DMIS, along with other softwares, are attempting to mimic that. If I use Datum shift, I report both scenarios. Datum shift for part acceptance, no Datum shift for the machinist to know how to make moves in the machine. If a customer came to me and asked why I reported a zero deviation on a report, I would kindly reference the ASME standard section and call it a day. The report would show them how much the Datum shifted to get said value.

Zeiss painted themselves into this corner a long time ago. Intending to make CMM programming accessible to a broader group of human types, they built rigid inflexibility into their software at a very rudimentary level. A strong point of Pc-Dmis is user control of probing and mathematical evaluations of that data in a very good spectrum of manufacturing. Perhaps a radio button enabling the use of Datum shift or added bonus after the evaluation?

What do I do with my pitchfork and torch now?

Niel:
You can't be the "Product Owner".
NOBODY can own the Demon!
Can't you see my dear friend,
The Demon owns YOU!
Look at all of us who have served the Demon,
Our life has been poured out!
And for what? So we may eat?
I'd feel better about myself at night if I sold hotdogs!
I know your sacrifice, we've all bled till our minds and our hearts were at the end,
And you, exhausting yourself for 4 years in a world that is defined in an imperfect definition, because least squares regression can only be a compromise at best.

Just because you can do this, does it mean you were meant to do this?

Look at us, servants of the Demon
We do this because we can, and nobody else wants to,
It's too late for me.. But YOU! Star-Wars-Quotes-Return-of-the-Jedi-5.webp

If the Customer gives you Datum bonus, and your Datum bonus is enough to allow your Datum to shift enough to give you a zero deviation on your feature, then that's what you get. If you or your customer doesn't like it, then remove the Datum bonus.
Judging by this post, I'm fairly positive your customer doesn't trust you, not your software

I'm trying to follow this conversation to the best of my ability. Personally I tend to use legacy. Part of that reason is because of past issues with Xact measure, part of it is the varying opinions on its accuracy, and part of it is not having the depth of knowledge necessary to understand what it's doing exactly, excuse the pun. It can make a complicated alignment structure easy, and save time, so I do use it on occasion, but it's extremely rare. I'll usually provide both methods, and label one as a reference (usually Xact measure), only so operators don't get confused as to which one to base their moves from. One key issue I don't like in the new version is that you cannot correct nominals in it, and often times, due to rounding errors on the model, the nominals vary slightly from print. Only by microns, but it gives me anxiety if it's not identical to print. Yes, I know you can enter nominal in the feature itself, but for me, it's so much easier to just enter it when I'm dimensioning items and then allow pcdmis to update the feature automatically. I'm not sure why they took away the ability to correct those.

The very first boss I ever had in QA, 20 years ago told me to never, ever, ever enter zero on a customer report, even if you can prove through manual methods the result is correct, because it immediately raises a red flag. Policy there was that if pcdmis reported something as zero, you had to enter something that was in tolerance, but on the low end. Another option is to just increase the place of the result. 0.000 will usually show "something" if you go out to four or five places, six if necessary. Of course if you're in metric and reporting 0.000003, you'd likely raise the same red flag. Using metric I will use something like 0.003, give or take, using standard it would be 0.0003, give or take. The number I use in either case is related to how much tolerance I get. The important part is insuring the feature is in tolerance, and that you're not getting zero due to some error in your code.

To be honest, datum shift and how Xact measure is compiling its final result seems like a magic that I don't understand, so in turn, I cannot explain to an engineer, or operator what may be causing their issue, specifically, only because it's pulling from so many different things to arrive at its final calculation. I feel legacy is more reliable, and in some ways forces you to make a better part because you're not relying on things such as datum shift to bring a part into tolerance. I could be dead wrong on that. It's just an opinion, and I think whether one does, or does not use Xact measure is a matter of preference. At the end of the day, either method can produce a good part. Again, it just seems like Xact measure is using Mulligans by drawing on various factors to get there. I've also had many occasions where I construct the alignment in Xact measure, per the customer print, and get an error telling me I can't do it that way. Is that an Xact measure issue, or a drawing issue? I don't know. In those cases the print seems correct, but Xact doesn't like it for some reason.

I've seen many opinions on this topic stating that Xact measure does not work like it's supposed to, on this forum and elsewhere. I personally don't know. Like me, it could be lack of knowledge in how to use it rather than the function itself. A major factor to consider is that not all shops use pcdmis, and many of those shops being the customer, will verify your part on their cmm. If they get different results, it's a long arduous journey to convince them that Xact measure is superior to their software, and that they're getting it wrong, IF you happen to have enough knowledge about Xact measure to unpack it for them in a way they can understand. I'll end this now by just stating these are only my opinions. I'm sure others will disagree, but if there was only one way to do any of this, there would only be one piece of software and every shop would have it.

Of course, the REMOVAL of the reporting of the DATUM SHIFT was a huge mistake as showing a hole at perfect ZERO, when it CAN NOT BE (nothing is perfect!), and NOT explaining why, or showing how, it is a perfect zero, is a bonehead play.

As for anyone questioning the 'new math', let's face it, Pcdmis has a history of "THIS IS RIGHT, TRUST US", then the next release is "THAT WAS WRONG, THIS IS RIGHT, TRUST US", then the next release "NOPE, IT WAS RIGHT BEFORE BEFORE SO IT'S RIGHT AGAIN NOW, TRUST US....."

And let us not forget the vector point debacle.....