"Default" Math Vs "Legacy"?

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.

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.