GD&T Reference Book

[illini8181]

I work for a company which uses GD&T widely, but provides no GD&T training. I would like to do some learning on my own. Are there any books/resources that anyone would recommend for someone with a beginner/intermediate knowledge of GD&T? I of course have a copy of the standard and read through it regularly, but something with more examples and explanation would be helpful.
The best way for me to enhance my understanding of GD&T is probably simply to use it. However, GD&T makes up only about 20% of my job responsibilities, and I will often go weeks without needing to use it. Because I am not using it on a daily basis, I think I need another resource to deepen my understanding of GD&T. My plan is to get a book and spend 20-30 min reading it and doing example problems every day, providing daily exposure to GD&T.
On an older thread I saw “GD&T Application and Interpretation” by Wilson, “Fundamentals of Geometric Dimensioning and Tolerancing” by Krulikowski, and a book put out by Tec-Ease recommended. Is there anyone out there who has used any of these resources (or a different resource) and would say that the book they used significantly improved their ability to apply GD&T?

 

[CoryPad]

The Krulikowski book and the associated exercise workbook are excellent. I can state that they definitely improved my ability to apply GD&T in my work.

http://www.etinews.com/index.html

 

[3DDave]

Check Bryan R. Fischer at

http://www.advanceddimensionalmanagement.com,

who has done some very impressive work.

As to learning: It isn't easy. Approach the effort cautiously.

This is because D&T is essentially a programming language for 2D and 3D geometric variation. Mostly people stink at writing programs. It isn't that they are especially stupid, but that there is often a lack of correspondence between what people expect will happen and what does happen. If there wasn't, compilers needn't check for errors in code and software would never have problems and computers (and cars) would never crash.

Just like learning any programming language:
1) understand exactly what the symbols mean
2) become expert at analyzing the results of existing usages
3) generate new usages

It's that second step that is the tough one. It is difficult because the number of worked examples is limited and the majority of examples will be for configurations that are carefully constructed to work correctly, which does nothing to teach how these configurations came about. It is also easy to believe a written explanation that does not reflect what the symbols actually mean, leading to misunderstanding. Many people get stuck thinking they understand, while understanding only a special case or getting it completely wrong.

2*2 = 2+2, therefore "*" is the same as "+"? That kind of thing, especially with regards to using feature-of-size (FOS)references as datum references in feature control frames or using FOS references in combination with datum references they are disconnected from.

Considered correctly, D&T is trivially easy, but getting to that point is often very hard.

 

[illini8181]

Wow 3DDave, your post is very insightful! "It is difficult, because the number of worked examples is limited and the majority of examples will be for configurations that are carefully constructed to work correctly, which does nothing to teach how these configurations came about." - so true! My company has certain cases that we always use, and I am comfortable in using those cases, but it is definitely a mistake to think that I understand them inside and out. Also, the more I understand GD&T, the more I wonder whether there is a better way for us to do things. I could be wrong - our current methods could be the very best way to do them - but I believe that I should have that conviction based upon my own knowledge of GD&T.

CoryPad, thanks for the recommendation!

 

[3DDave]

If you start with two ideas you will do well:

1) The point of a drawing is distinguish parts/assemblies that will function from those that won't
2) There may be multiple ways of describing very similar outcomes

Some say a drawing records design intent, which is saying it records what someone intended. Not many people create a drawing with the intent of creating a failed product, though they do. I like to keep intent for feelings. Instead, a drawing records a possible solution to the problem of separating the usable from the unusable, which is made difficult because the border is not always as firm as one would like. Some solutions are good, some not.

Some problems are trivial, such as making certain that holes in a part to allow screws through actually do so. Others are complicated, such as making sure that there is enough clearance in a hydraulic valve to still operate even during transient thermal events.

Many solutions are possible. Look at the number of clothes hanger designs. That's just to perform the task of providing a hook and support. Most of them work ok, so some other scheme is required to choose among them. You can't just look at the hanger drawing alone. Factors off the drawing will be required for decision. Try to evaluate the likely outcomes to ensure the solutions are reliable and then evaluate the cost of those solutions. Be aware that some people refuse to do the work and will try to cover their inaction with bluster. Don't care so much about a solution you have if there's another that is as good that costs less. That cost may change, needing a different solution.