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

Community Tip - Need to share some code when posting a question or reply? Make sure to use the "Insert code sample" menu option. Learn more! X

Family Table Transforming the generic into an instance

madami
11-Garnet

Family Table Transforming the generic into an instance

Is there a way to transform the generic part into an instance and replace the generic element for a new element?

 

For example:
I have a case of a family table witches one the generic element is a part of an assembly.
The problem is, when I want to change any instance of this family table, it is mandatory to change the generic element too, and it forces me to create a new revision of the this generic...
What I'm trying to do is transforming the "actual generic" into an instance.
If that generic became an instance I wouldn't need to change the "generics" revision anymore, because I would have a new generic element ruling the family.
That would allow me to edit other instances by creating another version of the new "new generic".

Thanks.

ACCEPTED SOLUTION

Accepted Solutions
rreifsnyder
15-Moonstone
(To:madami)

This is one of the reasons that it is not best practice to actually use the generic in any assemblies. All you need to do is make a new instance that simply matches the generic (you may need to rename the generic based on your naming conventions) then replace the generic in the assembly with this new instance. One other point that is often overlooked is that I would not tie things together into a family table that are revved separately. For parts I only use family tables where the likelihood of needing to replace parts for size or other factors is high. For assemblies, where you are controlling different configurations it only makes sense where there are so many components in common that will all or mostly change together if there is a design change. I have seen them used where a new "version" of an assembly was re-identified to a new number to differentiate the new design from the configuration already in the field. This became a problem because that commonality started to diverge and became more of a problem than the table helped.

Of course there are exceptions to these but they should be considered carefully on a case by case basis.

View solution in original post

4 REPLIES 4
KenFarley
21-Topaz I
(To:madami)

I don't fully understand what you're asking, but I might have an idea of what you're doing.

When I use parts with family tables in assemblies, I have a method that I follow to make sure I can swap different instances in/out of instances of the assembly.

(1) Make sure the features that are being used to assemble the part into the assembly are common to all the instances. This is so when I use a different instance I don't get failures.

(2) When I define the instances of the family table in the Assembly, I "add column" the family table Part as a component.

(3) By default, the family table in the assembly puts a Yes or No in the rows for the instances for this Part. This is the default, but not the only option.

(4) For an instance in the assembly, instead of "Y" or "N", you can enter the name of the instance of the Part that you want to use for the instance of the Assembly. Be sure to spell the Part instance *exactly* as you have it defined in the family table for the Part.

 

Once you've done this, you can test it out by bringing up the Assembly instance and make sure the Part of interest is correct.

Actually that isn't my problem. What I'm trying to do is to create a new family, and trying to include the generic and all the others instances into it. This way I can change the family ruler. I added an image to help you to understand. But thanks anyway.

rreifsnyder
15-Moonstone
(To:madami)

This is one of the reasons that it is not best practice to actually use the generic in any assemblies. All you need to do is make a new instance that simply matches the generic (you may need to rename the generic based on your naming conventions) then replace the generic in the assembly with this new instance. One other point that is often overlooked is that I would not tie things together into a family table that are revved separately. For parts I only use family tables where the likelihood of needing to replace parts for size or other factors is high. For assemblies, where you are controlling different configurations it only makes sense where there are so many components in common that will all or mostly change together if there is a design change. I have seen them used where a new "version" of an assembly was re-identified to a new number to differentiate the new design from the configuration already in the field. This became a problem because that commonality started to diverge and became more of a problem than the table helped.

Of course there are exceptions to these but they should be considered carefully on a case by case basis.

It worked just fine!! Thanks a lot!

Announcements
NEW Creo+ Topics: Real-time Collaboration


Top Tags