Type Catalog - Family Type Parameter and Missing Spaces

This is for the Department of I could kick myself or Dept. of why can't I remember this.

These are two images of the same Type Catalog, one works and the other doesn't. The key location of the issue/difference is marked in yellow. This first one won't work.

Two little spaces on either side of the colon, like this: Family Name : Family Type.

Note to self, remember this next time around knucklehead!

Ooh Spelting Errrs - Descendnig

Daniel Stine found this one and passed it along to me so I'm not being so picky, he is :)

Silly develepers, thats not how your spell Descending.

Just more proof they shouldn't have changed the Family Types dialog ;)

Revit 2016 R2 - New Family Types Dialog Format

My friend Rolly sent me a screen capture of the new Family Types dialog. It's been revised to use similar buttons as some of the other dialogs, like the Filters and View Templates dialog for example.

It is slimmer now. I liked the larger buttons with words personally. I struggle (a little) with the tiny pictures (see what I did there) on these icon only buttons. At least I can rely on muscle memory to click on them after awhile. It will be helpful require less screen real estate for the interface and allow for more practical editing of those really long pesky conditional formulas...if dabble with those.

It seems I have a growing number of friends who are concerned about my lack of new blog posts :) Thanks Rolly! It's so much easier when you send me pichurs :)

Purge Unused - Categorical Wish and Dynamo

I wish we could choose a single category or several individual categories while using Purge Unused. The dialog defaults to selecting everything that is not used. It's normal to have things that just aren't used yet. That means a generic application of Purge Unused on everything will eliminate things we need, just haven't needed them yet.

I'd like to be able to click the Check None button and the check a box next to a category or categories.

I think the default presumption for Purge Unused should NOT be everything selected. We should have to deliberately do that using the Check All button instead.

It would be a lot faster than working through a long list of families and the unused types. Ideally (even ordinarily) the list wouldn't be long but I've seen some lists that go on and on...

For what it is worth, we can select a category and use NUM LOK + * to expand the whole branch of that category. Then we can select the first and last types in the branch followed by clicking OK to Purge Unused. It just takes a while for the list to respond when there are a few thousand types...yeah I know...that's a lot!

Regarding Dynamo

I pinged Julien Benoit about this and using Dynamo. In response he was kind enough to send me the graph below.

At the moment it leaves behind a Family with no types if the purging process eliminates types and there were no types in use. Given how quickly he responded to my question WITH an attachment, no complaints here! Thanks Julien! Check out Julien's blog while you are at it.

Changing Column Types and Copy Monitor

Using Copy/Monitor Revit does not complain when we change column families or types. It does complain if the column is moved. This is different from other elements like grids and levels. My understanding is that the way they expected Architects and Engineers to use the feature is a little different for columns, something like this:

• Architect places schematic architectural columns (different from structural columns)
• Architect sends model to engineer
• Engineer uses copy/monitor to create structural columns where the architects schematic columns are
• Engineer sends their model to Architect
• Architect adjusts their columns to be masking only (unless they are left uncovered)

The disparity between column types is intentional because an Architect's needs for the column are often different, masking a structural element versus designing/engineering the column itself. It can also be argued that it would still be better to complain when the column family is changed or swapped for another type (size). Even if, as the Architect, I've shifted my focus to wrapping structural columns it is likely worth being warned if the structural column has changed.

To be warned requires me to have a copy of the column to monitor, which I'd prefer to avoid ordinarily. In general, I encourage Architects to remove their own columns (structural or otherwise, if they use them) in their model as soon as the Engineer is hired and they send them their structural model. Now the architect can focus on using walls to wrap columns as required by Design Development and Construction Documentation. I resist the natural temptation to have my own copy of elements if at all possible, striving to avoid redundancy. Using copy/monitor (the monitor aspect only) can still alert us to major changes to location of the grids/columns.

For now Revit doesn't complain if we change the columns, as long as that change isn't its position/location. If that doesn't fit our model view then we need to let them know.

I wrote this post in part because of a thread at the Autodesk Revit Structure online user group. I wrote this suggestion to work around the lack of warning.

Since Revit is sensitive to movement, we could agree to move columns that are changed like this. If the architect is redesigning a column they can swap out the type for a new type but also move it off grid by a specific value. This will prompt a coordination review when the file is refreshed in the other discipline's file. When they examine the column they'll see the change is more about the size than position. They can respond to the change and move the column back into position, which will prompt coordination review upon return. We could agree that such trigger movement would always be East to West and always a specific distance or something like that so each team knows what to expect.

Revit MEP 2014 - Reapply Type

This button snuck past me in my reading about what's new. I don't see anything at all about it in the What's New documentation at the WikiHelp pages at Autodesk either.

Originally I was preparing for my What's New session at RTC (happening right now!) and while I was working through various tasks I noticed the button and thought, "Hey I don't remember that in 2013!"

Well my memory isn't that good anymore apparently because it IS in 2013 too.

I don't see it in the What's New for 2013 though and I didn't find it in 2012. Perhaps I am sort of correct (a little?) that it is new, or at least undocumented? I guess this fits into "What's old is new again"? I left a mention of it in my What's New class handout even though it isn't new to 2014.

If you haven't noticed it then let me explain.

