XACTMeasure Position

[JacobCheverie]

I am trying to measure Position in XactMeasure. I have MMB on primary and secondary datum. I run the part, it says Position is bad. I take MMB off, it says Position is bad. I turn MMB on, it says Position is good. How?

I understand the Datum Shift/MMB relationship, but I am translating and rotating in all three X, Y, Z. How complicated is this fitting algorithm? As far as I am concerned, the shift values that I see are computer mumbo-jumbo that I cannot decipher whether or not the part is good.

It'll tell me that the position of the feature is good, but the "position of the datum" is bad? Shouldn't it only shift to it's max allowable limit, not shift OOT?

I have looked through a lot of posts on this forum, none that ever came to conclusion. This cannot just be turned off as it is a customer req't. Any clues?

hex.jpg

For those wondering, I am fixing part as in top image. Measuring -D-/Leveling X+. Measuring -E-/ Rotating Z+. Translating YZ to D and X to E.

I am concerned about the Position of E to C and D.

[Darrollh]

Try measuring it in Legacy and see what you get.

[JacobCheverie]

Darrollh I have tried Legacy but I cannot accurately use MMB with Legacy according to this forum. Some parts are failing without MMB and management is requiring it.

[Sora5]

You can check out the two search result for more info on this issue. I don't think a solution ever came out of it and it remains one of those unsolved mystery today.

Search result for datum out of tolerance

[JacobCheverie]

But is the part OK if the datum is reading OOT, or does nobody know?

[Mike Ruff]

If you look at the posts Sora linked, Josh Carpenter explained what is going on, although he did not have a reason for why it does it. His linked picture that really explained it well is now unlinked in that thread though From my understanding, IF it is ONLY the DATUM POSITION showing out of tolerance, then the part should be good, because these numbers have to do with the amount of datum shift that was used/available, not with whether or not the part meets the print.

[JacobCheverie]

That's why I mentioned that I have looked at the posts. On one, Carpenter states he doesn't know, he's just a CMM guy. On the other, there is a link to Carpenter saying it's a bug/shut it off/it's not important/only engineers with too much time on their hands care.

I don't see an explanation there.

[louisd]

I am concerned about the Position of E to C and D.

Well, for datum E TP, your FCF calls for datum C as primary, and D as secondary datums.
Your alignment is not per FCF. How are you constructing Datum C and Datum D features?
--Hopefully they are both very well defined cylinders, with axis lines as long as physically possible.

-I am presuming in xact you defined the datums as C and D, yes?

If you click on the "Custom DRF" box, what is Datum C controlling? what is Datum D controlling?
First: C datum definition should be u,v,x,y
Second: D datum definition should be z and w
If not, you don't have your alignment per the print.

[JacobCheverie]

Xact should create the alignment for me. And yes, C is controlling u, v, x, and y. D is controlling z and w as they should.

Datum D is a cylinder formed from two circles at each end. C is a cylinder of two levels.

[louisd]

Ok, so everything is correct. Must be the same bug Josh explained.

You could locate and extract possible datum shift manually, to affirm your xactmeasure output is actually capturing true pass/fail if you are concerned with the red output line, I presume

[Kp61dude!]

Wait it sounds like, from reading the posts, that if datum/s shifts out of allowable boundary the part is good? How will the part fit in assembly? Anything that shifts far away from intended targets, too far, most likely won't play nice with mating parts... you'll need a big hammer.

[JacobCheverie]

Right, that would be my understanding. So now I am back to square 1. Neither Calypso NOR PC-DMIS can accurately handle MMB. We just renewed our SMA too..

[Jakep379]

I've had this issue before except my parts would check good even without MMB. I just removed it from the report per below.

http://www.pcdmisforum.com/forum/pc-dmis-enterprise-metrology-software/tips-tricks/438790-how-to-creating-a-report-tp-label-not-showing-the-datum-features

[JacobCheverie]

I saw this, I just want to know if this is truly a bug or if the part is bad before I start hiding things. Thank you

[Zero_micron_filter]

I researched the issue before as well, I don't have links to all that I found. But I made myself notes summarizing what I found.
Note what I was researching was the tertiary showing RED...not bad, but RED, and yes Josh called it a bug, but another tidbit I found was that the root of the problem was reporting of this datum's position upstream of feature Xactmeasure reporting.
I listed two solutions...I can't tell you I confirmed them, I think I did but...as I made the notes sometime last year.
1) Either cast a feature (from the datum) for reporting (the datum's position) upstream, So positions downstream in program do not calculate MMB based position of that datum (particularly for tertiary as there are no brackets to enter MMB).
2) Specify MMB (in brackets) next to datum in FCF in Xactmeasure.

Hope this helps.

[JacobCheverie]

Thanks Zero_micron_filter

The issue I'm having is with the secondary datum showing OOT, not just red. Specification of the boundary size did not help me. I will try casting the feature.

[Kp61dude!]

Josh's ears are probably ringing! That guy was alright...

[louisd]

