Modeling Same parts - but with

[vmcdaniel]

Like many of you we create items/part numbers (PN) with the same geometry but in a different color/material. What we would like is

I think there are four ways to do this.

1. Family Table

2. Stand-Alone parts

3. Inheritance/Merge/CopyGeom (Same relationship structure)

4. Assemblies

Family Tables, used in the past, are out because of our regimented change control process.
Stand-alone parts are no fun, having to change multiple models for the same geometry change, and which one gets sent to the toolmaker?
Maybe having a general/master .prt and then add that into an assembly to make the PN, this takes care of mass geometry changes, and clears up which one drive the tooling, but now there is a part model that gets no PN, thus could be out of control and assemblies where they are not needed.
Inheritance/Merge/CopyGeom seems good, no assembly structure, mass geom. update is easy. It is an advanced feature, so could confuse some users.

In your experience what are the downfalls of any of these methods? Which do you use? I'm just looking for that burn that I don't see.
Thanks for your comments.

WF3.0, soon to be 5.0
Ilink 3.x soon to be Windchill 9.1

Vaughn McDaniel III | CAD/PLM Administrator | Kärcher NA - Englewood |303-762-1800x187 |vaughn.mcdaniel@karcherNA.com<">mailto:|vaughn.mcdaniel@karcherNA.com>
Please note my new email address.
[cid:image001.jpg@01CA945F.1B7AD840]

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.

[ptc-726111]

Vaughn,

I understand your concern about family tables (method 1), but I think that is the best approach. When using the part in an assembly, I find it to be easier to replace the component if it is a member of a family table. However, I was wondering if it is possible to assign a different material to each family table member.

I probably wound not use assemblies (method 4), but method 3 could be a good approach provided you have the AAX module (may Pro-E users do not). I know some Pro-E users without the AAX module use stand alone parts (method 2), and I likewise wonder if there is a better alternative. Post a summary of what you find out.

Chris

In Reply to Vaughn McDaniel:

Like many of you we create items/part numbers (PN) with the same geometry but in a different color/material. What we would like is

I think there are four ways to do this.

1. Family Table

2. Stand-Alone parts

3. Inheritance/Merge/CopyGeom (Same relationship structure)

4. Assemblies

Family Tables, used in the past, are out because of our regimented change control process.
Stand-alone parts are no fun, having to change multiple models for the same geometry change, and which one gets sent to the toolmaker?
Maybe having a general/master .prt and then add that into an assembly to make the PN, this takes care of mass geometry changes, and clears up which one drive the tooling, but now there is a part model that gets no PN, thus could be out of control and assemblies where they are not needed.
Inheritance/Merge/CopyGeom seems good, no assembly structure, mass geom. update is easy. It is an advanced feature, so could confuse some users.

In your experience what are the downfalls of any of these methods? Which do you use? I'm just looking for that burn that I don't see.
Thanks for your comments.

WF3.0, soon to be 5.0
Ilink 3.x soon to be Windchill 9.1

Vaughn McDaniel III | CAD/PLM Administrator | Kärcher NA - Englewood |303-762-1800x187 |vaughn.mcdaniel@karcherNA.com<
Please note my new email address.
[cid:image001.jpg@01CA945F.1B7AD840]

[JoshuaHouser]

Hi Vaughn,

I think we've probably had this conversation at PTC User, but since I've been harping on this topic for a couple years now, I'll add my 2 cents.

We attempt to avoid creating the same part multiple times in Pro/E because it is not value-added work for the engineers/designers. We use a variable in our ERP part number to indicate color/finish that does not affect the functional design of the component. (Due tocorporate changes, we still do not have EPM Documents in Windchill).

With Windchill being the master repository of our BOM's, we will be forced to either create 1:1 Pro/E files for colors/finishes, or have disassociated BOM part structures in Windchill, negating the benefit of part and cad document association.

I believe we will most likely use inheritance features to create these multiple parts/drawings. We have discouraged our users from family tables for years due to the overhead of and historical 'flakiness".

Joshua Houser
MCAD Tools Administrator
Pelco
Worldwide Headquarters:
3500 Pelco Way
Clovis, CA 93612-5699 USA
Phone 559/292-1981
North America 800/289-9100
-

