cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you know you can set a signature that will be added to all your posts? Set it here! X

Model-based definition to eliminate 2D drawings - Y14.41

gchampoux
1-Newbie

Model-based definition to eliminate 2D drawings - Y14.41

Has anyone implemented model-based definition (MBD) by Y14.41 (or some other standard) with the goal of eliminating 2D drawings?
Sometimes call "3D drawings".


I have asked this question some time back, but did not get any response that indicated success.


I have had doubts about the practicality of MBD.
If you have implemented MBD, how did it allow your company to:



  • Reduce errors?

  • Quicken the development cycle?

  • Reduce cost?


Some specific concerns:



  1. Ho do we defining non-geometric information in Pro/E, such as general notes & revision history.
    Making them all 3D notes would be ugly.

  2. How do we segregate what the recipient needs to know vs. what is available in the model.
    (design intent & construction features).

  3. How do we deliver to non-Pro/E users, such as management or low-end shop-floor PC's?
    Is there a 3D file type can display all the MBD information, including notes, dimensions, GD&T, etc.? (not just geometry)

  4. How do we document models that deviate from reality?
    Sometimes, reality is not possible or practical because due to Pro/E or user limitations.
    On a 2D drawing, we can call-out whatever we want, regardless of how the feature was actually modeled.

Even if all the above are addressed, my basic concern is this:
A 2D drawing tells the recipient what he NEEDS to know.
An MBD tells the recipient that all the information is available in the model.
How is that better?


Gerry


This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.
10 REPLIES 10

I don't think all of the tools are readily available yet.



Based on my experiences (dealing with MBD in CATIA format from our
customers)



1) Non-geometric information (attribute info) is added as notes to the
model tree. To be sure we have been alerted to all of the attribute
data we have a small program that will 'slurp' all of the attribute data
from the model, and 'belch' the results into an Excel spreadsheet.



2) Design intent is based on extensive use of GD&T definitions. You
have to be very comfortable with using GD&T for everything. Having the
GD&T symbol highlight the surface, line, etc... where it is applied is
essential to understand the scope of the requirement. I don't
understand the question about construction features, although range of
motion, etc... issues can be shown as 2D sketches, with the added notes
in the tree. Testing requirements, tensile test locations, etc are
shown in zones, like keep in / keep out definition in Pro-E



3) For production workers, we create in-house documentation that
distills the needed info in a compact format. 2D drawings (in PDF
format) are used. For tooling and fixturing work, we create 3D STEP
files for use by outside vendors, and then create a 2D .pdf files for
illustration of critical features and GD&T requirements. The drawing is
not a complete definition, and requires the 3D model for many details of
the geometry. As a nice benefit, all of our documentation is reduced to
'A' sized sheets. Easier to print, and easier to store.



4) No models used are allowed to be released that deviate from
requirements. The model has to be constructed to meet the requirements,
or the requirements are modified to meet the model. The exception to
this may be very small fastener features on large parts like rivets
holes, etc... In this case the features can be shown schematically as a
point location, with a note relating back to a specification that
describes the condition of the feature.



Now 'design intent' with regard to hole locations, etc... where the
construction may have been mirrored from a central plane, but the
drawing may show dimensions coming from a edge is eliminated. No
location dimensions are shown for holes, only the true position location
to the appropriate datums in the model. Datum callouts, whether point,
zone, or surface must be visible on the model.



I agree that 2D drawings were not just a mechanical document, but also
told a 'story' of the part, what was important, and how to manufacture
the component. This is the toughest thing I see to implement. A CMM
working off of the MBD may close this loop and be a check and balance to
manufacturing although the designer and inspector may still disagree,
their conversation is driven higher up the 'food chain'.(which is a good
thing) I don't see how manual inspection is feasible in most cases
without very deep inspection of the MBD, and/or supplemental 2D
documents.



In my opinion, for MBD to work your downstream users of design
information must have very good tools to interpret the MBD, and these
people need the most training and collaboration. It is also essential
that the machine operators and the part inspectors be two different and
uninfluenced groups. I don't see how the part can be inspected in the
machine it was made on, but this is a topic for a different discussion.



Can MBD reduce cost? I believe so. Much like Philip Crosby's mantra of
'Quality if Free' is true, if you are strong enough and clever enough to
use this tool to best advantage.



Theoretically, MBD will reduce errors, but like all things, requires the
organization to be transformed. Some type of document control and
access system seems to be mandatory, and the review and markup tools,
(in my opinion) still need work. For one-off tooling and fixturing, I
would hope that STEP-NC (or similar) would take off allowing the design
to be reviewed and programmed at the machine tool, if the proper GD&T
information can be embedded in the STEP file.







Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317

Thank you for your insight!



Gerry


TimKnier
4-Participant
(To:gchampoux)

