Tie Dimensions of Nested Family to Host?

[ctc]

I have created several doors to nest into a cabinet family and to be able to swap them out.

I have loaded a door into the cabinet family and I would like to tie the door's height & width to the cabinets height and width.

When I place the door into the cabinet family and use the align tool in elevation to align the corresponding reference planes of the door family to the cabinet family, the door family will not resize to fit the cabinet.

How do I tie the height and width of the door to the cabinet?

[JamesVan]

You have to make a parameter in the door family, then tie it to a length parameter in the cabinet family. Select the nested door in the cabinet family, drill down to the height parameter and click the little button at the right end of the row. This will allow you to drive parameters down into nested families.

[dbaldacchino]

As a rule, I like to make the nested family parameters that I want to connect to the host parameters as an instance parameter. You can drive instance parameters by both type and instance parameters within host families. This way you can re-use the same nested door for different size cabinets.

[aaronrumple]

As a rule, I like to make the nested family parameters that I want to connect to the host parameters as an instance parameter. You can drive instance parameters by both type and instance parameters within host families. This way you can re-use the same nested door for different size cabinets.
This is a good strategy, except I did run into a limitation recently. I was controlling the nested thickness of a door panel and frame. It had to be a type parameter or several other parameters used to control the front to back relationship of the wall wouldn't work. Support confirmed this was "by design". So there may be other examples of this limit that I haven't run into, but I think they can be handled on a case by case basis.

[dbaldacchino]

Thanks for the heads up Aaron. I recently ran into another issue with doors and Support said it was by design too...not really related to parameters in this case, and didn't make much sense to me.

I set a reference @ 4" away from the door jamb as Defines Origin. The thinking was that I can align & lock this to a wall so when it moves, the door follows. But, when you try to change the door to another family with the same structure (same ref plane at 4" from jamb as Defines Origin), you get a constraining error, which means you cannot lock the door to a wall and then change the door family. Leaving the door reference unlocked and then changing the family works perfect and the door does not move at all, so the constraining error doesn't make logical sense, but somewhow this is "by design".

[ctc]

This is a good strategy, except I did run into a limitation recently. I was controlling the nested thickness of a door panel and frame. It had to be a type parameter or several other parameters used to control the front to back relationship of the wall wouldn't work. Support confirmed this was "by design". So there may be other examples of this limit that I haven't run into, but I think they can be handled on a case by case basis.
OK, Thanks. 2 questions.

If I tie the dimensions of the door to those in the Cabinet, how does making a nested family "shared" affect the swapping of different nested door designs?

Does any of this affect or pre-vent a host family from having multiple different swappable nested families? Ex: doors, drawers, hardware all in the same cabinet family.

[dbaldacchino]

By making it shared, you can schedule the individual elements. Make sure you start adding descriptions and assembly codes to each element to make it easy to filter out schedules later on. By making families shared, you can add more families to your project and you'll be able to choose them inside your family (if you add a family label in your family) and not have to visit the family editor. You can only swop between categories of the same kind. So for instance if your door is of the door category, you can only swop from the list of doors in your project. This brings up one of the drawbacks of this approach since you cannot filter what is available for you to choose from.....once you make such nested family shared, you will then see ALL doors (for example) in your project as possible options to choose from.

Remember that when you want to be able to swop between different families, these nested families have to have exactly the same parameters, even if they are not used. For example, let's say you have a door with an opening and you have opening width and opening height parameters. If you're driving these parameters by connecting them to the host family parameters, these need to exist inside another door family that does not have this option (ex: no opening). Otherwise Revit will give you an error when you change these doors because it expects to see all connected parameters.