Can Position Tolerance and Run-Out can be applied together? 2

[pandeydhiraj]

In any case can Position Tolerance and Run-Out can be applied together to a Feature of Size or plane surface.
I know both are location control doesnot make sense if applied to same feature, but just want to make sure about this thing.
Thanks
Dhiraj

 

[pylfrm]

Per ASME Y14.5.1M-1994, the actual value of RFS position deviation is equal to the size difference between the RAME (using the appropriate DRF) and the UAME.

My statement above is intended to be as general as it sounds, but to explain in more detail I will sacrifice some generality and use the specific example of an external cylindrical feature.

First, definitions from ASME Y14.5.1M-1994 para. 1.5:

r(P) = the distance of a point P to true position, in the case that the datum reference frame is understood from context
r[sub]AM[/sub] = actual mating size (radius)
t[sub]0[/sub] = a specific tolerance given on a drawing or part specification​

I will also define the following:

actual_value = actual value of the feature's position deviation
size_UAME = diameter of the feature's unrelated actual mating envelope
size_RAME = diameter of the feature's related actual mating envelope (orientation and location constrained using the DRF of the position tolerance)​

ASME Y14.5.1M-1994 does not use the terms 'UAME' and 'RAME', so the two types of AME are not always clearly distinguished. I will use the ASME Y14.5-2009 definitions of these terms for clarity. Unfortunately we are left to determine from context that r[sub]AM[/sub] refers to the UAME size in this case.

Per Table 5-1, the tolerance zone (volume in which material is prohibited) is defined as follows:

r(P) > b​

To get the tolerance zone boundary, convert the inequality to an equation:

r(P) = b​

For the actual value, we are interested in the smallest such boundary not violated by the feature. Note that this is equivalent to the definition of the RAME with orientation and location constrained. Substitute, accounting for the diameter vs. radius discrepancy:

size_RAME / 2 = b​

Per Table 5-2, the size of the tolerance zone is as follows:

b = r[sub]AM[/sub] + t[sub]0[/sub] / 2​

Substitute as discussed above:

b = size_UAME / 2 + actual_value / 2​

Combine the two equations, eliminating b:

size_RAME / 2 = size_UAME / 2 + actual_value / 2​

Multiply by 2:

size_RAME = size_UAME + actual_value​

Rearrange:

actual_value = size_RAME - size_UAME​

Additionally, if it were as you suggest (size difference between UAME and RAME) wouldn't that be zero in this case? Unless there is orientation error, which I do not think we were assuming any with this simplified 2D case, the UAME and RAME would be identical (99.544) - right?

I was referring to the RAME with both orientation and location constrained using the DRF of the position tolerance. I had forgotten that Y14.5-2009 says "constrained either in orientation or location or both", so I failed to specify.

Does this clear things up?


pylfrm

 

[chez311]

pylfrm,

I can't express enough how much I appreciate your laying it out like that in simple terms - that was an excellent explanation and really helped me decipher some of the concepts related to position in Y14.5.1 . I know some of this stuff may be somewhat elementary to those who are more familiar with it, but I do wish the math standard was more accessible and I don't think I'm alone in having a hard time following it. I'd really like to start diving in and utilizing the math standard when applicable, so I can promise this won't be the last time I'm asking questions about it - thanks again for the help in furthering my understanding/learning of the topic.

In regards to UAME/RAME definition in Y14.5 I also had to digest some of that, I'll be honest from the examples utilized to teach it to me I was under the impression that the RAME was only constrained in orientation. Now this didn't come from anything I saw explicitly, its just I never saw an example where the RAME was location constrained. Indeed with the relatively scant treatment in the standard the only examples which mention it (Fig 4-20(b) in relation to para 4.11.13 and 7-18(b) in relation to para 7.3.6.2.2) are constrained in orientation. It is only in the definition you pointed out in para 1.3.25.2 (and similar Related Actual Minimum Material Envelope per para 1.3.26.2) where its mentioned that it can be constrained in both orientation and location. I know your example did not explicitly reference a DRF or specific tolerance, but the fact that we were discussing position I think would imply that there is a DRF specified which constrains the feature in location and orientation in some manner (its been discussed before - if there is no location constraint in some form, whether by SIM REQ or other then position is not really the proper callout) - in such a case would you say that the RAME would automatically be location constrained? This is the only way I know how to interpret 1.3.25.2 - ie: whether the RAME is constrained in orientation, location, or both is dictated by the DRF and type of tolerance applied (position, orientation, etc..).

