Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X
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:
Some specific concerns:
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
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