When a family with connectors is nested into another family, the connectors get ‘lost’ in the host family. They have to be recreated in the host to appear in a project. This is the case even if you are nesting a shared family. This behaviour is akin to a project being linked into another one, where the connectors from the linked project won’t be available to the host project.
To give an example, let’s imagine there is a host family classified as specialty equipment. Within the specialty equipment family we have a sink that we created as its own family, set as a shared plumbing fixture, and then nested into the host family. The sink of course has plumbing connectors, but these won’t show up in our project because they are within a nested family. The first thing that comes to mind is to add a new set of connectors to the host family and use those instead, as shown in the image below.
This solves the immediate connector problem, but can create other problems depending on how you use schedules and systems in Revit. As a shared plumbing fixture family, the sink will appear in the project’s plumbing fixture schedule, and through the schedule you can update the FU (fixture units) values within the sink’s connectors, as shown in the image below.
Unfortunately the sink’s connectors aren’t actually active in the project; only the connectors in the specialty equipment host family are. When you select the specialty equipment family, you see the FU values for the connectors that you recreated in the specialty equipment family, not the ones of the nested plumbing fixture. And if you want to create a system, you will be connecting to the connectors in the specialty equipment family as well. At the very least there is strong potential for confusion and a disconnect (pun intended) between schedules and systems.
Another way to solve the problem would be to nest the specialty equipment family within the plumbing fixture. The issues with this approach are too many to cover here so I’ll leave that as an exercise for those interested.
A third approach could be to create a multi-category schedule and then have shared parameters that, for example, drive the diameters of the connectors in both the host and nested families. This schedule could list the plumbing fixture and specialty equipment families so you could manually make their diameter values match. There’s just one hitch. A plumbing fixture has built-in parameters for CWFU, HWFU, WFU (Chilled Water Fixture Units, Hot Water Fixture Units and Waste Fixture Units respectively). These parameters won’t appear on a multi-category schedule, and there is no way you can turn them into shared parameters (a trick I previously wrote about doesn’t work in this case).
As with almost anything, there is a workaround for this third approach that involves creating new shared parameters, but it isn’t worth discussing as it’s more work than it’s worth.
Then there is the right approach, which I nearly forgot about thinking of all the potential workarounds with nesting. Currently the right approach is to not nest families with connectors at all, but instead to create a group. The whole thing still comes up small (for delivery or storage purposes) and gives you the best results (when you bring the group into a project you will get two families, classified independently – file size increase being irrelevant as the extra weight will be shed on loading the group into a project). It’s also what Revit wants, currently.
Sink: 288K
Casework: 584K
Specialty equipment (all as one family and no nesting): 636K
Specialty equipment (nested sink): 716K
Group (casework and sink): 972K
When I say “currently” above, I mean from the point of view of systems within Revit and how they are best approached. The ability to nest families has to-date ignored the needs of families with connectors, or MEP families in general. The same issue applies at the project level. Allowing connectors to be seen when nested would have been great in so many of our family creation projects I don’t even want to count them. The fix would likely come hand in hand with connectors showing through linked files. The latter would solve workflow issues encountered in large projects on the mechanical side, where for performance reasons you might need to split up the project. In short, I would say the best future solution to lost connectors in nested families would be to never lose them in the first place. But for that, we’ll need a new version of Revit.