Not to drag this out further, but since we were discussing RFS - my mind naturally jumps to the MMC/MMB case. Is this interpretation any different in those cases? Is the RAME still location constrained or does the MMC/MMB condition affect this requirement vs RFS?

 

[3DDave]

chez311,

The math standard isn't a particular improvement; it substitutes one layer of abstraction for a different layer.

Basically, if you take a class in vectors and linear algebra you can recreate the majority of the math standard from the main standard. The standout contribution, such as it is, is the resolution to arguments about rocking on datum simulators and even that does a poor job of translating to final assembly expectations. The next one is the concept of spines, which is mentioned only once in the main '2009 Y14.5 standard. It's less a standout because it's really just a reflection of how CAD systems work.

 

[chez311]

3DDave,

Thats a fair assessment. It just seemed to me that there were some situations where Y14.5.1 provided some clarity where Y14.5 is lacking - for example in this case determining what the position error is according to the surface interpretation. Its been a while since my linear algebra courses in college, and admittedly I probably didn't pay attention as much as I should have (truthfully I simply didn't enjoy it nearly as much as calculus). The language and terminology doesn't help either, but now I have a little insight into how some of the terms/variables in Y14.5.1 translate to those utilized in Y14.5 - perhaps its just a paradigm shift that I need to make, as I can understand the concepts just fine for the most part. Maybe as you point out its not quite as useful as I initially thought because it could be accomplished by taking the time to plot it out and do the math for myself to come to the same conclusions, however it might help to have a roadmap in those instances.

 

[pylfrm]

chez311,

I suppose I used the term RAME in an unusual context without much explanation. I saw a way to condense several paragraphs and equations down to one sentence, so I ran with it.

The usual context is RMB non-primary datum feature simulators, where the constraint is defined by the higher-precedence datum feature reference(s). Here are some examples from ASME Y14.5-2009 where both orientation and location of the RAME are constrained:
[ul]
[li]Fig. 4-9: Datum feature simulator of datum feature C[/li]
[li]Fig. 4-15: Datum feature simulator of datum feature C[/li]
[li]Fig. 4-32(a): Datum feature simulator of datum feature B[/li]
[li]Fig. 4-43: Datum feature simulator of datum feature C[/li]
[/ul]

The way I look at it, any RAME is always fully constrained at true position. The constraint between that and the actual part depends on the datum feature references involved.

For MMC position deviation, the relevant RAME is the same. The actual value calculation involves MMC size instead of UAME size though.


pylfrm

 

[chez311]

pylfrm,

What I was really referring to was figures/paragraphs where the standard explicitly references the RAME by name - as far as I can tell it only happens the handful of times that I mentioned, all of which only constrain orientation. I agree though that the examples you noted are times when the RAME is constrained in location and orientation. It might seem excessive to need someone to point out "this is exactly how the Related Actual Mating Envelope can be constrained in location and orientation simultaneously" and it seems like an obvious, logical conclusion to me now but it just never quite clicked into place for me until you pointed it out.

I'm still grappling with what this "actual value" means in terms of actual position error for the surface interpretation. After giving it some thought, I've at least come to the realization that the surface interpretation is not really about actually measuring deviation of the entire surface (which would be more akin to a surface control) - its more about (1) ensuring that the surface does not violate the virtual condition (VC) ie: RAME > VC and (2) somehow evaluating the mating envelope deviation from the VC.

What I'm not super clear on is how the size alone of the UAME tells you much about the position error due to the surface. Imagine a feature like that on Fig. 5-1 in Y14.5.1 - the axis of the UAME could continue to deviate away from the RAME (within the limits of size, of course) but the actual value per the surface interpretation (which for an internal feature i believe is: actual_value = size_UAME - size_RAME) would remain unchanged if the size of the UAME did not change (as well as the size of the RAME). And even if it did, a UAME of a larger size but with its axis closer to the RAME would show a larger position error than a UAME of a smaller size with its axis further away from the RAME (assuming again, the size of the RAME did not change either).

Something just isn't adding up for me..

 

[pylfrm]

After giving it some thought, I've at least come to the realization that the surface interpretation is not really about actually measuring deviation of the entire surface (which would be more akin to a surface control) - its more about (1) ensuring that the surface does not violate the virtual condition (VC) ie: RAME > VC and (2) somehow evaluating the mating envelope deviation from the VC.

The surface interpretation results in a boundary that the entire feature surface must not violate. Would you not consider that a surface control? The actual value ends up being determined by a few extreme points only, but that's the case with almost all tolerance types.

