Skip to main content
T
Troll3x4-Participant
4-Participant
July 11, 2024
Solved

My model doesn't change size when regenerating when using families

  • July 11, 2024
  • 2 replies
  • 2404 views

Hi everyone, I am using Creo 9.0, and when trying to open one of the variations of my project created through nested families, the parameter I want to change gets changed but there is no way to regen the model. When I go through the first set of families it works perfectly, then I can choose the generic and everything works fine, but it doesn't work as it should.

I attach some photos.

Thanks, 

Joan

Captura de pantalla 2024-07-11 160557.pngCaptura de pantalla 2024-07-11 160614.pngCaptura de pantalla 2024-07-11 160828.pngHi everyone, I am using Creo 9.0, and when trying to open one of the variations of my project created through nested families, the parameter I want to change gets changed but there is no way to regen the model. When I go through the first set of families it works perfectly, then I can choose the generic and everything works fine, but it doesn't work as it should.

I attach some photos.

Thanks, 

Joan

Best answer by KenFarley

Are you trying to load two instances from your top level "HEAD..." at the same time? If so, how do you know what the dimensions of the component parts should be? What will happen, if I'm thinking through things, is the "last" assembly to have its relations evaluated will "win". It is the one whose dictated dimensional values will be applied to the components.

There is not a different component loaded for every assembly you have in memory. If you have a part that is being used in all the assemblies, it is a part in memory only once. It has its own Session ID. If you load up another assembly that uses that same part, it references the exact same part that is already in memory. So if that second assembly makes changes to the part those changes will take effect and thus change what is going on in the first assembly. This is why I generally don't use assembly relations to drive dimensions in components.

My method for doing what you seem to be trying to do would be to:

(1) Build the lower level part(s) with all the options I think I'm going to need. For example, "femhead" will have a family table with instances like "femhead-32dia-coat", "femhead-32dia-nocoat", "femhead-28dia-coat", etc.

(2) In the top level assembly, say "femhead-asms", just have the generic, "femhead" in the assembly with the other parts.

(3) Put a column in the family table of "femhead-asm" for the "femhead" component.

(4) For each instance of the assembly, instead of the default "Y" or "N", put the name of the version of the "femhead" part that you want for that instance. For example, "femhead-asm-32coat" would have "femhead-32dia-coat" instead of "Y" in the "femhead" column.

 

Perhaps this method of structuring the assemblies will work for you.

2 replies

tbraxton
22-Sapphire II
tbraxton22-Sapphire II
22-Sapphire II
July 11, 2024

Without having access to the models, it is difficult to determine what is the issue. It appears that you may be using nested family tables of an assembly that is 2 levels deep. As a general rule, I would not consider using family tables as a best practice to manage design intent that needs to propagate through multiple levels of designs.

 

Have you used the global reference viewer to look at the dependencies of the instance in the second level? 

    T
    Troll3x4-ParticipantAuthor
    4-Participant
    July 12, 2024

    I have tried also with just one family table and it is not working. Also, what should I look for in the reference viewer? I attach a .zip file with my models and assembly.

    Thanks.

    tbraxton
    22-Sapphire II
    tbraxton22-Sapphire II
    22-Sapphire II
    July 12, 2024

    The OP is using an educational license.

     

    To the OP; educational license is not compatible with commercial versions so most of us will not be able to open your files.

    KenFarley
    KenFarley21-Topaz II
    21-Topaz II
    July 11, 2024

    You're using Session IDs in your relations. Every instance in memory will have a unique Session ID. If you have used d6:2, but the instance now in use is different, i.e. it now has Session ID 28, your relations will not work as expected.

    When I need to do something of this nature, if I do in fact understand your intent, I ensure the component models have all the different iterations needed, then call those in the assembly family table.

    See discussion from this recent question:

    https://community.ptc.com/t5/3D-Part-Assembly-Design/Family-Table-Suppression/m-p/959873 

    T
    Troll3x4-ParticipantAuthor
    4-Participant
    July 12, 2024

    I don't see how that would be my issue, since my relations are working perfectly fine, except when I try to change the parameters from the family table it just doesn't work. If I get to just the coat or no coat versions, and then I select the generic version of those, it lets me change the parameter and regen it properly, but not if I do it from the family table. I've tried to put it all in the same family table, as I understood I should do from both comments I've received, and still it doesn't work. I did it with nested families in that way since is the way I've learned at university.

    Thanks.

    Captura de pantalla 2024-07-12 093319.png

    KenFarley
    KenFarley21-Topaz IIAnswer
    21-Topaz II
    July 12, 2024

    Are you trying to load two instances from your top level "HEAD..." at the same time? If so, how do you know what the dimensions of the component parts should be? What will happen, if I'm thinking through things, is the "last" assembly to have its relations evaluated will "win". It is the one whose dictated dimensional values will be applied to the components.

    There is not a different component loaded for every assembly you have in memory. If you have a part that is being used in all the assemblies, it is a part in memory only once. It has its own Session ID. If you load up another assembly that uses that same part, it references the exact same part that is already in memory. So if that second assembly makes changes to the part those changes will take effect and thus change what is going on in the first assembly. This is why I generally don't use assembly relations to drive dimensions in components.

    My method for doing what you seem to be trying to do would be to:

    (1) Build the lower level part(s) with all the options I think I'm going to need. For example, "femhead" will have a family table with instances like "femhead-32dia-coat", "femhead-32dia-nocoat", "femhead-28dia-coat", etc.

    (2) In the top level assembly, say "femhead-asms", just have the generic, "femhead" in the assembly with the other parts.

    (3) Put a column in the family table of "femhead-asm" for the "femhead" component.

    (4) For each instance of the assembly, instead of the default "Y" or "N", put the name of the version of the "femhead" part that you want for that instance. For example, "femhead-asm-32coat" would have "femhead-32dia-coat" instead of "Y" in the "femhead" column.

     

    Perhaps this method of structuring the assemblies will work for you.

    Terms & ConditionsAccessibility statement