www.pelco.com

[ptc-1932745]

You can use interchange groups to change out non-family tabled parts automatically, even with different topologies.

This is turning out to be our favored 'family part' method in assemblies. Good separation also from part rev / interchange group rev / etc... as compared to family tables.



I think that you need a seat of AAX, or TDO, or Manufacturing to get the interchange groups to work initially.



With Model based definition, (un)fortunately the materials info, surface finish, etc... is embedded in the model and I see no other choice than to have separate and possibly shape-identical models with different attribute data.









Christopher Gosnell

TRIGON INC.
FPD Company
124 Hidden Valley Road
McMurray, PA 15317
PH: 724.941.5540
FX: 724.941.8322
www.fpdinc.com

[vmcdaniel]

Since we have AAX I'm trying to go down the Inheritance route, seems like the right tool for the job.

Those of you who use inheritance:

My next hurdle is: We don't 'always' know what the requirement for a part will be in the future. We could release version 1-green and 2 years later version 2-blue comes along. So should we:

1. Use aparent driving model, such as tank_geometry.prt and that will drive 1-green.prt and 2-blue.prt

OR

2. Use 1-green.prt as the parent for 2-blue, 3-yellow

I wantONE rule that applies to all myscenerios. #1 seems excessive to do for every inj molded, painted part, just incase we make a different color'some' day.

I think I'm fine with #2, our PN are incrementing and PLM knows the trail back to the intial one.

[ptc-810450]

WF3 and Windchill 8

We don't associate the CAD parts, only the drawings (and have set the
lifecycle state of the drawing to flow down to all parts directly
referenced in the drawing). We also have a separate specification document
that has all the details about colours, allowable burrs, cleanliness,
various cosmetic details, materials etc - it is THE specification for the
part. Therefore the drawing only becomes a specification of the shape and
tolerances and can be associated to multiple WTParts (for exampe the
different colours). From the drawing it is easy to find the appropriate
CAD model if required. This means you only have one drawing and one model
for any amount of colours.

I found that actively associating EPMdocs is more trouble than it is worth,
particularly when a product is not in full change control - the design is
still being changed and users would change assemblies as a 'what if' and
check it in, wildly changing the BOM. Once the design is locked down and
we were in change control, the BOM structure has typically been already
manually created and there is no point going back to create the active
associations (note that we don't have large assemblies so this is feasible,
also most of our users are familiar with manual BOM creation because we
have a Manufacturing View that is also manually created). Finally,
associating EPMdocs is much more painful than associating any other
documents (particularly for non-CAD users) so we avoid unnecessary
associations.


In regards to Vaughn's email, I would go with option 2. Use one colour as
the parent for the other (less models to manage).
--
Mark von Huben
Principal Engineer
Cochlear Ltd
14 Mars Rd
Lane Cove, NSW, 2066
Australia




|------------>
| From: |
|------------>

[vmcdaniel]

A couple more options are:

5 - Multi part drawings, represent the different colors on atable on a single drawing.

6- General drawing and seperate specification document for different colors.

We have always modelled every part. Makes sense when you are trying to drive the BOM for the CAD, you need to represent it some how.

[vmcdaniel]

SUMMARY:

We are going to go down the Inheritance road,we have not heard of one disadvantage. Our two largest concerns are -Replacing in an assembly and creating the drawing.

We are up in the air about the drawing we will use, create new, or an overlay.

Inheritance models can be <u>automatically replaced in assmblies</u> as easy as Family Tables: From Pro/E Help:

Replacing Components Automatically

Automatic replacement of components can be performed only if the replaced model is one of the following types:

●A Shrinkwrap feature●An Inheritance feature●A Merge feature●A member of a Family Table●A functional interchange assembly●A model that is declared to a layout

Other responses:

Hi Vaughn,
Saw a presentation on Inheritance parts V Family Tables at the 2007 Conference. This was given by Craig Iverson and Kevin Alexander of Fluidmaster. I have the PowerPoint (1.8MB) if you want it. They were recommending Inheritance Parts to replace Family tables especially in the transition to Windchill PDMLink.

