General Tolerance: "ALL COAXIAL FEATURES TO BE RUNOUT WITHIN .005" 2

[CAD_Man]

Many of our components consist of complex multi-step bores and or threads.

In an effort to reduce overly redundant Feature Control Frames we would like to have add a general callout to our tolerance block.

I've seen "ALL COAXIAL FEATURES TO BE RUNOUT WITHIN .005" before, but I thought runout is measured to a defined datum. So this note leave me asking... runout to what?

Would this callout work? If so please explain how.

Has anyone done something like this before?

Any suggestions?

Chris Wilson
Engineering Services Manager

Certified SolidWorks Professional
Certified Enterprise PDM Administrator

 

[JNieman]

"Runout to what?" is right.

Runout is a relational measurement that requires a datum.

 

[swertel]

I've seen this a lot. And "runout to what?" is exactly the problem.

In essence, it's runout to each other. So no matter where the inspector affixes the part to create the theoretical datum, everything else must then be relative to that. Give the same part to another inspector and he'll hold it a different way, resulting in a different set of runout measurements. What happens when one passes and another does not?

I know of nowhere in ASME Y14.5 that this note makes sense. While I have seen it often enough to say that it's almost common practice, I've never met anyone who knows what it means in terms of inspection. Basically, you might as well just place a note that says "Turn all cylindrical features on the same setup." It'll get you the same result, except now your machinist will be pissed at you instead of your inspector.

--Scott
www.wertel.pro

 

[JNieman]

Except it's quite possible that not all diameters /can/ be manufactured in the same setup, and it's quite possible that in doing so, your part may be /less/ accurately made.

Don't tell machinists how to make parts via the design drawing. That's worse than notes like "All features runout .005"

 

[KENAT]

Why not use the applicable note in ASME Y14.5M-1994 section 2.7.3 (c) or at least look to it for guidance.

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[CAD_Man]

So my note would say, "PERFECT COAXIALITY AT MMC REQUIRED FOR RELATED FEATURES"?

This might work!

Thanks KENAT!

Chris Wilson
Engineering Services Manager

Certified SolidWorks Professional
Certified Enterprise PDM Administrator

 

[powerhound]

My caution about the 2.7.3 note is that form is controlled only by the size tolerance. If you actually used runout then form could be controlled through its use depending on whether or not its value is higher or lower than the value of the size tolerance.

General notes like this should be fully understood before implementing them. You could get yourself in a mess and you'll be wishing you had just applied the right tolerance from the beginning.

John Acosta, GDTP Senior Level
Manufacturing Engineering Tech

 

[3DDave]

The original version is a feel-good note that does nothing. Pick the surface that orients and locates the mating part as the primary datum and go from there or ...

If these are repeated features, such as hydraulic valve ports, create a drawing of the ports and refer to that drawing for detail requirements. This is the same as not putting all the thread specs on a drawing, but instead referring to another document for tolerance details.

 

[pylfrm]

PERFECT COAXIALITY AT MMC REQUIRED FOR RELATED FEATURES

I realize this note is straight out of the standard, but it seems like a bad idea to me. It's still open to interpretation unless you somehow explicitly define which features are considered related. "RELATED FEATURE GROUP 1" or similar notes all over the place are hardly better than feature control frames.

You could perhaps apply a runout tolerance to multiple features as a flag note if you really want to save a tiny bit of space.


pylfrm

 

[geesamand]

My company has a ton of older drawings with notes that say "indicated features to run within .001" runout".

It was implied or understood that the way to do it was to set up on the bearing journals, as each rotating part had a reference note that mentioned the bearing code for each such journal.

Naturally, things that work when drafting and turning are in one building don't work in any other context. So we now handle those drawings but declaring one bearing journal A and the other B and letting all other controlled features run out against A-B.

 

[KENAT]

Don't have the standard in front of me right now but may want to consider tweaking the 'related' to 'diameters shown concentric' or change "features" to "diameters" or similar. I'd think diameters shown with common centerline could be readily interpreted as 'related'.[pre][/pre]

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[CAD_Man]

What if we started incorporating an overall profile tolerance? That seems to be the global solution for the Model Based Definition effort. Or would that not apply to 2D Drawings where 3D model is no supplied?

Chris Wilson
Engineering Services Manager

Certified SolidWorks Professional
Certified Enterprise PDM Administrator

 

[KENAT]

My guess is the wording would get messy & be hard not to conflict with directly dimensioned tolerances on size etc. even using the UoS type notes because I think you're only looking to control the coaxiality not size.

I think the important thing is to capture your functional requirement - which obviously may vary part to part.

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[Belanger]

What if we started incorporating an overall profile tolerance?

The hitch there is that profile must be applied to a "true profile." And a true profile is one defined by basic dimensions.
So a profile tolerance on the coaxial feature(s) would be controlling size as well as location. That's fine if you want it, but often the size and location are toleranced to different accuracies.

 

[JNieman]

Stepping away from the "by the book" definitions/requirements for a moment to discuss the practical effects most likely to occur, based on my own experience on both sides of the drawing and designing:

"PERFECT COAXIALITY AT MMC REQUIRED FOR RELATED FEATURES"...

Might be a little unusual, but would likely be understood and executed logically. If you're talking about precision components such as crankshafts, camshafts, and similar geometry, the tradesmen in the business of grinding such items will understand your part and very likely be able to deduce which features are related. You will likely endure a low level of risk among a supplier base that would prefer to keep their customers. If you're making things "in-house" your results may vary. Depends on work culture.

Ok, back onto the "by the book" discussion-

I understand the necessity of reducing redundant FCFs on the drawing, but I think the best way is to still make the callout to a datum cylinder. That's the only functional way to check it as others have explained in detail. You also eliminate all innocent mistakes, imo.