In the past there has been raging debates in this forum about created vs. shown dimensions on drawings. With the elimination of 2D drawings does this now become a non-issue? Or does this open up a whole other can o' worms. With top down design or even bad modeling practices, created dimensions in drawings allowed people to get around this and let them show the dimension scheme they wanted. Now with no drawings are they going to have to go back and redefine features to get the correct dimension scheme? What about external references from a feature in one part to a feature in another part. Where will the dimensions show up for those? Seems like right now there are more questions than answers.

Tim Knier
QG Product & Support Engineering
QuadTech
A Subsidiary of Quad/Graphics
Sussex, Wisconsin
414-566-7439 phone
-<">mailto:->
www.quadtechworld.com<">http://www.quadtechworld.com>

There is no dimension location scheme, only a datum reference frame, a
form tolerance and a position tolerance.



Now, dimensioning the hole size tolerance that influences the true
position at MMC must be called out in a note describing the feature.



Based on the definition for other features of size, I could possibly see
the hole diameter dimension going away, with profile of form of the hole
feature replacing diameter dimensions for holes. These profile of form
tolerances will then influence the amount of 'bonus' tolerance you get
at MMC. This is not done now, that I know of.



I could see the same happening for key slots, where now you might have a
width size and tolerance, with the slot modified by a position tolerance
to some set of datums be replaced by a basic slot feature with a profile
of form tolerance that is modified by a true position tolerance to a
datum reference frame.



For top down design or bottom up, there should be no more dimensions for
location, just the 3D model definition and a GD&T form and/or location
tolerance to the appropriate datums. One thing I don't see a lot of
now is a projected tolerance zone used for hole true position,
especially dowel holes for location. I expect that this will be used
more often with MBD.



Think of it this way. I design forgings. Classically, you would have
length and width tolerances, thickness tolerances, flatness and
straightness tolerances, flash extension allowance, etc... all that may
be applied in compounding ways. Look at ASME Y14.8. Allowing for
cleanup stock for the extremes of all of these conditions adds weight to
the part.



With MBD, you define the model, and then roll all of the model variation
allowed into one or more profile tolerances, regardless of the source of
variation. Just like in true position, if you want to use more
thickness tolerance, you will have less left over for straightness,
etc...



As a consequence, you must model the expected ejector mark, and trim
flash extension on the part, so that these features are accounted for.
This also gives your customer a more realistic model of the actual
condition to expect for the parts delivered. Should be less surprises
for the NC programmer who expects the model to fall within a given
envelope so that his approach cuts don't hit anything.



In process, your forgers (or casters, etc...) will still have classic
dimensions to use for spot checks for the sources of process variation,
once the process is shown to be in control. But it is more likely that
a CMM inspection of form of the entire part will be done periodically to
verify conformance, along with more tooling inspections to ensure
conformity.





Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317

Hi Gerry,

We did a partial move in that direction and to some extent it did achieve your three goals for us: Reduce errors, Quicken the development cycle, Reduce cost.

Our 2D drawings are associated with a 3D model (STEP) for complete product definition. The STEP contains all the geometry and the 2D drawing contains everything else the recipient needs to know.


Eventually the community needs to come up with a file format that contains both forms of information (2D & 3D) and is also machine readable.

Current 2D drawings have a very serious drawback in that all data contained on them must be passed through a human being - In via their eyes and out via their fingertips on a keyboard.

The ideal format would contain:


* Standard fields for everything (tolerances, materials, processes, parts lists, notes, etc...) that we currently put on the 2D drawing so that they could be read by a machine rather than transcribed by a human.

* A viewer application that would allow a user to view all that embedded data in a user friendly form that resembles a 2D drawing.

* Selecting different views might display different portions of the embedded data that are customized to the needs of each end user's role.

* This format would have to be an Open Standard (like PDF) to be useful for everyone - Proprietary standards could not achieve the widespread application needed to get everyone on the same page.

Mike Foster


You will never get rid of the human element. Everybody does things differently, and that will never, ever change. Much of the information is the same, yes, but the very nature of the parts you work with are frequently vastly different from other parts that other companies work with, and that's why we have different companies doing different things. It may be possible to create a universal modeling standard, but a universal way of handling database information? I don't think so. Even Windchill has to be customizable to be useful.

A few years ago my company decided to take BOM's off drawings and make them part of a separate database. I think it was tied to the MRP system. One database to manage, always the master, don't worry about syncing drawings, the information is always accurate and everyone reads the same information from the same place. Sounds good. What happened? The first thing that happened was the BOM's were no longer on the drawing, so anyone who wanted to look at a BOM had to 1. Pull up the drawing, 2. Pull up the BOM (after looking for it), 3. Wonder where the part was that used to be on the drawing BOM but wasn't on the master BOM. Yes, you can manage that separate database, but now you have a separate DB management function that used to be handled by the engineers who knew what the parts were supposed to be. The second thing that happened was the engineers got lazy. All the master information was in the master DB, so why worry about keeping the model up? Hey, I'm in a hurry to get this done and they're not going to use the model info anyway, so why bother?