If I were in your shoes, I'd do the following:
1: Check without mmb.
1a: If passes phuuuck it. it's a good part without shift.
1b: If fails, start #2
2: I'd be creating an alignment to reflect the FCF, then I would report xyz and diam's of both datums and the measured feature (datum E)
I'd also create intersect point between C and D and report those xyz's (as that's your actual variation for D shift if you are level to D)
trig it out on paper from there.
3: Compare results,
3a: If your trig'd data shows the part passes, and MMB shift would support passing the part, i'd start automating your math in assignments and generics.
3b: if your data shows the part fails and isn't aligned with xact, i'd be calling hex, opening a ticket and making a big fuss.
3c: if your data shows the part fails and is aligned with xact, you just confirmed that the demon is actually doing something right!

[JacobCheverie]

louisd I will give it a shot in the morning. Very logical, thank you.

[vpt.se]

Let's ping Rob Jensen on this one.

I am with JacobCheverie on this one, having the fitting algo only to use the max available bonus from the datum, making the datum in tolerance and the feature OOT - never the other way around (fitting the feature to it's best position which could make the feature in tolerance, but rendering the datum OOT).

I think the general consensus is to have it reversed from the way it is today.

[JacobCheverie]

Going further with what louisd mentioned, I'd like some verification to make sure that I am doing this correctly. I set my alignment per the FCF (level Y+ to [C], Rotate X+ about Y+ to [D], Origin X,Z on [C] and Y on [D]). Correct?

I dimensioned [C], [D], and [E] per my FCF alignment and found the following.

[C]: dx = 0, dz = 0, dy is irrelevant as is expected, I.D. size is .00023 over MMC size. This allows motion inside the walls of a hollow cylinder of wall thickness .00023, correct?

[D]: dx is irrelevant, dy = 0, dz = -.00061. O.D. size is .00451 under MMC size. This allows motion inside the walls of a hollow cylinder of wall thickness .00451, correct?

[E]: dx = .00015, dy = -.00188, dz is irrelevant. I.D. size is .00034 over MMC size. This implies that [E] is .00015 off center in X and -.00188 off center in Y of a cylindrical tolerance zone of size .00234 (Position tolerance of .002)

Now 2*sqrt(dx^2 + dy^2) for [E] implies a position of .00377 - OOT by ~.0014


BUT WAIT: Datum Shift.

[C] can slide over .00015 to eliminate dx for [E]. [C] is still OK, nothing out of bounds here.
[D] can slide back .00188 to eliminate dy for [E]. [D] is still OK, nothing out of bounds here.

Now [E] position is 0 and part is OK.

Now why is it telling me [D] is OOT?


Then I shut MMB off for both datums, part is still bad (by about .0014).
Then I turn MMB on for both datums, everything is A-OK.

Something is wrong.

[louisd]

Considering the functional interface of the D datum: It seems like it has threads on the end? Almost like a swingarm or rod end, correct? The D datum shaft as it approaches the C datum seems like it's just a span from the threads, correct? Try rotating about a line you construct from a circle as far down towards the end of D that you can, to the center of C. See how that works out.

C datum is your primary datum and XZ origin, you should be rotating about the centroid of C, radially outward to D. not orthogonal to the whole D datum, if that makes more sense.

[JacobCheverie]

louisd no threads, no rod end. Just a shank with two bores at each end perpendicular to one another. I will try rotating about a line constructed from D to C but that should only do two things:

1.) Alleviate the error in Z between C and D
2.) Shorten or lengthen the position of E relative to C

And I think you may have misinterpreted my alignment scheme. I am leveling (Y+) to C. Then I am rotating D (ABOUT Y+ (C)) to X+.

[vpt.se]

If datum D is a plane - and OOT as datum in the TP - then something is very wrong.

EDIT: Noticed that datum D has an OD, ergo not a plane. Weird dimensioning as the datum is connected to the surface of the cylinder - not the centerline...

[JacobCheverie]

D is a cylindrical shank. E and C are also cylindrical.

[michaelwildschutz]

Something for you all to read
Deleting Datum shift from FCF and Report Deleting Datum Shift(fcf) From Report Template.JPG

[JacobCheverie]

Thanks michaelwildschutz but I need the datum shift to pass the part and I need it to calculate correctly. I don't want to just eliminate/hide it.

[vpt.se]

^^ this!!!!!!!

[JacobCheverie]

Just so everybody is aware, I am still waiting on a solution to this particular problem from Hexagon.

However, in the case of the "bug" that everybody is referring to, Matthew Beecher with Hexagon has provided me with a little more information. Here is my paraphrased version of his response.
Sometimes, your datum row will be red but it'll show OOT = .0000 - This is a rare bug attributed to issues in the software that stem from rounding. Apparently, the datum shifts to it's allowable limit and then some. The additional shift past it's limit is out to about nine decimal places (.000000001 or so) and rounding makes it 0, but it is technically "OOT" hence the red report. In this case, Hexagon says to disregard the red and the part is OK. Apparently, this was supposed to be fixed in 2019R2 but it got pushed back. It is expected to be fixed in the next version, assuming the developers hold their current schedule.

Again, in my case, I am not seeing datum OOT = .0000, I am seeing datum OOT = .0004 up to .003 or so. This cannot be attributed to rounding. I have sent Hex a program to look at and they have forwarded it to a developer. I am hoping to hear back soon as a critical job is sitting on the floor over this. Hope this helps people understand what the bug actually is and be able to differentiate between OOT = .0000 and OOT > .0000.