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.
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.
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.
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.
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.