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.

In an Electrical Equipment family there is a system parameter for Voltage. As a system parameter it cannot be modified in any way—when the parameter is selected, the “Modify…” button is greyed out. It’s set as a type parameter, but let’s say I need it to be an instance parameter in a particular situation. You can tell type and instance parameters apart in a Family Types dialog box by looking for the “(default)” text that follows all instance parameters.

This is where the magic comes in. Pay attention to the trick or you might miss it. Now you see it as a type…

And now you don’t!

There are many things you can do in Revit that are not standard. Last night I was talking with Steve Stafford here at AU and discussing with him how some of these non-standard ways to achieve a result are too much of a hack to rely on (e.g. having connectors appear and disappear at will — oh yes, you can do that!). Then there are others, like the one being shown here, that I feel more comfortable using when creating families. They are workarounds more than hacks, and as such I give them a longer shelf life.

I was doing some consulting in Kuwait a little over a year ago when I was asked about doing just this kind of workaround in a family, where the best workflow would be achieved by having the Voltage parameter as an instance rather than a type. I managed to pull it off as I was complaining to Gary Ross (then at Autodesk) about this particular limitation. I found it more of a user interface limitation rather than an intended feature of Revit.

So how do you do this trick? Luckily you don’t have to be a magician. Open your Revit Electrical Equipment family, with your Voltage parameter set to type. Make sure you initialize the parameter with some value if none is there. Change the family’s category to something else, where Voltage is not a system parameter, for example Electrical Devices. Now your Voltage parameter is no longer a system parameter, so you can change it from being a type parameter to a system parameter. Once this is done, set the family category back to Electrical Equipment and you are done!

There are a few more things regarding this workaround that I’ll write about in a follow up post. In the meantime, I hope you find this little trick to be of use, and if you are at AU and would like to have a chat or meet for a drink, drop me a line.

Well I’m happy to report that you can have your cake and eat it too. The above image shows a pipe fitting family (an elbow in this example) that, when used in a project, will get highlighted in red if the angle of the elbow is different than either 45 or 90 (the two angles provided by the manufacturer). Not only that, it will also show you a non-modal dialog warning as you draw. But wait, it gets better! There is no plugin, hack or workaround. This is a built-in feature in Revit. The below video shows this feature in action.

Click here to view the embedded video.

You can achieve this seamless highlighting by means of the IsCustom built-in parameter on the Pipe Fittings Revit family category. When in a project, changing this Yes/No parameter will display a modeless dialog warning like the one shown below. The parameter can be controlled via a formula that draws information from within the project. You can add the colored highlighting by means of additional geometry associated to the IsCustom parameter.

One of our customers has been enjoying a set of fittings created this way and his feedback couldn’t be better. Long pipe runs, where a mistake of a couple degrees on a fitting can end up causing coordination issues, are now easily reviewed and fixed. And if a custom fitting is actually needed, then this can be highlighted and reported.

We are working on a manufacturer-specific set of fittings that all have this feature built in. I’ll write more about it when we release these families and write a follow-up post with step by step instructions on how to create such a family. If you don’t want to wait for the follow-up post, I’ll be at Autodesk University this coming week and would welcome the opportunity to talk with anyone who is interested in implementing this feature in their Revit families.

After several years in this business, I’d have to say that I agree with Steve’s general assessment. We’ve written before on this blog about the lack of clear and comprehensive standards for Revit families. Even among the standards that have been published, we have yet to see any significant adoption by Revit users or product manufacturers. For the most part, people seem to do whatever they think makes sense based on whatever experience and understanding they have of Revit.