Y14.5.1 only applies the term 'virtual condition' to MMC and LMC tolerance boundaries, so I'm not sure exactly what you're referring to here. Are you using 'VC' to mean the tolerance zone boundary defined by tables 5-1 and 5-2?

Imagine a feature like that on Fig. 5-1 in Y14.5.1 - the axis of the UAME could continue to deviate away from the RAME (within the limits of size, of course) but the actual value per the surface interpretation (which for an internal feature i believe is: actual_value = size_UAME - size_RAME) would remain unchanged if the size of the UAME did not change (as well as the size of the RAME). And even if it did, a UAME of a larger size but with its axis closer to the RAME would show a larger position error than a UAME of a smaller size with its axis further away from the RAME (assuming again, the size of the RAME did not change either).

Everything you say here is correct. The surface interpretation is completely different than the resolved geometry interpretation, and has nothing to do with the UAME axis. Aside from the fact that the committee thought it was a good idea to define two contradictory meanings for these tolerances, what isn't adding up?


pylfrm

 

[chez311]

pylfrm,

Yes I would have to concede that would be a surface control. I guess I was trying to separate it in my mind as we are talking about position, but I guess the distinction becomes murky when discussing surface interpretation of position.

As far as virtual condition, you are again correct - I was conflating the terms for MMC/LMC and RFS without regard to their application. I guess I would be referring to inner (for internal feature) / outer (for external feature) boundaries for RFS and VC for MMC/LMC. I also seem to have forgotten my post earlier in this thread that showed there is no reference to surface interpretation in Y14.5-2009 in connection with RFS, instead it is only mentioned with MMC/LMC. Can we take this to mean that the calculation included in Y14.5.1 for RFS surface interpretation is not actually valid when taken in conjunction with Y14.5-2009? If that sort of invalidates my below I apologize - but we were discussing surface interpretation in regards to RFS previously and it is included in the (apparently soon to be updated) Y14.5.1-1994 standard so I will continue.

The surface interpretation is completely different than the resolved geometry interpretation, and has nothing to do with the UAME axis.

I guess I understand that its different than the resolved geometry interpretation, but per my aforementioned reasons considering the UAME size alone just doesn't seem to tell the whole story. That being said my confusion disappears when discussing MMC/LMC surface interpretation, as the actual value would be the difference between the MMC/LMC size (respectively) and the RAME size. Considering the MMC case since the RAME and MMC boundary are concentric the difference in size between the RAME and MMC size can be interpreted as a distance - ie: smaller difference between RAME and MMC size also means a smaller distance between the surface of the feature and VC and is closer to violating the VC. For RFS with the actual value being the difference in size between the RAME and UAME means.....what exactly? Per my example deviations of Fig. 5-1 in Y14.5.1 the UAME can be bigger/smaller or closer/further from the RAME and I just don't see what it tells you about the surface in relation to the inner/outer boundary (for an internal/external feature respectively). As far as I can tell a larger/smaller actual value just means the difference between the UAME and RAME is larger/smaller - I don't see a similar logical conclusion like there is with MMC/LMC.

Also by "contradictory meanings" are you maybe alluding to what you mentioned in Evan's post (

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

about surface interpreation being correct for MMC/LMC and resolved geometry being correct for RFS?

 

[pylfrm]

Can we take this to mean that the calculation included in Y14.5.1 for RFS surface interpretation is not actually valid when taken in conjunction with Y14.5-2009?

Correct, and it's not valid for Y14.5M-1994 either. Nevertheless, CheckerHater inspired me to look it up.

That being said my confusion disappears when discussing MMC/LMC surface interpretation, as the actual value would be the difference between the MMC/LMC size (respectively) and the RAME size. Considering the MMC case since the RAME and MMC boundary are concentric the difference in size between the RAME and MMC size can be interpreted as a distance - ie: smaller difference between RAME and MMC size also means a smaller distance between the surface of the feature and VC and is closer to violating the VC.

Actual values for MMC position are as follows:

internal feature: actual_value = size_MMC - size_RAME
external feature: actual_value = size_RAME - size_MMC​

Unlike RFS where it's just an absolute difference, the order matters for the subtraction here. Actual values can be positive, zero, or negative. A larger value means the feature is closer to violating the virtual condition boundary, assuming it hasn't already.

For RFS with the actual value being the difference in size between the RAME and UAME means.....what exactly? Per my example deviations of Fig. 5-1 in Y14.5.1 the UAME can be bigger/smaller or closer/further from the RAME and I just don't see what it tells you about the surface in relation to the inner/outer boundary (for an internal/external feature respectively). As far as I can tell a larger/smaller actual value just means the difference between the UAME and RAME is larger/smaller - I don't see a similar logical conclusion like there is with MMC/LMC.

