Threaded hole perpendicularity callout

[Osen]

Hi All,

I'm currently designing a plate that has NPT threads. Custom NPT plugs thread into the holes and stick out about 35mm from the surface. When the first article came back and assembled with the plugs, I noticed that one of the plugs is visibly angled off axis when threaded into the hole. What's the typical way of controlling perpendicularity of NPT threaded holes?

Thank you.

 

[Kedu]

Projected tolerance zone is your best bet here.
See this discussion

https://www.eng-tips.com/viewthread.cfm?qid=381644

 

[chez311]

Osen,
What spec is your part drawn to? Is it ASME Y14.5 or ISO?

Kedu,
I think the issue is more that the specified thread is NPT - a tapered (ie: conical) thread form. Projected tolerance might be appropriate for a fitting*, which presumably projects some distance above the plate, but it doesn't solve the issue of applying position/perpendicularity to a conical feature - unless you think standard position/orientation controls could be applied to an NPT thread without issue.

*Edit: I noticed OP's post included the verbiage "When the first article came back and assembled with the plugs, I noticed that one of the plugs" - if these plugs are flush or nearly so then discussion of a projected tolerance may not be necessary. Perhaps OP can confirm.

 

[Osen]

Kedu, chez311,

Thank you for the responses.

The perpendicularity of the threaded holes is more for looks than function. The assembly is a custom vacuum application for a customer where feedthroughs (plugs) are mounted to the plate. When properly installed, the feedthroughs sit about 35mm above the surface of the plate, so if the thread is off, you'll see a slanted feedthrough.

In this case would I draw a 35mm projected zone above the surface and spec a positional tolerance?

chez311,

The spec we're using is ASME Y14.5.

 

[chez311]

Osen,

If you have access to Y14.5 section 7.4.1 of Y14.5-2009 addresses projected tolerance zones. Below are two examples of such a specification - a (P) in the FCF accompanying either by a dimension or a chain line with a dimension can be utilized. This can be for either position or orientation controls.

That being said, Y14.5 does NOT support position or orientation controls for conical/tapered features which your thread is. You could utilize a special note which describes a gauging requirement (perhaps orientation of a NPT gauge plug with a cylindrical pin/body with a height of the projected tolerance in the FCF).

Or maybe I'm overthinking it and theres no issue with NPT or tapered/conical thread forms - especially if the requirement is aesthetic not functional. I'm interested to hear others suggestions.

 

[Osen]

chez311,

Thank you for the example image. I appreciate the help.

I think the projected zone standard that you and Kedu suggested would be my best bet going forward.

 

[greenimi]

That being said, Y14.5 does NOT support position or orientation controls for conical/tapered features which your thread is. You could utilize a special note which describes a gauging requirement (perhaps orientation of a NPT gauge plug with a cylindrical pin/body with a height of the projected tolerance in the FCF).
Or maybe I'm overthinking it and theres no issue with NPT or tapered/conical thread forms

I do not see a problem in applying location or orientation controls on an NPT thread. The fact the axis should be driven from the conical helix /surface (and not from a cylindrical helix) I do not think it makes it less eligible.
And the simulation is quite the same, in my opinion. A conical threaded plug (versus a cylindrical one) with a pilot area to get an accurate (repeatable and reproducible) axis.

 

[chez311]

I do not see a problem in applying location or orientation controls on an NPT thread. The fact the axis should be driven from the conical helix /surface (and not from a cylindrical helix) I do not think it makes it less eligible.

One could utilize the same logic for an unthreaded conical feature and yet it is not supported by the standard. An axis can be derived from both geometries.

And the simulation is quite the same, in my opinion. A conical threaded plug (versus a cylindrical one) with a pilot area to get an accurate (repeatable and reproducible) axis.

Obviously from my previous statement I agree from a practical standpoint, I'm just playing a bit of devil's advocate. The only difference between a threaded vs. non-threaded gauge/simulator is that the threads provide a mechanism to draw the gauge into contact with the feature. Since the behavior specified for an RFS FOS simulator is expansion we can see why this would not work for a unthreaded conical gauge (as opposed to a cylindrical unthreaded gauge) - however if some sort of note or gauging requirement for the simulator to be pulled into contact with the feature would you have an issue with applying position/orientation to an unthreaded feature in that circumstance?

 

[shiva rahul]

chez311,

Its actually the same logic, since in both the features an axis can be derived from their geometries. Even though ASME standard doesn't directly support position or orientation controls for conical/tapered features for threads, we can directly apply the same logic because the behavior shall be same as its a RFS FOS and the simulator shall expand to make the maximum possible contact.

And projected zome shall be the best possible way to factor our the position/perpendicularity issues in this case

/shiva

 

[chez311]

shiva rahul,

I've already agreed from a practical standpoint that for a threaded feature it can be utilized.

