Is there something wrong with this program?

**BIGWIG7** · 10-16-2019, 10:28 AM

why don't you translate x,y origin to dat -C- during align AUTO_1?

**JEFMAN** · 10-16-2019, 10:34 AM

CIR 2, 3, 4 and 5 are measured on 180° only, so there not very accurate.
I think I would construct DATUM_D from circle hits, even if it seems to be ok.

Can you post the result with parameters on ?

**BIGWIG7** · 10-16-2019, 10:34 AM

well maybe datum -d- is oot?
what is the call out for dat -d-?

**NinjaBadger** · 10-16-2019, 11:21 AM

What's DX?

I think I've read that the Demon doesn't like it when you use variables for feature theo's which are used in an alignment.

**Tater** · 10-16-2019, 01:27 PM

What is the form of cylinder and circles?

**CodeWarrior** · 10-17-2019, 08:46 AM

I'm following this thread in hopes something gets resolved.

I really wish one of the PC-DMIS developers could answer this. I've asked tech support about this with multiple programs over the past couple years and haven't gotten a conclusive answer.

It makes me look incompetent when I can't explain to engineering/customers whether or not the part passed or failed.

**AndersI** · 10-17-2019, 09:13 AM

I may be stupid, but I see this:

- two datum cylinders with zero positional tolerance
- the same two cylinders are too far apart.

= there is no way to fit your datums to the requirement (the functional gage would not fit the datums, and you would not get the chance to verify the dimensioned feature). Note that all available (M) from the datum features has been consumed, and they can still not both be green.

Why is the positional tolerance zero on the datum features?

**AndersI** · 10-17-2019, 09:58 AM

Originally posted by JacobCheverie

I punched the FCF into Xact as I see it on the print. Where would I go about changing the +TOL on the datum features? I have never seen this as being an option, nor necessary.

I would guess there should be a position dimension for the two datums' relation to each other - otherwise how can you be sure a fit is possible? But it's difficult for me to test offline...

**JacobCheverie** · 10-17-2019, 10:00 AM

Here is another interpretation of the results, kind of going from what AndersI said. With the angular deviation of datum C (about 8 minutes of arc), the coordinate system formed by DRF [C|D] is skewed when leveling to C. Now, D is to be basically oriented (perpendicular) to C when rotating the coordinate system. There is a maximum material boundary of D whose center axis lies on the coordinate axis formed when leveling to C. The angular deviation of C puts the MMB of D at such a location that the actual measured cylinder D is outside of the MMB, thus the datum position is OOT.

Therefore, the part is bad. Is this the case? Is this how the Xact algorithms work?

With the amount of time spent on this we should've built a functional gage by now. If this interpretation is true, the part will fail a functional test in the following way:

Locating on C with a pin of MMC size, datum D must be placed in some sort of cylindrical container with I.D. size equal to MMC size of D. Then E must be fit on a pin of MMC size located basically per the print.
The failure would come by D not fitting into it's "container".

Is any of this correct?

**Tater** · 10-17-2019, 10:15 AM

Datum -D- is 10 x longer than Datum -C-. -C- is Level, make level from -D- if possible........

**Loon4ever** · 10-17-2019, 10:43 AM

Not really a solution but we just had an issue in our NADCAP audit where two Sets of holes where to the same DRF but PCDMIS was calculating the Datum shift differently for each set. The Auditor was convinced that it was PCDMIS that just couldn't calculate Datum Shift properly. I didn't write the program so I just said screw it and removed the MMB from the FCF to be done with it.

**JacobCheverie** · 11-11-2019, 11:35 AM

For anybody who is still following this/anybody who has received datum OOT values in XactMeasure -

Last Friday I spoke with Rob Jensen and he made a few things clear to me, some of which we've heard from Wes Cisco in a previous post. The internal programming and calculations used for Xact are essentially based on Y14.5.1-1994. These algorithms, if you will, are going on 25/26 years old. Sometime early next year we will see a new revision of 14.5.1 which is built on a much stronger mathematical foundation. These methods of calculation will be brought into PC-DMIS at some point and it sounds like we will have something very nice to send XactMeasure off.