By itself, the RFS actual value provides no information about the relationship of the feature surface to the inner/outer boundary. It does tell you how much interference there would be if UAME boundary were shifted to true position. How useful useful is that? I'm not really sure.

Also by "contradictory meanings" are you maybe alluding to what you mentioned in Evan's post (

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

about surface interpreation being correct for MMC/LMC and resolved geometry being correct for RFS?

Yes. It's a mystery to me why the standard would describe two interpretations for a tolerance, and then tell you to ignore one of them unless it just happens to agree with the other. Unfortunately it seems rather common for people to use the axis interpretation as their working definition for MMC and LMC position tolerances, despite the fact that it's more complex and less functionally relevant.


pylfrm

 

[chez311]

Unlike RFS where it's just an absolute difference, the order matters for the subtraction here. Actual values can be positive, zero, or negative. A larger value means the feature is closer to violating the virtual condition boundary, assuming it hasn't already.

This is true - I was referring to the absolute value of the difference for MMC/LMC as I was equating it to a distance. Though I guess you could interpret the sign as indication of a vector direction, I was not considering that.. Doubly so since I was not considering the case where the virtual condition boundary was violated which would be the only time you get a positive value, correct?

By itself, the RFS actual value provides no information about the relationship of the feature surface to the inner/outer boundary. It does tell you how much interference there would be if UAME boundary were shifted to true position. How useful useful is that? I'm not really sure.

Interference to what, the inner/outer boundary if the UAME were shifted to true position? Does it even tell you that? It only involves the relative size difference of the UAME and RAME - take for example a feature whose UAME and RAME are identical (co-radial - ie: concentric and of the same size). The actual value would be zero, however the UAME/RAME could be anywhere between the extreme inner/outer boundaries. One has to wonder what exactly the committee was trying to accomplish with this calculation - as you said I just don't see how useful it is. I do understand though that it can't be the same calculation as MMC (which would be RAME to inner/outer boundary for RFS) as I think that would provide some amount of bonus tolerance. The more I think about it the more I agree with you that for RFS, the only correct interpretation is the axis (resolved geometry) interpretation - I know that Y14.5-2009 supports that, hopefully the new Y14.5.1 will be consistent in this as well. EDIT: Update - its not. The same calculation is included in the draft I have in front of me as was in the Y14.5.1-1994 edition..

I just want to say thank you again for digging into this and fielding my questions. Its helped me quite a bit in understanding the math standard and some of the reasoning behind it. Hopefully by the time the new revision comes out I will have a good grasp on the concepts.

 

[pylfrm]

Doubly so since I was not considering the case where the virtual condition boundary was violated which would be the only time you get a positive value, correct?

No. The virtual condition boundary is not violated unless the actual value is larger than the tolerance value.

Interference to what, the inner/outer boundary if the UAME were shifted to true position? Does it even tell you that?

I meant interference between the actual part and an imaginary boundary of UAME size, but located at true position. The actual value is two times the greatest radial interference. Admittedly, this is basically just a restatement of the definition. It's probably not an amazing insight into functional or practical meaning, but it was the best I could come up with.

For [url

https://res.cloudinary.com/engineering-com/image/upload/v1547513201/tips/1_crop_3_wjgvz5.png

]this example[/url] we get an actual value of 9.544 with the axis interpretation, and 0.456 with the surface interpretation. Imagine we modify the part by shifting the feature 4.772 to the right. This makes the UAME axis coincident with the true position axis and brings the position actual value down to zero for both interpretations. How much better is the part in a practical sense though? To me, an improvement of 0.456 seems somewhat more reasonable than 9.544. The runout changes from 5.000 to 4.544, and I think this paints a better picture: There was a slight improvement, but most of the error remains.

I'd be interested to hear other thoughts on this.

I just want to say thank you again for digging into this and fielding my questions. Its helped me quite a bit in understanding the math standard and some of the reasoning behind it.

You're welcome. This thread certainly went off in an interesting direction, and I'm glad to have an excuse for the digging.


pylfrm

 

[pylfrm]

It turns out there is a specific term for what I was calling RAME size:

1.4.21 Size, true position mating. The size, optimized over the candidate datum reference frame set, R, of the actual mating envelope constrained to be located and oriented at true position. The true position mating size will be designated r[sub]TP[/sub].

Interestingly, it appears this term is not actually used anywhere in the standard. Anyway, it probably would have provided some clarity here.


pylfrm