So people who used the BOM information had to go through extra steps to get the BOM info they needed, didn't know if it was accurate, and the models got sloppy. It seems to me that if we left the BOM's on the drawing, and made it a policy to use the comparison between the two to check the database, you could be sure the models and the master DB were accurate, and it would force the engineers to make the models properly and keep them up to date..

When you make everything automatic and machine-based, people get lazy. It may work well most of the time, but there is always a situation that requires human intervention sooner or later. The question is not how to eliminate human intervention, but how to minimize human intervention with maximal productivity when it's needed, and how to keep the DB information accurate at the same time.

You will never eliminate the human element. We do what we do to help people ultimately, right? Human beings are going to use and benefit from what we generate. It would be nice to have all the information in the model and have some program automatically read it and automatically check the part and automatically plop all that information in the right place, but sooner or later in that process, a HUMAN BEING is going to analyze that information. When lots of things go automatic, the possibility of massive screw-ups increases, and they'll very likely bite you in the butt before you know you've been bit. When the mistake happens, someBODY is going to spend hours or days analyzing the problem and trying to figure it out.

It's OK to automate things, but you better have a top-notch, well-disciplined checking function to make certain your information is accurate. And that requires a human being. I'm still voting for drawings, because they're universally understood and they put all the critical information in one place. I'll concede that some model data makes sense to leave in the model, but the drawing should point to it.

Ken Sauter

Just wanted to chime in with my two cents on the topic du jour (for the past two or three decades - LOL)...


For the folk that asked about shown vs created dimensions, this new paradigm doesn't change that arguement in the slightest. To follow the new MBD paradigm (all the cool kids are doing it!), you now CREATE dimensions in 3D via annotation features. In other words, nearly all my design intent is driven via the skeleton (master) model. Therefore, very, very few (if any) driven dimensions are available to show (in 3D, or for that matter 2D). Besides, my design intent is almost never the way I want my individual part to be inspected (or even more important, toleranced) anyways, so I have ALWAYS used created dimensions.


Cheers!



In Reply to Kenneth Sauter:



You will never get rid of the human element. Everybody does things differently, and that will never, ever change. Much of the information is the same, yes, but the very nature of the parts you work with are frequently vastly different from other parts that other companies work with, and that's why we have different companies doing different things. It may be possible to create a universal modeling standard, but a universal way of handling database information? I don't think so. Even Windchill has to be customizable to be useful.

A few years ago my company decided to take BOM's off drawings and make them part of a separate database. I think it was tied to the MRP system. One database to manage, always the master, don't worry about syncing drawings, the information is always accurate and everyone reads the same information from the same place. Sounds good. What happened? The first thing that happened was the BOM's were no longer on the drawing, so anyone who wanted to look at a BOM had to 1. Pull up the drawing, 2. Pull up the BOM (after looking for it), 3. Wonder where the part was that used to be on the drawing BOM but wasn't on the master BOM. Yes, you can manage that separate database, but now you have a separate DB management function that used to be handled by the engineers who knew what the parts were supposed to be. The second thing that happened was the engineers got lazy. All the master information was in the master DB, so why worry about keeping the model up? Hey, I'm in a hurry to get this done and they're not going to use the model info anyway, so why bother?

So people who used the BOM information had to go through extra steps to get the BOM info they needed, didn't know if it was accurate, and the models got sloppy. It seems to me that if we left the BOM's on the drawing, and made it a policy to use the comparison between the two to check the database, you could be sure the models and the master DB were accurate, and it would force the engineers to make the models properly and keep them up to date..

When you make everything automatic and machine-based, people get lazy. It may work well most of the time, but there is always a situation that requires human intervention sooner or later. The question is not how to eliminate human intervention, but how to minimize human intervention with maximal productivity when it's needed, and how to keep the DB information accurate at the same time.

You will never eliminate the human element. We do what we do to help people ultimately, right? Human beings are going to use and benefit from what we generate. It would be nice to have all the information in the model and have some program automatically read it and automatically check the part and automatically plop all that information in the right place, but sooner or later in that process, a HUMAN BEING is going to analyze that information. When lots of things go automatic, the possibility of massive screw-ups increases, and they'll very likely bite you in the butt before you know you've been bit. When the mistake happens, someBODY is going to spend hours or days analyzing the problem and trying to figure it out.

It's OK to automate things, but you better have a top-notch, well-disciplined checking function to make certain your information is accurate. And that requires a human being. I'm still voting for drawings, because they're universally understood and they put all the critical information in one place. I'll concede that some model data makes sense to leave in the model, but the drawing should point to it.

Ken Sauter

Hi Gerry,


I saw this note for a couple years ago. Did you ever make any progress toward implementing Model-Based Definition? I am looking into it now and was curious what your conclusion was.


Thanks!


-----------------------------------------------------------------


Greg Kemner


Lead Mechanical Engineer


CAD Systems Administrator


Northrop Grumman


Cutting Edge Optronics

I was hoping to find presentations at PTC Live that might help me justify attending.-


So far no comments on my response to a post on this subject:



http://portal.ptcuser.org/p/fo/st/topic=3&post=122776#p122776


x

Top Tags