Assembly family table with relations

I would suggest that you use a notebook (*.lay) to define the variants needed. The notebook will define global variables and relations, and these can be declared/undeclared to any model as required. You can update each variant by changing the parameters in the notebook and then declaring it to the relevant models and have them update using the definitions in the notebook.

About Notebooks

I would approach this with Pro/PROGRAM and a COMPONENT Placement with a Variable that uses the model name for the placement.  That would get you different options on the assembly in a specific location. 

You could use the same approach for other locations that are resumed/suppressed or just move the original placement location parameter/dimension relationships.  Depends on how flexible you want to get.   

STRONGLY recommend you use CSYS references for any of this, they are the most stable and will keep you out of trouble - enabling you to focus on the legos you are moving/placing.

I think I’ve grasped the benefits of a notebook, but I don’t think it would be the right choice for me. To make it perhaps a little more practical: My aim is to have all the relationships that control the dimensions of the individual parts centralised in one place, but I want it to be possible to adjust the parameters in each sub-assembly where the individual parts are reused. Perhaps it’s possible with a notebook as well; in which case, I might not have understood it 100 per cent.

OK - key things I was assuming you confirmed with this objective:

 My aim is to have all the relationships that control the dimensions of the individual parts centralised in one place, but I want it to be possible to adjust the parameters in each sub-assembly where the individual parts are reused.

There are a couple of options for this.  Here is a nice overview of the problems with trying to use Pro/PROGRAM, Layouts, and Assembly Relations to get to the result.

My personal recommendation would be to use Excel to centrally manage the parameter mappings across your design… vs locking up the assembly with a bunch of logic and relationships to make things work. (sustainment problems).

You can use Nitro-CELL for FREE (there are limits on the amount of data you can send to/from Creo - but it is not limited other than that)… If your needs are small.. just use it.  If it is useful, and you need to do more.. then just buy a license.

https://simplifiedlogic.com/nitro-cell/

Dave

I’m going to assume I understand what you’re after and explain how I’ve dealt with this in the past. Not necessarily the best or most sophisticated method, but it has worked.

I’m thinking you want to have an assembly with some components that are always there, like your “frame” and “leaf”. Kind of like a wall and door or something like that. You might want the relationship between the two to differ for different instances of your assembly. i.e. door closed, door open to 45 degrees, maybe even door removed.

I’m further assuming you want to have “stuff” included in each of the instances. Some of the added components are to be in some of the instances, some are omitted.

Finally, I’ll assume that some of the components themselves have different versions. For example, a door has aluminum panels instead of lexan.

So, the way I address this kind of thing is to define the configuration of the different components with the appropriate family tables and relations.

If you’re going to be using different versions of a component in different instances of your assembly, you do NOT want to set the dimensions of the component from the assembly. This will work perfectly fine if you’re just using the component in the same configuration for all your assembly instances. However, if you’re going to have any number of assembly instances in memory at the same time, you’re going to end up with a “last to regenerate wins” situation. The last assembly you regenerated will change the component(s) to suit itself, which will make the component incorrect for the other assemblies.

Anyway, the method I used for the structure is:

1. Define the necessary family tables, parameters, and relations in the components to provide all the versions of them needed for the assemblies. Things like length, hole sizes, hole spacing, etc.
2. Assemble the groups of components that are to be included or excluded in any particular instance of the assembly. Things like mount plates, mounting bolts, door lock, etc. Grouped to provide minimum number of groups but enough to cover all the configurations needed.
3. In the assembly family table, add in all the different dimensions, groups, and components for each of the configurations needed.

If you group a bunch of things like features, datums, components, that group can be added to the family table in a column by selecting it as a “Feature”.

When you add a component to a family table, the default provided for entries in the rows for that component are “Y” or “N”. If you want to use a specific instance of the component, you replace the “Y” or “N” with the name of the instance you want to use from the component. For example if I have a model DOOR and I have “DOOR-TYPE-A” and “DOOR-TYPE-B” as family table versions of that DOOR, I replace the “Y” in the column with DOOR-TYPE-A or DOOR-TYPE-B. Make sure it’s spelled correctly or you will only get the generic model in the assembly instance.

It seems like a lot of work, but this has worked fine for me. You just have to be careful and diligent about how you arrange your assemblies. Do yourself a favor and change the name of anything you’re going to use in the assembly to something meaningful. That way in six months when you or someone else is trying to add something to the confgurations you won’t be frustrated trying to figure out what “d237” or whatever is referencing.