Get Andy!

Meet Andy, our fully parametric, fully positionable human Revit family.

Learn more

Nested Families and the Case of Disappearing Connectors

February 3, 2012 Filed under: Revit Families,Revit Family Editor Posted by Jose Fandos

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.

Comments

  1. 3 February 2012 12:40 pm Erik

    If you make the nested family “Shared” you can connect to the connector in the Project environment. The only problem is that you can’t “see” the connector, you just have to know where it is. Then you can snap and connect to it.

  2. 15 February 2012 8:28 am Jose

    Erik,

    I’ve tried your suggestion in a number of ways but nothing works. Maybe you could explain how you went about it. What I’m trying to achieve is the connectors within the nested family actually talking to the system they are in, not just providing a snap point for geometry. Just placing a pipe, for example, correctly in the center of where the connector should be is something that can be achieved with or without connectors.

  3. 25 June 2012 3:41 pm Tucker

    We ran into an issue that basically destroyed models when nesting plumbing connectors. Revit Arch was trying to complete a system and if you edited a family from project it would take a lot more into the family environment. Once brought back in, it would sit quietly until it could not complete all the systems. This caused issues as it was not easy to deteremine when the issue occured. Most of the time we had to send to Autodesk to actually deconstruct and put back together.

    We had discussions with Autodesk on this limitation as well as the linked model issue. We took out all plumbing connectors to prevent this from being an issue in the future as a ‘temp’ solution.

    This was Lab families where we nested fixtures (shared) into sink families and used a family type parameter to allow you to swap out the fixture in 3 locations on a sink (showed in scheduled also) . This capablility was important the same sink depending on lab type would have different fixture requirements. We were always okay with not having the fixture drive the sink family or vice versa as we scheduled the fixtures seperatly to account for all the flow rates of different services.

Add a comment