I think that Jeff has it backwards.  In my experience the newcomer to Revit wants to lock everything.  I think the initial instinct is to not trust Revit and just lock things down.  Later when this user tries to change something they get a string of messages telling them constraints aren’t met and they end up getting frustrated and removing all the locks anyway.

I’m sure Jeff would argue that the Revit Expert knows how to use locks properly.  I would agree that as you experiment with Revit you learn when to lock and when not to lock.  With Revit family creation that time is only as a last resort.

So what to do instead of locking?

1. Reference lines and planes:  Hosting and aligning geometry to reference lines and planes automatically creates a strong connection between them.  The link isn’t quite as strong as a lock, under some conditions it will detach.  But for most purposes it works just fine.  Align geometry to a reference plane and flex your model.  You’ll be surprised how often this works.  Carl Gibson has a great overview of the types of Reference lines.
2. Parameters:  Instead of locking a dimension to a fixed dimension assign a parameter to it.  Using parameters gives you flexibility to easily change things later, and more importantly it lets the user of the family know what’s going on inside it without having to edit the family.  For example, create a a parameter called Table Thickness and give it the formula 0′ 2″.  This tells the user that the Table is 2″ thick and locks it from changing.  Note that locking a parameter with a formula locks it across all types in the family.

Locking does have it’s place, but I always try to make a family work without locks first.

Still, you can build some functionality into your families to ensure that a value never exceeds a specified range or create warnings for the user of your family.

Lets start with a simple example.  In the plan view below I am showing a basic table.

Lets say in this example that we never want the table’s width to be greater than 1/2 the depth.  We have a few choices.

1. Don’t do anything
2. Display an error message for the user
3. Default to another value

Don’t do Anything

By default your parameters allow the user to input any value they want.  You can set up relationships between parameters using formulas but the results are still dependent on user entered values.

When creating families it’s good practice to set up the basic types that you expect the user  will need.  This will limit the amount they need to edit the parameter values.  Understanding when to use instance versus type parameters will also limit problems in the future and make the family easier to use.

A well designed family should be clear and easily understandable by someone other than the person who made it.  Some things I look for are:

• Model geometry is hosted to reference plans and lines that have meaningful names
• Well named parameters grouped under the appropriate categories
• Parameters are assigned to the geometry in a logical sequence
• Model and dimension locks are kept to a minimum

Even in a well designed family there will be times that a user will be confused as to why a model is breaking, or there are conditions that must be met to keep the model valid in the real world that must be maintained.  For example, a manufacturer won’t make a table longer than 8 feet long.  With the default model there is no way to tell the user that 8 feet is the maximum length or provide clarification as to why the model broke when value “x” exceeded value “y”.  So what can we do?

Display an Error Message

The easiest thing to do is to give the user a message.  Start by creating a text parameter, I placed my error message in the Text category so that it’s at the top of the Family Types browser.

Back to our example of not wanting the table’s width to be greater than 1/2 the depth.  To alert the user to this we create the following formula for our new text parameter.

=if(TableWidth > (0.5 * TableDepth), “TableDepth”, “OK”)

Notice how I am mixing parameter names, numbers and text strings?  Pretty cool right?  If our table with is greater then half the table depth then the user gets the message “TableDepth”.

Of course in the real world you give a more descriptive message like “Table width can not exceed half the depth”.  But I wanted to make sure the formula fit in my screen shots.

If the Width is less than half the Depth then the user gets a simple “OK” message.

I really like this technique.  You can create nested error messages to handle different scenarios too.

=if(TableWidth > (0.5 * TableDepth), “Table is too wide”, (if(TableWidth < (2′-0″), “Table width must be greater than 2 feet”, “OK”)))

Default to Another Value

The guys in my office will point out that this option can be annoying because it overrides the value the user inputs and may cause confusion.  Sometimes inputing a value out of range will break a model completely so this method is necessary to prevent that from occuring.  I recommend using this method in conjunction with the error message to let your users know what you did when they weren’t looking.

In order to build this functionality you need to add some complexity to how your family is structured.  In the examples above the parameters were directly linked to a piece of geometry.  We need to insert some logic between what the user inputs and what the model does.  To make this work we create an additional set of parameters.

The parameters under the Dimensions category are what the user modifies however the parameters under the Analytical Model are what actually control the geometry.

Now we have some flexibility to insert control logic.  We can now assign the following formula to TableWidthActual.

=if(TableWidth > (0.5 * TableDepth), (0.5 * TableDepth), TableWidth)

This formula checks the values the user entered for TableWidth and TableDepth.  If TableWidth exceeds half the depth then the formula ignores the user entered width and defaults to half the depth.  Otherwise the formula passes the user entered width through.  (NOTE:  The formula in the image below is incorrect)

The ability to control the values your users enter is powerful.  Use it with caution, and like I said earlier, creating an error message like this is helpful.

=if(not(TableWidth = TableWidthActual), “Your width was changed because it was too big”, “OK”)

If you have any questions leave them in the comments.  Thanks Faekk for the inspiration for this article.

I do some pretty advanced stuff with formulas, but we need to get the basics under our belt first.  Most of this post is from the Revit Help files.  To save you the trouble of looking it up, I’m putting it here.

Basic opperators:

Conditional Statements

Some Extra Stuff

