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

Community Tip - Stay updated on what is happening on the PTC Community by subscribing to PTC Community Announcements. X

Replace Inheritance base/parent model with a family table instance???

JoshH
3-Visitor

Replace Inheritance base/parent model with a family table instance???

Hi folks,

I must be getting rusty since I just caught this one.

 

Are you guys serious that the only way I can replace the parent of an inheritance part is to use a family table instance?? SPR 2115640

 

Even if I didn't totally despise family tables, it still seems wrong to bind these two technologies together! A primary reason I might be swapping out an inheritance is because I want the base model to stay at the released state and unrevised. If I create a family table with it, now my revisions/release states are completely out-of-whack.

 

I really appreciate that there's a recent SPR on this. I'm hoping to stir the kettle a little on this one to make sure this one doesn't get lost.

 

-Josh


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.
6 REPLIES 6
Patriot_1776
22-Sapphire II
(To:JoshH)

That would actually be the best way to do it. Think about it. Family tables only cause issues if you don't know how to use them.

Or, you could make an interchange assembly, that might (should) work, but I haven't tried it.

I don't dispute the power of family tables when implemented with intent and intelligence.

If you are trying disassociate the base model from the inheritance part, your compounding the problem instead of fixing it with family tables.

Patriot_1776
22-Sapphire II
(To:JoshH)

If you're trying to disassociate the model, you've just negated the power of top-down design, so why do it in the first place?

I can't see anything compounding, you're still only going to reference one model, one instance or another.

What you can do is step out what you would use for an inheritance as surfaces, and use that in a skeleton or assembly model.

Let's take the simple scenario of a parent model with two inheritance children. The parent is a raw casting and the children each get machined slightly differently. Now we are going to create a separate raw casting so that they each are completely independant. Even worse, they are governed by ATEX regulations meaning $10K for any minor change.

Skeleton models and top-down aside, this change is driven by procurement and I need everything to correlate properly.

Patriot_1776
22-Sapphire II
(To:JoshH)

I didn't understand what you meant above. Did you mean that you MEANT to have 2 separate castings, or it happened by accident?

What you can do, is not use an inheritance model or skeleton, and simply put all the geometry into a family table, where different casting/machinings are simply instances. You can use datum curves and surfaces (as in an inheritance model or skeleton) to drive geometry. I've done this many times. this way, there are no external references. The down side is that only one person at a time may work on everything.

James62
10-Marble
(To:JoshH)

Hmm, sorry, but I don't get it either.

Do you mean to replace the casting (the reference model) or the machined parts (inherited models)?

Inheritance parts are one way associative to their reference part. Meaning, it could only makes sense to replace the parent, and update the childern, not replace the childern.

Top Tags