So what is the role of content creators in this “wild west” of Revit families? You could argue that we should be playing the role of sheriff, riding into town on our trusty steeds and bringing law and order to the people. Yet even among content creators there isn’t broad agreement on what constitutes best practices for Revit families. You can see this in the comments on Steve Stafford’s post. One of the comments from a content creator talks about the need to include a schedule with manufacturer-specific content (which means including shared parameters in the families), whereas we have written before about how the best approach is for manufacturers not to include any shared parameters in their families. Another comment from a content creator talks about including model text within the family at the request of the designers for whom it was created, even though that text nearly doubles the family’s file size. While we think there are better approaches to including help text with Revit families (i.e. through a separate text file), we’ve been in the same situation of having a customer specifically request embedded text and having to comply. As a content creator, sometimes you have to abandon your own best practices in order to satisfy your customer.

Taking a step back, I would ask whether we should be surprised at this fuzzy state of affairs when it comes Revit families. After all, Revit is still in a relatively early phase of adoption throughout the AEC community; it is a completely new kind of platform relative to its predecessor; and “Revit families” itself is such a broad category (everything in Revit is a family!) with such broad applications that it would be another kind of mistake to think we can find a one-size-fits-all set of rules and standards for how a Revit family should be built.

To a large degree, I think that developing and applying coherent standards will always be a slow and iterative process, and we need to be patient with it. At the same time, I do believe content creators have an important role to play in facilitating and accelerating that process. As a kind of nexus between end users, manufacturers, and Autodesk itself, and with a wider range of experience with Revit families than any of those parties, content creators are in a unique position to foster dialogue and debate on standards. The best thing we can do is publish our views on the subject and encourage public discussion on specific points. For example, let’s return to the question of whether manufacturers should include share parameters in their Revit families. To us, there is no doubt that it’s an exercise in futility for manufacturers to include shared parameters in their families. In fact, we believe it does more harm than good. If someone thinks we’re wrong about that, then let’s hear the reasons why and see if we can reach some consensus about what standard would make sense for this issue.

With only a few days left until AU 2011 begins, I’m excited to attend sessions and engage in personal conversations where I can hear the perspectives of other Revit practitioners and content providers on the subject of Revit family standards. I’m looking forward to a week of lively discussions and hopefully to making some measure of progress in settling the Revit families frontier.

To spice things up a bit, I took out my not-so-exciting (but very informative) voiceover that I recorded for the AU virtual booth video, and replaced it with a soundtrack timed to the images in the video. So turn up the volume, hit the play button, and let our Revit families help you celebrate the end of the week. Happy Friday!

Click here to view the embedded video.

We’ve now posted the final and correct version of the butterfly valve to our sample downloads page. If you downloaded our Pratt butterfly valve and got errors when loading it or selecting certain types, then we sincerely apologize for the inconvenience and frustration you experienced in trying to work with an incomplete Revit family never meant for distribution. We hope that you will consider downloading the family again and giving it another spin. In this case, the second time should be the charm.

On behalf of our entire team, thank you for your patience and understanding, and as always we welcome any questions or comments either here on the blog, by email at contact@andekan.com, or by phone at 415.366.7755.

Because the transformer’s geometry was fairly simple and straightforward, we created the family to be driven entirely by a type catalog. This allows users to quickly select and load only the case geometry and parameters of the kVA model(s) they are using in their Revit project, thereby improving the family’s usability and performance. In the future, having the type catalog will also facilitate keeping the family updated with current products specs and dimensions, or using it as a template to create new families for similar products from the same manufacturer.

Below are few images of the family in 3D. The first shows the family at different levels of detail, while the second shows several different types in Fine, and the third shows a rendering.

The black box on top of the second case above represents an optional smart energy meter that can be turned on or off by the user.

In addition to giving us a good opportunity to brush up on our electrical equipment families, the project called for adding a couple custom visual features to the family in order to meet the needs of engineers working with this product in Revit. One of these features is an option to display the transformer’s center of gravity, which is important information for ensuring safe placement of the transformer, especially in areas with seismic activity (i.e. right here in California). Below are a couple images showing the family in different views with the center of gravity indication turned on.

