Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X
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
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
Solved! Go to Solution.
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.
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?
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.
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.
The GRV is used to map the parent child relationships among models. It will show the dependencies between models. The other method you can use is the relations editor tools. You can use this tool to evaluate the value of parameters and relations within a given model. If you are able to find the object at which the propagation of the design intent is not behaving as expected, you can test the relations within that model. This will narrow down the domain for you to troubleshoot.
You should do a test to confirm that @KenFarley is not correct since you are doubting his suggestion is the issue. If it is not the issue you should be able to provide evidence of why it is not the problem. This can be done by studying the relations at the various levels within the models.
Hi Troll3x,
If you want to change ball joint diameter, you should do the change in that part, not in the assembly level.
Inside the part family table instead of use the parameter 'D' you could try to use dimension d13 ( I don't know exactly, I don't have student license) from the generic part, and I think it will work fine.
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
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.
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.
Ohh ok, I understand it. So I tried to create a model of each component with the parameters I needed it for each and it worked, although I thought there was another faster way, but hey, it works, so many thanks!