An unthreaded conical feature specified RFS would require simulation/measurement of the UAME. Y14.5 does not define a UAME for conical features, and such geometry allows infinite expansion of a UAME simulator (unconstrained to DRF). Neither is a RAME defined for a conical geometry, however as long as translation along the feature axis is constrained by the particular chosen DRF a similar such boundary can be imagined.

"Maximum possible contact" is an often quoted, but poorly defined (read: not defined in Y14.5) concept and personally in most cases I find it is best to ignore it.

My point is that I think RFS position could be applied to an unthreaded conical feature as long as a gauging requirement were specified to restrain the simulator to the surface of the feature. That or some sort of fitting routine could be implemented.

MMC position, not requiring the simulation of the UAME, could be executed similar to Y14.5-2009 fig 8-24 in conjunction with the "boundary" concept.

 

[greenimi]

An unthreaded conical feature specified RFS would require simulation/measurement of the UAME. Y14.5 does not define a UAME for conical features, and such geometry allows infinite expansion of a UAME simulator (unconstrained to DRF).

Fig. 4-44 and 4-45 /2009 have cones identified as datum features so I still think there is support from the standard for such of application (drive an axis from a conical feature).

 

[chez311]

greenimi,

An axis can be derived from any geometry with symmetry (or arbitrarily on any geometry for that matter), that doesn't mean evaluation of an applied position tolerance is simple.

Cones are not FOS and do not have a defined UAME. The axis required for evaluation of RFS position tolerance is that of the UAME, and since cones do not have a UAME this leaves the consideration for what boundary/axis combination to be utilized open ended. I would say in this case any boundary could be utilized which makes contact with the feature and therefore any range of axes can be chosen if not specified (that is - if we assume that position applied to a conical feature as it is, which without a special note I would say is questionable already). Inclusion of a gauging/restraint requirement or fitting routine would at least remove some of this ambiguity about what boundary to utilize - unless you are okay with any boundary which makes contact with the feature.

Below is an example of three boundaries on a conical feature with form error making the same amount of contact which without specification otherwise could all be valid boundaries/axes. This and the above also applies to a cone as a primary datum feature as shown in Y14.5-2009 fig 4-44/4-45. Unlike a FOS the minimum or maximum (for external/internal features respectively) boundary cannot be utilized because there is no minimum or maximum.

Perhaps some extension of the candidate datum concept could be applied here, however I think this would leave some room for interpretation that would not lead to a common standard method. A tapered feature with nominally flat/planar sides would be easier to apply this to.

 

[chez311]

From the thread (

https://www.eng-tips.com/viewthread.cfm?qid=448819)

where pylfrm and sem discuss a similar concept:

The "ability to escape" condition was my rough idea for how the concept of containment should be interpreted in this context, but let me back up a bit. The definitions provided by ASME Y14.5-2009 are not sufficiently robust to provide a definitive answer here. To arrive at a reasonable answer, we can attempt to patch up some of the gaps. To that end, consider the following replacement definitions:

Unrelated actual mating envelope: A theoretical envelope outside the material, uniformly offset from a feature's true profile as far as possible in the direction toward the material. The relationship between the true profile and the actual surface is otherwise unconstrained. If the material of the feature does not provide a limit to the offset, no unrelated actual mating envelope exists.

Feature of size: A feature with an unrelated actual mating envelope.

I think these definitions generally produce the same answers for cases that are clearly defined in the standard, and provide some additional clarity for cases that aren't. Thoughts?

Using these definitions, the conical feature (with or without the flat surface at the tip) is certainly not a feature of size. If you imagine the true profile starts out roughly aligned with the actual feature and an offset envelope progresses toward the material, it never reaches a point where it can't progress further. The feature just gets pushed away from the true profile.

The classification of a cone as a non-FOS precludes I think the typical use of RFS position on a conical feature without special notation about how a boundary/axis is to be established as the definition of UAME is insufficient (it does not exist for this shape).

If a conical surface is used as a primary datum feature as shown in Fig. 4-44, the datum feature simulator is coincident with the true profile. In this respect, a cone has more in common with a plane than it does with a feature of size like a cylinder. That doesn't mean it can't establish an axis, just that it does so in a different way.

This equivalence means that the datum feature simulator may as well be a solid piece of material. A conical socket with an opening diameter of roughly 0.9*F should do the job. Datum simulation would basically be a matter of pushing the part up against the simulator axially.

I don't disagree with this evaluation of a cone as a primary datum feature, however the last bit (bolded) I think needs further clarification - see the end of my previous post (26 Sep 19 18:44). It certainly can be simply pushed up against a fixed simulator however that doesn't solve the issue with form error as I noted as multiple orientations are possible and as I said I'm not sure the candidate datum concept provides a simple solution to this - perhaps I'm not seeing something though.