The second custom visual feature we added to the family was contextual highlighting of the transformer’s conduit access areas. Each model’s case has two areas where the manufacturer recommends cutting a hole for hooking up an electrical conduit to the transformer. We built the family so that the conduit access areas appear highlighted when a user attempts to create a conduit connection to the family. While within Revit it’s currently not possible to restrict the actual placement of a conduit connection on a family (i.e. you can choose to connect a conduit anywhere on the surface of a family), this visualization feature at least gives the user an indication of where they ought to place their conduit connection for compliance with the manufacturer’s specifications. Below are a couple images showing the conduit access area highlighting in action.

Both we and our customer were excited to develop these custom features for the E-Saver-C3L family, and we’re eager to receive further feedback once the family has been put to thorough use in Revit projects. We’d also love to hear your questions or comments either about the features presented in this post or about any other aspects of working with transformer families in Revit.

If you’re reading our blog, then you might be most interested in the long-overdue update to our Sample Downloads page. We added 5 new sample families for you to download and check out, including the Clow reducing wye and Tyler Pipe roof drain shown below. You can see all of the new samples here.

We’re excited to begin offering this wider range of sample downloads, one that reflects both the breadth and depth of our experience creating Revit families. We hope to continue adding families to the page as the months go by, and we’ll be sure to continue announcing those new additions here.

Happy downloading!

This time I added the issue of how to name your Revit family files to the list of things to consider. I think what I had to say came as a surprise to some people in the audience, so I thought I would share my stance here as well, where I can go into more detail and get more feedback.

To date, all the issued standards or guidelines covering Revit families contain a recommended naming convention. Let’s take a look at the different approaches taken by some of the best known standards.

Autodesk RMCSG

<Functional Type>‐<Subtype>‐<Manufacturer>‐<Descriptor 1>‐<Descriptor 2>‐<2D if necessary>

ANZRS (Australia & New Zealand)

<Functional Type>_<Subtype>_<Manufacturer>_<Descriptor1>

Open Revit Standards

<Identifier>_<Category>_<Type>_<Manufacturer>_<Description>_<Host/Size>

Revit Foodservice Equipment Standards

QF_Manufacturer_Model

Each has an accompanying set of rules about the use of special characters, lists of names for the different fields, exceptions to the rules, etc. It is clear that no two standards are the same or have the same rules. What’s more, two people using the same standard might arrive at a different name depending on each person’s interpretation of what information should go in a given field, how to make an abbreviation, etc.

In my experience, none of these standards has taken hold, and most companies also have their own internal naming conventions, different from any published documentation, which they are hesitant to give up. So what is a Revit user or BIM manager or product manufacturer to do in this world of incomplete and conflicting naming standards?

I would say don’t worry about it. It’s actually not a major consideration, or doesn’t need to be. Pick one that you think makes sense and move on. Don’t stress about which standard is most relevant to your industry, or most likely to gain popularity, or even the most comprehensive.

Why do I want to remove naming conventions from the list of things to consider? Ask yourself what the point is of having a naming convention in the first place. Not surprisingly, the reasons given by the published standards all vary, but there are two reasons that all of them have in common: a naming standard allows for 1) identification and 2) finding (searching) of families, both inside and outside of Revit projects. In my experience, these are also the two needs that make people the most anxious about choosing the right naming standard to use.

Identifying and finding families are cumbersome tasks with current tools. This is why we turn to file naming, which is perhaps the most rudimentary tool but also the most accessible. But this is bound to change in the near future. Outside of Revit there are tools for managing and finding families that are more powerful and faster than any naming convention would ever allow anyone to do. And these tools have only started showing up. I’m certain that within a year there will be more options available than published naming standards.

Inside of Revit things could quickly change as well. I don’t have any specific knowledge of how or if Autodesk plans to sort out the challenges of finding families within the project browser (and if I did, I wouldn’t be able to tell you), but anyone can see that the current solution is sub-par. An improvement could come as soon as within a few months. Even if it took a few years for Autodesk to address this, it will be much sooner than any significant amount of people agreeing to a file naming standard.