That's the future. For now, there is a known bug in which the report will be red but read OOT 0.0000. The OOT is not truly 0, but out by an amount that is visible at 6+ decimal places. This is representative of a part that is probably right on the border, but I would not fail it. The red on the reports is annoying, but there is nothing Hexagon can do.
It is also possible for the datum to shift past (not a bug) it's boundary in order to make a feature pass. In my opinion, the software shouldn't do this, but then again, the fitting algorithms are just told to run to completion. It appears that Hexagon just didn't have the logic in that states "If shift leads to datum OOT, shift back and report NG". Again, I think we will see something much cleaner in 2020 and beyond.
Also, not quite a bug but rather a lack of insight, many people already know this but I'm not sure if they know why: Datum features that are CONSTRUCTED should not be used in a FCF with material boundary modifiers. If you construct a cylinder from a few circles, the cylinder doesn't retain the hit points of the circles. All the constructed cylinder is is an axis going through the center of each individual circle. The hit points from each circle are all projected onto a plane and a best fit (on the plane) is performed to determine cylinder size. So now we have an axis with an associated size, located at the cylinder centroid. This makes for a "perfect" cylinder without a clear way of shifting to satisfy a boundary condition.

For my issue specifically, the real problem stems from design. A very short cylinder is being used as a primary datum when I have a perfectly long cylinder being used as secondary. Furthermore, there needs to be a geometric control on the secondary datum that respects the order of precedence seen in the DRF. There doesn't exist such a callout on my print, and this is why, as has been pointed out by AndersI , the +Tol column reads 0.0000. It should not. The reason for this requirement is such that a proper boundary can be calculated for the datum features. Without this control, the boundary is not being computed correctly.

As a last note, as many of you may already know, the required control that I do not have must be placed before the dimension in question. And now I must try to reach out to the supplier of the drawing to tell them that the design is a bit off.

I hope this helps.

EDIT: Want to send out another thank you to neil.challinor. Neil came on the forum and responded to some people that were unhappy about support, frankly myself included. He asked people to get in touch with him directly. After doing so, it wasn't long until I had a response on more than one support ticket. Don't lose hope in Hex yet.

**AndersI** · 11-12-2019, 05:53 AM

Originally posted by louisd

If a rounding glitch/bug is to blame...

I'd consider it neither glitch nor bug - if the part is as much as an atom out of tolerance, it *is* out of tolerance according to the standards.

What's interesting in these circumstances is that no-one, ever, questions a result that is an atom *inside* the limits, while at the same time we *know* we have measurement uncertainty quite larger than that...

What I really would like is a possibility to enter a 'system uncertainty zone' and call those results neither IN or OUT, but UNCERTAIN. But that's not interesting for the industry, it seems...

**Jakep379** · 11-13-2019, 09:03 AM

Originally posted by JacobCheverie View Post

Also, not quite a bug but rather a lack of insight, many people already know this but I'm not sure if they know why: Datum features that are CONSTRUCTED should not be used in a FCF with material boundary modifiers. If you construct a cylinder from a few circles, the cylinder doesn't retain the hit points of the circles. All the constructed cylinder is is an axis going through the center of each individual circle. The hit points from each circle are all projected onto a plane and a best fit (on the plane) is performed to determine cylinder size. So now we have an axis with an associated size, located at the cylinder centroid. This makes for a "perfect" cylinder without a clear way of shifting to satisfy a boundary condition.

Hey Jacob,

This is the first time i'm hearing this. I've tried to find some more info can you point me to anywhere where this is said?
Does this apply to all constructed features? How could u create a width without construction?
What if instead of circles for a cylinder you use a bunch of random vector points for a cylinder?

Is there something wrong with this program?

Is there something wrong with this program?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Related Topics