Then again, I kind of hate "U.N.O. F.C.F.s" more complicated than a simple form. These ambiguities are similar to the problems commonly experience with "Unless Otherwise Noted, all holes must conform to True Position w/in 0.030in" because... uh... from where? It's especially murky when model based and there's little indication of a DRF.

Anyways... I'm interested in the consensus of this topic.

 

[MikeHalloran]

It is occasionally of interest to eavesdrop on discussions amongst programmers who work in the language C, or its descendants, wherein a small piece of source code is dissected, with everyone postulating how the 'C preprocessor', a hoary old tiny piece of bug-ridden malignant code, will interpret the source, with endless conjecture and argument about how the resulting binary code will (mis)behave.

I am amused at the similarity to discussions amongst GD&T practitioners about how a particular set of symbology should be, or will be, interpreted in practice. We too often lose sight of the preprocessor's analog, an ordinary person working on the shop floor, who may or may not have much formal education, or even a few minutes of training in GD&T, and who is tasked with converting the symbology into a process for executing the design intent.

In an 'old school' environment, where the shop is making yet another variant of something they've been making for generations, a general note is sufficient, because everybody knows where the implied datums are, and how the noted features should relate to the datums.

In a 'new school' environment, where the shop is making something that no participant has seen or used before, and because of Supply Chain Management and other nefarious influences, has no opportunity to actually converse with the actual designer, GD&T becomes a useful lingua franca in which to encode and communicate the design intent, but because the communication is basically one-way and one-time, it's important to make the symbology clear and unambiguous, even to persons who don't live and breathe GD&T every day. That is a huge challenge to do, without 'talking down' to the intended audience.

The 'old school' way of making a drawing appear uncrowded is to transfer the image to a larger piece of paper and spread out the elements enough so that they don't confuse the reader. The 'new school' way is to use multiple A or B size sheets. I'd rather have everything related on one large sheet, but I recognize the modern practice of distribution by fax or small-format printer has made my preference impracticable. In no case is arbitrarily reducing the number of FCFs (below what is actually needed) a good thing.





Mike Halloran
Pembroke Pines, FL, USA

 

[3DDave]

Mike, the analogy is a pretty good one. The big difference is that each C compiler is definitive about what it accepts and one can investigate if the output is acting as desired. Discussing D&T is like people trying to convince each other what a C compiler might do because there isn't one. For any particular C compiler and pre-processor there is a definitive answer that is found by just using it.

What is more interesting about the difference is the guys who created C (Thanks Kernighan, Thomas, and Ritchie) had to create an actual implementation based on their language spec - each item in the spec had to have a use and a particular method of execution, unlike Y14.5 which has a lot of near magic thinking and 'you know what I mean, because it is obvious to me' hand waving.

 

[CAD_Man]

Could someone please explain where this thread is leading. I fee like I'm in the twilight zone!
What the heck is a C compiler, D&T, pre-processor, etc.? And what does it have to do with ASME Y14.5?
This is a discussion about DRAFTING not software code! Why are you mixing the two?

Chris Wilson
Engineering Services Manager

Certified SolidWorks Professional
Certified Enterprise PDM Administrator

 

[3DDave]

D&T (see Title of the 'Y14.5 document) is a symbolic programming language overlaid on a geometric representation that designers use to tell what part variations are acceptable. Each requirement is an 'IF' statement and the part is only acceptable if all of the results of the 'IF' statements are 'TRUE' Each symbol is a function that controls what sort of variations will be acceptable.

There are close parallels between the 'Y14.5 series of document versions and other programming languages. Understanding why programming languages** can result in predictable outcomes and how 'Y14.5 sometimes does not, should guide people into better understanding of how to improve 'Y14.5 given the lack of an impartial 'Y14.5 interpreter***.

It really should be less related to drafting, which is the menial task of making drawings, but since it appears on drawings it seems hopelessly inextricable. It is more closely allied with geometry, trigonometry, statistics, and stress/strain and other engineering analysis.

**(though not necessarily the programs they are used to create)

***There is one, developed by VSA, that handled a large subset of cases in a direct and understandable manner. It created C code that was compiled and executed to simulate the results one might get from a factory run of parts. One could examine the code to confirm it would do what the symbology indicated was acceptable. Now it's buried in Siemens under Tecnomatix. Since it was compiled, one could easily tie it to other software, such as combustion analysis software that would show the effects on combustion in engines as a result of engine component variations.

http://www.plm.automation.siemens.c...lity/variation-analysis.shtml#lightview-close

Too many think it is 'drafting' and don't care about the results.


As an aside - C is the programming language that most widely used operating systems are now or were originally built with (UNIX, Linux, and Windows, for example) and what a significant amount of the telecom and internet industry depends on. Solidworks was likely written in C or its successor C++. Its most endearing attribute is that it was developed as a tool by smart people who used the tool to develop UNIX. Most other languages were developed either as educational devices (BASIC, FORTH, PASCAL) or as utilities for others (FORTRAN, COBOL, VBA, JAVA) so their goals were different than the ones for creating C. In all cases the creators had to build software that demonstrated their interpretation of the rules.

ASME has not developed an interpreter so no one can see how they would interpret their rules for various situations, leaving users to make individualized guesses. People being people, they bring their own backgrounds, some more complete than others, to their interpretations. Without an unbiased interpreter that does not change it's opinion based on the background of a user, trying to use 'Y14.5 can result in very different opinions of the likely results and very different sets of parts produced and accepted to a single set of requirements.

 

[mkcski]

Thanks to all who contributed to this fantastic philosophical discussion. It confirms my "thinking" about GD&T after over 35 years of applying and interpreting the symbols. The goal is one interpretation but the reality is much more practical and dependent on many factors.

Certified Sr. GD&T Professional