In short, I’m sure naming standards won’t be an issue anymore. The amount of man hours that have been spent considering the best file naming convention for Revit families would have allowed us to build and finish the tower of Babel six times over by now. Personally, I use one standard, apply small changes to suit working conditions, and rely on other tools for making sure I can identify and find my families.

Type catalogs, on the other hand, have been getting better, more practical for day-to-day use, and, thanks to an improvement in Revit 2012, easier to deal with than ever. Gone are the days when creating a type catalog was an exercise in self-mutilation. Now you can just open any family in Revit 2012, choose Export -> Family Types and your template type catalog txt file is ready, without any chance of spelling mistakes or incorrect data categories. Sweet!

So what about the built-in family types? What’s wrong with them? I did a little research on the evolution of types in Revit by posting a question in some LinkedIn forums to find out how built-in family types and type catalogs came to be. My feeling was that the built-in types were first and type catalogs came later as a more thought-out solution. Wesley Benn confirmed my suspicions when he wrote, “…family types showed up in version 2‚” while “…Catalog files (then known simply as the family type browser) showed up in version 4.0.” And from the version 4 release notes as posted by Wesley:

Family type browser:

Families now can have types defined in external text files. These files must have the same name as the families itself and reside at the same directory location. When the family is loaded, externally defined types are visible within the “Load Family” dialogue and only those types selected by the user are created in the project. For families with a large number of possible types such as structural shapes, this makes it simpler to manage the type lists in a project.

So there you have it: type catalogs were created as a solution for families with “a large number of possible types.” This points to the one small advantage to built-in family types, which is that they allow you to bring into a project a family and all its related types in one fell swoop. In that sense they are a sort of group, and that’s about it. Everything else about them is a drawback. Say you have a family with built-in types and you don’t want some of the types in your project. Tough luck. After you load it, you’ll have to hunt down the family in the project browser (not an easy task given the current user interface) and remove the unwanted types. If the unnecessary types are left in there, you are wasting space and increasing memory requirements (though I would have to test the latter more thoroughly to be able to make that claim with certainty – if anyone is up to the task and wants to report back, it will be appreciated). And what if you don’t have time to go hunting and instead just leave the extra types in the project? If you’re working on a team, someone less familiar with the types of that particular family might pick the wrong type, and you end up with the wrong information in the project.

It doesn’t end there either. The maximum recommended number of types built within a family is 5. That is, recommended by the Seek guidelines (though not necessarily what users do in practice). With 5 types, updating some parameters for one type and forgetting to update those same parameters for other types is a common mistake. It’s one of the reasons why I always leave the creation of new types until the very end of the family creation process. But even that won’t help if I’m editing an existing family with built-in types. The interface doesn’t make things easy either. If you don’t check for yourself, there is nothing in the family editor to tell you that a family has other types!

In contrast, type catalogs won’t automatically bring in a set of types with just a double click. Instead, when loading a family that has a type catalog, you are able to select only what you need, and even filter through the available family parameters shown in the type catalog. You can repeat the procedure to bring in other types later, when and if you need them. And editing the types or adding types to the family is something that can be done from Excel or a Google Spreadsheet. You don’t even have to know Revit to update a type catalog – think about all the manufacturers who have or will have Revit families and need to keep them updated as their product lines evolve year after year.

Type catalogs feel like the way parameters ought to be managed. It’s easier than ever to create them, and every piece of family management software that I’ve tried or seen works as if type catalogs are the norm, i.e. allowing you to load just the types you need. Yes, there is still room for improvement with type catalogs (worth another post), but built-in family types don’t seem to be going anywhere. Rather they appear to be slowly fading from use in Revit, and that’s fine by me. As far as I’m concerned, they are already dead.