I also fiddled with Inheritance Parts when I got back and made a simple PowerPoint (480k PDF) which I have attached. This was thinking of cast and machined parts but you get the idea. I have the WF2 parts I made for this example and altogether it fits in a zip file of 1.8MB if you want those.

We do not really use it much as we do not yet have a PDM system and we still limp on using Family Tables in the few parts that need colour change. I can see us running into the same issue when we do move to PDM though and I plan that we will use Inheritance parts to solve this.
Regards, Brent Drysdale
Vaughn,
I have done something similar with an executable statement. The part with have an input of “material” and “color”, and a parameter I have called PRTNO for the part number. Say the part’s generic number is “XXX-0001234” and you would use a suffix “-XXXX” to determine color and material. “-1XXX” would be nylon, “-2XXX” plexiglass, “-3XXX” polyethylene, and the last “XXX” would represent color. Relations could look something like this:
IF MATERIAL==1
PTC_MATERIAL_NAME="NYLON"
MATNO=”1”
ENDIF
IF MATERIAL==2
PTC_MATERIAL_NAME="PLEXIGLASS"
MATNO=”2”
ENDIF
IF MATERIAL==3
PTC_MATERIAL_NAME="POLYETHYLENE"
MATNO=”3”
ENDIF
IF COLOR==”RED”
COLNO=”001”
ENDIF
IF COLOR==”BLUE”
COLNO=”002”
ENDIF
IF COLOR==”GREEN”
COLNO=”003”
ENDIF
PRTNO=” XXX-0001234-“+MATNO+COLNO
I then use the PRTNO parameter in my BOM tables to report the part number. As long as your material files and directory are clear all the mass properties should be automatically updated.
Hope this helps,

Rodney Decker

Engineer

Leggett & Platt Storage Products Group

We create the raw assembly and an associated drawing. Then create the painted assemblies with the first item being the unpainted assembly.
Shown on the unpainted drawing are the epls for all the painted assemblies.
Currently the unpainted epl is in the lower right section of our drawing immediately above the title block.
The painted epls are loaded on the drawing in the upper right moving down towards the unpainted epl.
The only drawback we see is that both the painted and unpainted parts now must travel at the same revision level since all are shown on the face of this one common drawing.
Regards,

Ron

Hi Vaughn,
Whether we use Family Table Instances or Inheritance parts we use your method #2. Of course for our equipment this means the original part is almost always black but this is not a sticking point to the method. In a way #2 captures history so that with colours you know that a green one was an original.
Regards, Brent Drysdale
Why not use an assembly with your base part and a bulk item for the different colors?
Arnold

Maybe I am wrong but is there not a 5th way?

We have a lot of identical parts with different materials (& of course different part#s). We just put a chart on the drawing with a column for the part#s, material, color, spec#s, markings, etc...

One model, one drawing, charted. Very simple & it works very well for us.

Regards,

Joe S.

For what it’s worth I family table a lot. We have hot rolled and galvanized equipment that have identical geometry, so I have a generic and as many instances as I need, then I create (when it makes the most sense) a drawing table that’s automatically filled in by the family table. I just find it a time saver for that as well as the ease of using the replace feature in assemblies.
To assign different materials to family table instances add a column for the parameter MATERIALFMF. If you’ve not assigned your generic’s material do it now, if you already had it there that’s fine too. Now you have to go to RELATIONS and scroll down to the line that reads: MATERIALFMF=MATERIAL_PARAM("CONDITION"), turn that line off with a ‘/*’ at the beginning of the line. Save your relations and regenerate. When you go back into your family table you will be able to assign different materials to the instances now in their appropriate cells.
Hope that helps. mb

[vmcdaniel]

One more issue on this:

Family Tables allow you to switch instances in a drawing and not have to start over just for a color change. Does merge have a way to do this?

[vmcdaniel]

Here is the PowerPoint

[JoshuaHouser]

This one goes back to 2005, but it may have some useful tips when diving into Inheritance Features.

Joshua Houser
MCAD Tools Administrator
Pelco
Worldwide Headquarters:
3500 Pelco Way
Clovis, CA 93612-5699 USA
Phone 559/292-1981
North America 800/289-9100
-

www.pelco.com