Community Tip - When posting, your subject should be specific and summarize your question. Here are some additional tips on asking a great question. X
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.
Solved! Go to Solution.
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.
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.
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!