Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TugboatEng on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
Another Angled Hole Positional Tolerance Question 4
- Thread starter R1chJC
- Start date
CheckerHater
Mechanical
This domino effect of interpretations is exactly what I meant when considered "before" more ambiguous than "after".
"For every expert there is an equal and opposite expert"
Arthur C. Clarke Profiles of the future
But maybe they are away from the surface? And that's why we need the basic angle? Too many things are left to be implied.3DDave said:
"For every expert there is an equal and opposite expert"
Arthur C. Clarke Profiles of the future
3DDave said:
Thats a good point - I would think probably either fully define the surface first and then give just the y-dimension for the holes or define the surface fully with the x/y dimension for both holes. However if you have more than two holes you would have to only give the x-dimension for 2 of them to prevent redundancy. Regardless I wouldn't go with that method anyway if I didn't have to.
3DDave said:
Is what you're describing similar to the below snapshot from my attachment in a previous comment? This is the method that I found in the Y14.5 standard Figure 7-36.
CH has pointed out that I may have made an error in the way I applied dimensions in at least one of my examples, so take the below with a grain of salt - however he didn't point out exactly what the issue was so I'm not sure if it applies to the portion I have a snapshot of below, if it does and invalidates what I'm saying I apologize. I kindof quickly drew it up but at least I thought it communicated the point I was trying to make - maybe not.
EDIT: I think I figured out the issue he had with my dimensions. I see that everything (size dim/position tol/basic dims) were applied on a side view with construction/hidden lines instead of either a section view or at least the size dimension on a projected view normal to the top face. I don't think that invalidates my point but I can re-upload a sketch if necessary.. I am obviously still learning and it is good to get this kind of feedback so I don't keep making the same mistakes.
R1chJC said:
I'm not sure if some people here will agree with me, but I think it mainly comes down to trying to figure out the best way to communicate the dimensions/constraints in a drawing with the least likelihood of them being misinterpreted. I agree with Evan in that I don't think most of the methods presented are outright wrong, as long as enough dimensions are provided to fully constrain/define the features it should not matter however there are certain methods over others that lead to less confusion and less effort to discern the important information - ie: where exactly a hole axis lies in relation to the DRF.
I would wholeheartedly agree - there are many times in which the standard is unclear or ambiguous which is what leads to discussions like these. I don't know that the standard is ambiguous in this case though, so much as doesn't explicitly state or show an example that defines the "before" method as wrong and the "after" method as correct as Drake claims.
-
3
- #44
R1chJC,
Read at your own risk:
I have found a basic reason and a larger number of subtle reasons for the problem of disagreement.
The basic reason is that application of dimensioning and FCFs is effectively writing a program which is intended to predict/restrict a range of outputs. Understanding how to get a single answer out is tough enough, but there aren't many computer functions the typical person deals with that return sets of answers. In ordinary programming a programmer turns over the interpretation of the program to a computer and the computer does its thing and doesn't really have an opinion. Either the results are as expected or the user changes their program.
Within the limits of computational machinery, any computer given the same program will produce the same outputs. People aren't built that way. They bring a bunch of preconceptions and misunderstandings and when you give a bunch of them the same inputs they are likely to produce different outputs.
This is made worse because the interpretation training that people get, unlike the photo-masks that Intel and AMD and others use for their CPUs and the carefully built compilers and OS's, is done person-to-person. If you've experienced the 'Telephone Game,' where a story is whispered from one person to another, you can see the flaws can gather really rapidly. The ideal would be to go back to the standard, Y14.5 for example, but that standard is not written to educate via examples of correct and incorrect applications; it contains flat statements that aren't easily extensible.
Most of the subtleties come in via that 'Telephone Game' training. Certainly someone misheard something back when they were exposed to the -1982 version and have not only applied it ever since, but taught a couple of generations the same wrong thing. And some of those who have tried to reconcile with the writing and get rebuked for their effort.
The best answer for training I have come across was using VSA software which generated programming code to represent the effects of the FCFs and ran it through a random number generator to create compliant, varied results just like a factory would; however it depended on the pre-digestion of the dimensioning scheme to produce the nominal geometry. Since dimensioning schemes are used to communicate between humans more than being necessary for computation, this problem will be subject to human interpretation problems. When I write best I mean, because I didn't pay for it. In fact I got paid very well to spend most of a year doing nothing but using it; to the point that I learned that most problems in dimensioning and tolerancing are from the 'Telephone Game' training and a healthy dose of wishful thinking, not some underlying mystery of how to use trigonometry.
I have found the schemes I like best (note the word 'like') are ones where the values are easily recognized on one part as matching the dimensions on mating features on mating parts. The more difficult it is to verify that parts nominally fit together, the more likely the chance they won't. Such schemes sometimes require trigonometry to convert to the use of tools such as height gages, so inspectors often weigh in with their preferences based on the tools they have. Without a mating part then I fall back to liking the shortest path to the referenced datums; there are usually several equivalent schemes and choosing is a matter of previous (often unhappy) experience and avoiding a repeat.
One engineer decided that all holes in a beam (about 500 inches overall) should be baseline dimensioned, even though there were multiple patterns of holes. Of the ten patterns, he misplaced holes in five or six of them. Had they been dimensioned locally with a dimension from the baseline to the center of each pattern the mismatched holes would be instantly noticeable. Since there were hundreds of holes, it cost a large amount of time to go hole-by-hole to find the ones that didn't match.
Getting back to the software concept. Most programming could be done with binary switches loading individual instructions. Programming languages were developed in order to make what is supposed to happen more obvious to other programmers; the computers don't care. And even in programming, there are plenty of programmers who write working programs that are convoluted and excessively complex and hide or lose track of the fundamental method being expressed and produce undesirable results. It's small wonder the same happens on drawings.
Best of luck.
Read at your own risk:
I have found a basic reason and a larger number of subtle reasons for the problem of disagreement.
The basic reason is that application of dimensioning and FCFs is effectively writing a program which is intended to predict/restrict a range of outputs. Understanding how to get a single answer out is tough enough, but there aren't many computer functions the typical person deals with that return sets of answers. In ordinary programming a programmer turns over the interpretation of the program to a computer and the computer does its thing and doesn't really have an opinion. Either the results are as expected or the user changes their program.
Within the limits of computational machinery, any computer given the same program will produce the same outputs. People aren't built that way. They bring a bunch of preconceptions and misunderstandings and when you give a bunch of them the same inputs they are likely to produce different outputs.
This is made worse because the interpretation training that people get, unlike the photo-masks that Intel and AMD and others use for their CPUs and the carefully built compilers and OS's, is done person-to-person. If you've experienced the 'Telephone Game,' where a story is whispered from one person to another, you can see the flaws can gather really rapidly. The ideal would be to go back to the standard, Y14.5 for example, but that standard is not written to educate via examples of correct and incorrect applications; it contains flat statements that aren't easily extensible.
Most of the subtleties come in via that 'Telephone Game' training. Certainly someone misheard something back when they were exposed to the -1982 version and have not only applied it ever since, but taught a couple of generations the same wrong thing. And some of those who have tried to reconcile with the writing and get rebuked for their effort.
The best answer for training I have come across was using VSA software which generated programming code to represent the effects of the FCFs and ran it through a random number generator to create compliant, varied results just like a factory would; however it depended on the pre-digestion of the dimensioning scheme to produce the nominal geometry. Since dimensioning schemes are used to communicate between humans more than being necessary for computation, this problem will be subject to human interpretation problems. When I write best I mean, because I didn't pay for it. In fact I got paid very well to spend most of a year doing nothing but using it; to the point that I learned that most problems in dimensioning and tolerancing are from the 'Telephone Game' training and a healthy dose of wishful thinking, not some underlying mystery of how to use trigonometry.
I have found the schemes I like best (note the word 'like') are ones where the values are easily recognized on one part as matching the dimensions on mating features on mating parts. The more difficult it is to verify that parts nominally fit together, the more likely the chance they won't. Such schemes sometimes require trigonometry to convert to the use of tools such as height gages, so inspectors often weigh in with their preferences based on the tools they have. Without a mating part then I fall back to liking the shortest path to the referenced datums; there are usually several equivalent schemes and choosing is a matter of previous (often unhappy) experience and avoiding a repeat.
One engineer decided that all holes in a beam (about 500 inches overall) should be baseline dimensioned, even though there were multiple patterns of holes. Of the ten patterns, he misplaced holes in five or six of them. Had they been dimensioned locally with a dimension from the baseline to the center of each pattern the mismatched holes would be instantly noticeable. Since there were hundreds of holes, it cost a large amount of time to go hole-by-hole to find the ones that didn't match.
Getting back to the software concept. Most programming could be done with binary switches loading individual instructions. Programming languages were developed in order to make what is supposed to happen more obvious to other programmers; the computers don't care. And even in programming, there are plenty of programmers who write working programs that are convoluted and excessively complex and hide or lose track of the fundamental method being expressed and produce undesirable results. It's small wonder the same happens on drawings.
Best of luck.
3DDave - I did not mean to say that was the actual figure, thats why I said "per Y14.5 Fig 7-36" as in trying to dimension it with the same method.
See attached for the actual figure from the standard. Sorry if that created any confusion, that was not my intent.
See attached for the actual figure from the standard. Sorry if that created any confusion, that was not my intent.
Also 3DDave I have to commend you on that explanation, that was a very well thought out response and included everything and so much more that I was trying to communicate (albeit poorly) in my previous posts - the computer/programming analogy works very well in contrast to the the myriad of issues that arise when humans create and interpret drawings.
Ultimately there will always be issues and misinterpretations, however it is good to strive towards methods of reducing the possibilities of these issues. Now if only we could agree on what those methods are.... haha!
Ultimately there will always be issues and misinterpretations, however it is good to strive towards methods of reducing the possibilities of these issues. Now if only we could agree on what those methods are.... haha!
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question
