Starting a new series today, with some quick one question Revit quizzes. If you have any feedback please do not hesitate to leave some comments below…
The scenario is as follows:
You have a custom door family, containing 2 nested shared door families. You use the host family to lay out the nested families. When you schedule the doors, you notice each instance of the custom family is being counted as 3 doors versus the expected 2. Why is this?
Check below for 2 approaches
1. You can set the host door family to another family category, such as Generic Model. This is how similar families, such as cased openings function. In that case, only the 2 nested door families would schedule. For a good recent post on this check out Dept. of Reviteristics - An Opening isn't a Door on Revit OpEd.
2. Create and add a shared parameter in the door families; it could be a Yes/No Parameter called "Schedule". Then in the host family, un-check "Schedule".
Lastly, filter your door schedule to exclude any matches. Simple video example, with no sound, here.
Ryan,
Does not unckeching the "Shared" property stop the nested components from scheduling seperately? That is how we typically handle our nested families. Our doors have the property unchecked while our plumbing fixtures are checked.
Posted by: Chris Hubbard | January 25, 2011 at 01:03 PM
Correct; un-checking “Shared” in a nested family would prevent the nested families from appearing in the project schedule assuming they were loaded into a host family.
In this example, the host family itself is appearing in the schedule, as it contains the nested 2 "Shared" families. This is the family [host] we wish to exclude from the door schedule. Both nested families in this example are set “Shared” so they appear in the schedule.
Posted by: Ryan Duell | January 25, 2011 at 01:30 PM
I prefer the first approach of creating the opening as a Generic Family. Nested shared doors are the only way to go as there are far too many door styles
Posted by: Sumex | January 25, 2011 at 04:49 PM
Ryan,
Thanks for posting that. Sumex I agree that the standard "opening" should be a generic model to prevent it from scheduling with doors. However depending on the project we sometimes use the door frame as the door and sometimes the door panel. We can quickly switch each of our families (copy to project library edit family and resave) prior to loading into the project.
The downside of this method is once we commit to shared or not, we have to stick with that because you cannot reload a family or nested component after changing that property.
I agree that nested doors are the only way to go for the same reason. Prior to that we either ignored the frame (dumb parameter for the type) and drafted a frame layout or had a new type for each frame type material and profile. It was a PITA.
Good to know that there are different ways to accomplish the same task depending on the need.
Posted by: Chris Hubbard | January 26, 2011 at 11:14 AM