If you’re around NX for very long you’ll hear someone talk about the Master Model concept. It is an important concept. It comes up in the various forums from time to time. Usually when people as,
What is the master model concept? There are no shortage of answers offered. But I feel that most of the discussions miss the mark. I think there are a lot of misconceptions about the Master Model Concept. I am going to try to clear some of them up.
Master Model Definition
If I’m going to discuss what people get wrong about the Master Model Concept, I should at least try to provide a definition of what it is. Here is how I define it
Master Model Concept:
A method of separating a CAD model definition from data which is dependent upon the CAD model but does not define the CAD model itself. This separation is achieved by storing the CAD model definition, called a Master Model, within one file and each piece of dependent data within separate files which refer to the Master Model, typically by including it as a component within themselves. Typical examples of dependent data types are drawings, machining tool path definitions, and FEA analyses.
Now, on to the misconceptions.
Master Model Misconceptions
These are the misconceptions that I feel people have.
1. The Master Model Concept is Only for Drawings
Drawings are the first place most of us encounter the MMC. Unfortunatley many people think this is all the MMC is about. In the early days of Unigraphics, there was but one file, and it contained your geometry and your drawing. Then UG gave us the ability to create assemblies. Soon someone figured out that you could the geometry in one file and the drawing in another. And then the word spread that drawings did not have to be embedded into the same file as the model.
But that’s not the only thing you can do use MMC for. You can have a separate file for your manufacturing tool path information too. And another file for your FEA analyses. Any type of work you need to do that is driven by the model but does not influence the model can (and should!) be broken out into a separate file that references the master model.
2. The Master Model Concept is about reducing file sizes
The second misconception I hear is that the main benefit of MMC is that it reduces your file sizes. Drawings and tool paths and FEA meshes can be consume a lot disk space, so by separating them out from the model file you make your models easier to work with.
That is a benefit. I agree with that.
I just don’t think it’s the primary benefit.
I think the primary benefit is that MMC decouples your model file from your drawings, machining files, and analysis models.
Decoupling is a word that is used in software engineering fairl regularly. However, if it’s used in terms of CAD modeling, I’ve not heard it. Decoupling means to take a system and divide it into logical self-contained units which share only what they need to share with each other through well defined channels. For example, drawings do not need to know the model tree for the geometry. It makes no difference if that hole was created with a feature or by extruding a sketch. All the drawing needs to see are the faces and the edges. Likewise, the model does not need to know that the drawing even exists.
So here’s another point about MMC:
The flow of information in MMC is from the master model and to the dependent files.
So, why is this A Good Thing?
Protecting model integrity
No, I’m not talking about protecting the reputations of Victoria’s Secret models. I mean that there is nothing you can do to the drawing, tool paths, or FEA analyses that will damage the master model.
If you had everything in one file, could you be sure that you wouldn’t inadvertently make an unintended change to the model when you were only supposed to be updating the drawing?
Parallel work efforts
A second benefit of decoupling the model from the dependent files is that you can now divide the work effort into parallel tracks. One person can be working the model while another starts on the drawing and a third begins to prepare the tool paths.
Separate life cycles
Since the model and drawing and machining and analysis files are separate they can be submitted to different workflows for review and release. The engineering group can review the model, the drafting group can review the drawing, manufacturing, the tool paths, etc.
The different files can be revised independently. A change to a note on the drawing does not require the model to be changed. Nor does a new analyses. And changes to the model that do not affect the other files do not require them to be updated. For example, there’s no reason to update a tool path because someone added a new reference set to the model.
3. In Teamcenter the Dependent Models Must be Manifestations
standard implementation of Teamcenter puts the master model in a UGMASTER dataset that is attached to a item revision with a Specification relationship. Then, additional datasets for the other models, like the drawing, are put in UGPART datasets that are attached to the same item revision but with a Manifestation relationship. Some people seem to think that this is what MMC has to look like in Teamcenter. But there are other solutions. For example, the drawing could be in its own item revision under a different item. For more on this topic, see this post on different ways of storing drawings in Teamcenter
If anyone knows the history of who first came up with the master model concept, please share. (Paging John Baker…)
I endorse using the MMC for all files. I know that some people feel that for really simple models that the drawing should be embedded in the model file. Personally, I feel it’s better to just consistently use one approach. If you’re going to use MMC in some cases (and you should), just use it in all cases.
Watch out for the WAVE
Interpart relationships, particularly WAVE relations, can turn the MMC upside down. Watch out for any relationship that makes a master model dependent on something that happens in the derivative file(s).
Have I missed any misconceptions? Do you disagree with my choices? Leave a comment, below.
Was this useful?
If so, please share, and endorse (+1, Like, etc.) on your social network of choice.
If you feel I’m mistaken about or missing something, pleas share your thoughts in the comments.