Imagine you've placed a lot of duct and then change the related duct system settings about which fittings should be used. Nothing will happen to the existing duct. The Reapply Type button will take whatever duct you select and REAPPLY your recent changes (to the type) to your selection. Once a duct is placed it more or less remains inert unless another duct it trimmed or extended into it, touches it. When the duct is harrassed by another Revit will start to refer to the settings to determine what fittings to use.

Here's to "new" old features!

Create a Type Catalog

There is a relatively new feature available to create a type catalog automatically. Anyone who has tried to deal with this task using Revit MEP can relate to the awkwardness of trying to define the units for each parameter properly. The syntax and names used don't necessarily leap to mind.

If you visit the Application Menu > Export you'll find the Family Types option.

This does not create a perfect type catalog. By perfect I mean it may provide more parameters than you really intend to use in the catalog. That's because it will export them all. We often only provide the critical or most relevant values in a type catalog and leave others as default settings that all types will share. It works great if you want them all though.

Just to quibble though, I think that the name of the command ought to be Export > Type Catalog instead of Family Types. It would be more consistent with what the resulting file is called and used for, a Type Catalog.

Creating New Types

We have a few options when we need a new version of a door, wall or window etc. System families (wall, floor or ceiling for example) are created in a project while component families (door, window or furniture for example) are separate files, created in Revit's family editor mode.

If you need a new wall type you can choose door number one or two to make it. Door number one is using the Project Browser. You need to expand the Families category in the browser, then expand Walls and finally expand either Basic Walls, Curtain Walls or Stacked Walls.

When you select the wall you'd like to edit, or in this case duplicate, a right click will provide a list of options, one of which is Duplicate.

You can also double click on the name in the browser to open the Type Properties dialog. Once that is open you can click the Duplicate button.

I usually double click because I can duplicate and then immediately edit the type. The right click approach will still involve opening the dialog to edit its properties as well as renaming it. I figure the double click approach is a slight shortcut.

Once the new type is created it is available to use but not actually in use. Keep in mind that when using Worksharing it is only available in the local file we are using, we need to SwC to make it available to others.

Door number two is to select a wall you see in the drawing area and then click Edit Type on the Properties Palette. Once the Type Properties dialog is open you can duplicate and edit its properties. The significant different between these two doors is that this one alters the wall we selected, unless we reassign the wall back to the previous type first.

Worth restating, creating a new type by selecting a wall placed in the model will result in changing that wall to the new type unless you remember to reassign the selected wall to the original type before closing the dialog.

Another mistake we can make is to just edit the properties of the selected wall instead of remembering to create a new type first. This usually results in cries of anguish after all the walls change in the model. Fortunately if you catch it quick using undo will usually fix it.

With component families (aka loadable families) we can use the same approach in the project, either door number one or two. However this does not alter the original family in our project, office or stock libraries. If the new type really ought to be part of the library version then that family needs to be opened and have the type created there. Then you can reload the family to add the new type to the project.

Here's a two minute (ish) video if it helps.

Family Types or Type Catalogs

Jose Fandos wrote a post in August titled, The Death of the Family Types. He thinks that the role and or usefulness of built-in family types is over or "dead" as he puts it.

I don't agree entirely. I do agree that for someone who makes content regularly that adding types to the family directly is a task best left for last. Making sure every type is properly defined can be quite tedious inside the family. It isn't a lot of fun making sure every value is correct in the rows of a type catalog either though. At least it IS easier to copy/paste and then adjust values than within the family itself.

While making "my" life easier when making content, Type Catalogs can be perceived as a hassle by the end user because they need to load the family each time they find they don't have the type/size they need. The recommendation of no more than 5 types in a family found within the Autodesk Seek recommendations is one less than the earlier family editor guidelines that suggest no more than six. The text of the Revit Content Standards document that the team used internally said: (David Conant shared it with me in 2005 while preparing a session for AU)

Predefined Types:
• All families should have at least one pre-defined type unless a type catalog is used.
• Where real world examples come in typical sizes, pre-defined types should be generated.
• Where there are to be more than 6 predefined types in a family, use a type catalog to organize the types.

Keep in mind that these rules or standards were coming from the viewpoint that they are generic families meant to be pretty broadly applicable. Obviously the document David shared with me came after the introduction of type catalogs since it makes reference to them. Jose's post shares that Wesley Benn provided him with the text from What's New in Release 4.0 that show when type catalogs were introduced. Regardless, the point at which we choose one over the other family types or a type catalog boils down to preference.

As a daily user I don't enjoy interacting with Type Catalogs as much as I prefer them as a person who also makes content. If there are only five types in the family I'd probably be inclined to load them all to avoid doing it again to get the one I left behind. I also find that once users realize how easy it is to create a new type in their project, they are just as likely or inclined to do that instead of editing the family externally and reloading. If users start doing that the type catalog starts getting out of sync with the library. Keeping track of the flock can be hard on the Family Shepherd at that point, with strange sheep showing up in the fields.

I think that family types have a place and the rumors of their demise are greatly exaggerated.

Dept. of Subtle - Family Editor Parameter Lock

A recent exchange at the RevitForum.org reminded me of this subtlety. The Family Types dialog introduced the concept of locking a parameter.

You can select a reference plane and the dimension changes to blue like "normal" when the parameter is un-locked. When it is locked you can edit the dimension value by selecting the dimension, which is counter-intuitive because that's how we create a dimension override in the project environment. I believe the lock check box is "supposed" to lock out editing in canvas but they left a "back door" unlocked (pun intended).

It is easiest to see this in action so I did a quick video demo.