• Revit allows you to use integers, decimals, fractional values, and parameter names in formulas.  You can enter dimensions in feet and inches just like you do in dimension strings.  Remember that parameter names are case sensitive.
• You can enter a value in a formula essentially locking it across all types.  This is an alternative to locking the dimension in the model.
• Instance and Type parameters can not be used in the same formula.

Initial Setup and Naming of Family Parameters

One thing that Eric didn’t cover in too much depth was naming and grouping of parameters.  I also use Eric’s programming syntax method for naming parameters except I usually capitalize the first letter.  It doesn’t make much difference really, I just like the look of it in my parameter list.  For example, “WindowTrimWidth” instead of “windowTrimWidth”.  Although Revit supports parameter names with spaces, I think having your parameters as one “word” makes writing formulas easier.

The first thing I do when setting up a new family is place all of my reference planes, dimensions and parameters.  I flex the model with the reference planes and make sure it works.  If it does then I’ll start modeling the geometry.

When I first add parameters I don’t write out the whole name for parameters that I know will involve some calculations.   Sometimes formulas can become quite complex:

if(and(LoopOne, LoopTwo), DepthDefault, if(or(LoopOne, LoopTwo),DepthDefault- DepthBikeLoop, Diameter))

Make one error in typing this out and you have a hard time debugging it.  I start with naming my parameters with shortened names like LO, LT, DD, etc.  This makes the structure easier to see.

if(and(LO, LT), DD, if(or(LO, LT), DD – DBL, D))

Once I know everything is working I rename the parameters and they are automatically updated in my formulas.

Grouping of Family Parameters

Currently Revit only allows us to categorize parameters in a set list.

• Analysis Results
• Analytical Model
• Constraints
• Construction
• Dimensions
• Electrical
• Electrical – Lighting
• Electrical – Loads
• Electrical Engineering
• Energy Analysis
• Fire Protection
• Graphics
• Green Building Properties
• Identiy Data
• IFC Parameters
• Layers
• Materials and Finishes
• Mechanical
• Mechanical – Airflow
• Mechanical – Loads
• Model Properties
• Other
• Phasing
• Photometrics
• Plumbing
• Rebar Set
• Slab Shape Edit
• Structural
• Structural Analysis
• Text
• Title Text

I’m glad that Revit doesn’t let us customize this list, it would just complicate things even more.  Eric reminds us to “choose a pertinent parameter group for your parameters,” but what does that mean?  Really, it depends on your office.  I would recommend creating a standard.

I discourage the use of the “Other” category because it ends up being a trash bin holding everything.  ”Dimensions” is obvious, but I only put parameters in this group that are relevant to the user of the family.  I use “Analytical Model” for any behind the scenes calculations or dimensions that the user of the model doesn’t need to bother with; unit conversions, dimension calculations to keep the model from breaking, etc.  I have also seen “Model Properties” used for this.  If I have toggles for the visibility of different components I put those under “Construction“, if I have a toggle for something that is graphical only, like in an annotation family, I put that under “Graphics“.

Tomorrow we will look at using formulas in families.

Default Revit Sections Are Flat!

There are two tools that you will use to make this happen, Visibility/Graphic Overrides and the Join Tool.

I think the reason that you would try to used filled regions to poché walls is because you don’t fully understand how Revit displays objects.  Revit uses a hierarchy of graphic settings to determine what to display.

On the most general level are the project’s Object Styles.  You reach these by going to Manage -> Settings -> Object Styles.  I could write a number of essays on what you can do here, but right now we will just focus on the Walls category.  The main walls category by default has 3 sub-categories.  For these 4 category/sub-categories you can set the line weights/color/pattern for projection and cut views as well as the default material.  This is where we could bump up the line weight for cut walls to make our elevations read clearer.

Using Material Cut and Surface Patterns

The category parameters are where you will want to define the defaults for your project.  Materials definitions allow you to define a Cut Pattern.  In a default project walls have no fill pattern, so in your section your walls will have a white fill when printed.  If you had a masonry wall you might want the cut pattern to reflect that.  Material patterns can be a lot of fun as I show in the screenshot to the right.

Revit offers a lot of control over what is displayed.  So far we have just discussed project wide settings.  The next level is view specific.  Each view in Revit allows you to override these general settings.  You might for example want your masonry cut pattern to display in a detail view or large scale sections, but for design presentations or small scale sections you want to override those patterns and show a solid color poché.  That’s where Visibility/Graphic Overrides come in.

To access Visibility/Graphic Overrides use the key shortcut “VG” or right click and select View Properties, then edit V/G Overrides from there.

Visibility / Graphic Override Dialog

The V/G Overrides dialog looks like the Object Styles dialog except it has an extra tab “Filters.”  (I’ll discuss filters in a nother post)  Remember, the changes we make in the V/G Overrides dialog are specific to this view and Object Styles are the defaults for your entire project.  This is where we can create our view specific poché.  Click the Override under Cut -> Patterns then select a solid pattern fill and set the color for the fill.

Building Section With Wall Cut Pattern override

Now, we’re getting closer, but some designers like to have a monolithic look to their sections and not see the divisions between foundation, floor, walls, and roof.

The Join Tool

This is an easy fix with the join tool!

Using the Join tool, join the walls floor and roof

After the join tool things look much cleaner.

There we go.  This section is looking a lot better and it will update when move, add, or remove elements.  The one thing that may require some touch up are our element joins.  New elements will need to be told what to join with.

Don’t forget to save these settings to your view and project templates!

Finished Section