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

Instance is the Master - ideas on Modeling ModelManager integration

Instance is the Master - ideas on Modeling ModelManager integration

This idea on the integration of Modeling and Model Manager is something i send to CoCreate in 2004. Reading product idea 1061 i thougt it might be useful to add it here as a product idea.

We have a company wide multidisciplinary PLM system that is used for interdisciplinary communication and for the release process to the production departments. Besides that we need a database (lets call it Model Manager, MM) that is tightly integrated with the mechanical design tools (OneSpace designer modeling/Annotation). Part (article) structure is managed in the PLM system. The design structure is managed in ModelManager. In the design phase of a project the mechanical engineer only deals with ModelManager. This memo describes some of our ideas on the OneSpace Designer – Model Manager integration.

The idea is that we need a kind of BOM in the design environment. However, it should be as simple as possible. We need something like masterdata to keep information like material etc. However we don’t want the extra overhead of masterdata structure.

Lets look at this example

19-9-2012 13-13-17.png 

This results in the following 3D model / masterdata structure

19-9-2012 13-23-30.png

A drawing of this assy should look like this

19-9-2012 13-25-30.png

What we would like to see here is not the 3D model structure, but the 3D instance structure!

In fact, the masterdata of a button is a representation of one instance of the button.

Another example:

When I search the red button in Masterdata (154), I find that the 3D model 123 is related to it. When I load the 3D model of this red button, I get a button in a grey color (because that was the base color of the contents). However, when I inquire this button in OneSpace designer, this still leads to the red masterdata.

Discussing about this behaviour the idea rose that the instance information of the color (RGBCOLOR x,x,x) should be passed to the masterdata in MM. When the 3D model of this masterdata is loaded, the color information should be passed back to the OneSpace Designer Modeling. This could be done also for an attribute like material. A material in the master data leads to a density in OneSpace Modeling.

Why not map the masterdata and the instance information one-to-one? Don’t store the instance information  in the owning assy, but store it as a separate object in MM. For design BOM purposes this instance structure would suffice. It could be one-to-one with the OneSpace Modeling instance structure. I don’t need to manage a separate masterdata structure.


1 Comment
PeterKehoe
Regular Member

If I understand what you are asking for, you will need a way to specify whether a given instance should be an instance of an existing part or a new part. In your example, there are 3 instances of your button. You would need to specify that the 2 green buttons are really the same part (use the same Masterdata), but the the red button requires a separate Masterdata. This seems like it would be tricky to do such that it will be easy to understand. It's possible you could use the instance color, like in your example, as a way to do that, but it doesn't seem like a good solution in general because many people use instance color for other purposes (like being able to differentiate parts that are close together)-relying on color to automatically differentiate could cause problems.

Have you tried using the BOM module in ModelManager? It has been a while since I used it, but it might have the ability to get a Masterdata relationship they way you want.