Which Phase Filter?

There are several phase filters that stock templates come with. Sometimes people aren't certain which ones to use or why they exist. There are three options that affect how elements are influenced by Phase Filters: By Category, Overridden and Not Displayed.

By Category - Project Object Styles and/or view's Visibility/Graphics Overrides govern.
Overridden - Revit will change the appearance of elements based on the Phase Graphics Overrides settings (see next image). Note that a Filter (View not Phase) applied to a view can still influence an element affected by a Phase Filter.
Not Displayed - Yes, this means elements are not displayed in the view.

What does it take for Revit to regard an element as being New, Existing, Demolished or Temporary? It varies according to the Phase of the view we see it in and which Phase Created and Phase Demolished parameters values are assigned to it. The following conditions define which Phase Status an element belongs to in a given view. For the following images assume this view is assigned to Phase New Construction and that we are looking at the Phasing parameters of four different walls.

New - Element's Phase Created parameter is assigned to the phase of this view and the Phase Demolished parameter is set to None.

Existing - Element's Phase Created parameter is assigned to an earlier phase than the phase of this view and the Phase Demolished parameter is set to None.

Demolished - Element's Phase Created parameter is assigned to an earlier phase than the phase of this view AND its Phase Demolished parameter is assigned to the same Phase as this view.

Temporary - Element's Phase Created parameter is the same phase as this view AND its Phase Demolished parameter is also assigned to the same phase as this view.

Any given element can belong to one of these four Phase Status in any given view according to the Phase parameter of that view AND its own Phase Created and Phased Demolished parameter settings. Phase graphics depend entirely on creating views for each appropriate phase and creating elements so they are assigned to the correct phase and then altered so their Phase Demolished parameters are assigned as required, if required.

Getting to the title of this post finally, each view has a Phase Filter parameter. What follows is my take on why I'd use each of the stock Phase Filters.

None - It's not a Phase Filter in the dialog, it's a choice in the list of Phase Filters within a view's properties. We use this when we don't want any Phase settings to affect the elements in the view. Everything is displayed according to either Object Styles or Visibility/Graphics Overrides.

Show All = This filter can't be altered or deleted. It means show us everything WITH Phase graphic alterations applied. NEW elements are governed by Object Styles (or possibly Visibility Graphics overrides) AND it overrides Existing, Demolished and Temporary elements. Use this filter to help see everything mixed together AND altered so each Phase Status is obvious. It is NOT a typical way of producing traditional documents but it CAN help explain relationships very well.

Show Completed = We're done! We don't want to see any graphical bias toward new or existing work, they should look the same. We don't want to see any demolished or temporary elements. We want to use this to show the finished design after construction is done. We could think of it as a view of "As Built" conditions if the model is kept current through construction.

Show Previous and New = We want to show new construction information in context against existing features but without Demolished or Temporary elements. This is ideal for New Construction views.

Show Previous and Demo = This is the filter to use for typical demolition documentation, existing features altered to show where demolition occurs. New work and Temporary work are not shown.

Show New Only = This is useful when we want to give a hint of future work. We can isolate and override graphics in a view to prepare a view for overlaying over another view on a sheet. When we overlay this on top of a new construction plan we'll see how they relate to each other despite the fact that Revit has no "future" phase.

Don't be fazed by phasing!

Copy Monitor Walls and Openings

I've mentioned in the past that we need to be careful using the Copy/Monitor (C/M) tool on walls when we use the option Copy windows/doors/openings.

When Revit examines the geometry of the family used to create the opening in the C/M'd wall it looks at the overall geometry to define the opening's size. That's usually not good because trim on the face of the wall does not define the opening required. The stock door families (and windows) are good/bad examples of this in action.

This is an opportunity to bring up another advantage of creating doors like described in A Door's Life, they behave when you use C/M. Why do they behave? There isn't any native geometry in the host door family. The frame, door panel, swing and hardware geometry are all based on nested families and the C/M tool doesn't "see" them when it creates the equivalent opening in the C/M'd wall.

Here's a comparison based on stock and not stock doors, in plan view.

The openings created from the stock doors are as large as the trim elements that surround the opening of the door (3" wide trim). The openings for the not stock doors as as large as the opening in the host family and all the nested components are designed to fit inside the opening that's used in the family. The nestedness of all the components prevents them from being detected by C/M.

Here's the elevation of the same doors.

Property Lines without Digital Reference

As a follow up to a related post last week this post describes how we can create a property line when we lack any digital data to use. The survey may be an old hand drawn document provided as part of the deed or it could just be a printed drawing that nobody can find the file for. While we wait for a new survey we can still start with what we have. We've captured some bearing and distance information from my old survey drawing.

When we have a CAD file we can import as a resource the Property Line tool option: Create by Sketching makes it pretty easy. Since that's not an option in this situation we need to choose the other option: Create by entering distances and bearing.

Take a moment to revise the project units so they show the same units as the survey data. It helps to confirm the values we see in the dialog match those we've entered (it's shown that way in the image, not in the video). When we enter values for bearing a space between Degrees, Minutes and Seconds is all that's needed. To advance from one field to another we can use the TAB key to move forward or SHIFT + TAB to move backward in the dialog.

Also note that if the distance and bearing information is accurate enough Revit will report "closed". If the data isn't then it won't be able to report "closed" or show the area of the property. Unlike many sketch based elements Revit will tolerate a Property Line boundary that does not close. I altered the distance for the last segment to show the following error message that appears.

Once the Property Line is completed, click OK and we'll find the element is "stuck" to our cursor expecting us to decide where to place it. We pick an arbitrary spot and then move it so a corner of the Property Line is at a corner of the building. The goal is to make it easy to use Rotate True North and define the angle between the current Project North position of the building and the side of the property we'd like it to line up with.

In this example we've decided that the side of the house needs to be parallel to the East property boundary segment. Now we can use Rotate True North. When the tool starts we need to choose where the Rotation origin should go. In this case we need it to be at the corner of the building, the same corner where the corner of the Property Line is now. The first pick is rotation origin, the second pick is on the building and third pick is on the property line segment.

The task is much easier when we put the Property Line right on top of the building as a frame of reference. It also allows us to define the angle without trying to determine what it actually is.

Now that the orientation is correct we can move the Property Line into the correct location/position. Adding dimensions makes it easier to be accurate. We need to double check the values to make sure the changes to one dimensional direction don't alter other dimensions inappropriately.

This is a video demonstration of the concepts with captions, no audio.

Creating Door Families

Long post warning!

I wrote supporting documents for two presentations I did about using the family editor and creating door families, they are:

Autodesk University 2005 Session BD21-1L: Autodesk Revit Building Family Editor: From the Beginning (using Revit 8.0) - Download It
Central States Revit Workshop 2013: A Door's Life (using Revit 2013) - Download It

I also wrote an earlier post here and shared A Door's Life as a Box embedded document.

I recently responded to questions about the techniques the older handout describes and then, as the thread grew, later criticism at RFO that my second document does not live up to their experience with the original. The following stream of consciousness is, for the most part, my reply there. I have rewritten parts of it so hopefully it makes sense here apart from the thread at RFO.

If you work through each document, or have already, the following describes what I experienced writing the newer version; why I didn't find it practical to just "refresh" the original, though I did start out thinking I could just do that. I started by opening the AU 2005 BD21-1L handout word documents and using Save As. Fwiw, that document was created using Word's Master and Sub-document concept (think Xref's for Word), each section is a separate document linked to a master for formatting, style setting and page numbering.

When I first started pondering (over 18 months earlier) what became "A Door's Life" I was thinking about a session for RTC in Europe. Coincidentally I received two suggestions via email within a couple weeks of each other recommending the AU 2005 handout should be updated. One even said he'd do it and submit it as a class for AU, asking if I'd have any objections. I wrote back that I didn't have any objections. I don't think he did it though, at least not that I'm aware of.

Reviewing the original outline I added the section about nesting hardware because its more common outside the USA to include hardware in door families (thinking about RTC EUR). I decided to remove the section devoted to creating the nested variable lite panel family with voids because, during the eight years of work and travel I've done since the lab at AU, I've never met anyone actually using it (until the thread at RFO). It's a relatively complicated and labor intensive part of the document too.

In its place I described creating two simpler nested panels, one derived from the first since that's how many firms actually end up going through the process. This also meant I could put the more relevant (especially in 2013 than 2005) clearance form (part of the nested swing) and hardware section in without increasing the page count too much. When CSRW submissions were requested I was already restructuring the handout (it is in imperial units) and I decided to use it for their workshop instead and took a different direction with the RTCEUR session. After a bit of reformatting it became a CSRW session and I finished it.

As such, the final form of A Door's Life is based loosely on the CSRW template, I started with it but I took some liberties. The AU 2005 BD21-1L handout is 48 pages and the font is primarily Arial 11 and based on the AU 2005 template. In contrast A Door's Life is 80 pages (3 pages are the Table of Contents, no ToC in AU BD21-1L) and uses the fonts; Calibri 11 and Cambria 10 (for lists). As a result the appearance is certainly different (see next image).

The tips (and additional comments) are a burgundy color to fit the color of the CSRW template graphics (see left image).

Doing the writing and editing I was immediately confronted with images of the Revit Building 8.0 user interface that included the Design Bar, Menu and Toolbars. When I finished the work I'd ended up replacing nearly every image. Even images that didn't need to be looked so out of place against the new interface that I often chose to replace them anyway. It's like remodeling a room that is connected to others. Improvements in the room make the other rooms look shabby.

There are also the feature and language changes from 2005 to 2013. Every instruction and description that referred to Design Bar tab, Menu or Toolbar had to be replaced with references to ribbon tabs, panels, buttons, properties palette, and other subtleties. There are also new, perhaps better, choices for how to offer some instructions, via right click, palette, view control shortcut bar etc.

There are changes in Revit itself like the behavior of the nested swing family. Between 2005 and present day the swing technique described in the 2005 handout doesn't work anymore. It's necessary to constrain it a little differently, the text of the old process had to go. The nested swing in A Door's Life has more features to describe as well. The clearance form section nearly takes up as much space as the panel/void section did in the AU 2005 handout. The clearance form describes a much more valuable lesson, in my opinion, about constraining sketches as well as the whole concept of clearance forms which isn't part of the original at all.

I think its worth mentioning that over eight years I've changed. I've been affected by the people I've met, taught and all the work I've done since. I've learned a lot more about Revit, this business, writing, editing, document formatting etc. I've done technical editing for two Revit books (beginning another now) and contributed chapters to two editions of another. My opinions and approach to writing and describing things has changed, evolved. I'm a different person than I was in 2005 and I learned a LOT from doing that lab too. I find it hard to imagine I could look at work I did eight years ago and be satisfied with "Save As"...and I wasn't. I also did not intend or expect either document to define a singular process to build "your" perfect door family. I hoped to describe the techniques that can be used together or separately to help organize anyone's own door library and all the concepts apply/extend to any other content easily too.

I closed my response in the thread with "I am grateful that you've found the original document useful and worthy of the praise, that it deserves to be updated. I won't hide my disappointment that you find the newer version not as worthy of your praise. I guess what they say about sequels is really true."

Railing without a Host

I wrote a post in July 2008 called Railing Over Wall, it was focused on this kind of condition.

This post revisits the same technique with 2014 and a different notion of a host element. The key to doing this is in the properties of the sketched line segments of the railing. This image depicts how three segments were created so they can be altered, each segment numbered 1-3.

These are the segment settings for #1, Slope: Flat and Height Correction: By Type.

These are the segment settings for #2, Slope: Sloped and Height Correction: By Type.

These are the segment settings for #3, Slope: Flat and Height Correction: Custom and 4'-0".

If we don't need a horizontal railing section at the top we can alter the sketch and use different settings for segment #2. If we do that these are the segment settings for #2, Slope: Sloped and Height Correction: Custom and 4'-0".

These are the two different sketch based railings side by side. The lower railing is missing its horizontal starting section. I just made the sketch of the first segment tiny so Revit would know what the starting elevation is. Without it I'd end up with a horizontal railing at 4'-0", aligned with the upper horizontal beam.

The line at the base of the railing is a tiny profile that is needed to host the bottom of the balusters. Without that bottom railing to terminate against they'd go to the lowest elevation of the railing (flat). I could offset the sacrificial railing so that it slips below the surface of the beam but in this case I wasn't worried about it. If you find it distracting this is what doing it looks like, though the balusters not finishing cleanly at the top of the beam may be more distracting.

Btw, the Beam Join tool was used to the get the beams to clean up.

Shared Coordinates and Worksets

Ordinarily we are not permitted to save changes to a linked Revit model. The lone exception is when we use Publish Coordinates. Any time we makes changes to a model that we've published coordinates to we are attempting to save a change to the linked file. For example when you publish coordinates for the first time you'll get this message.

When we get around to saving the host project file we'll be greeted with this message.

That message is the one that is indicates Revit is going to change data in the linked file. If this file is open by someone else already we'll be politely rejected, though the message is a bit oblique.

But then this message will likely appear right after you click Close for the previous message dialog.

Followed by a repeat appearance of the previous message, "Failed to open document". This means Revit couldn't save the change to the shared coordinates because the file is currently open (read only). This means to be successful we need to make sure nobody is working on the linked model, at least for long enough to let us publish or update the shared coordinate information.

When worksets are being used this changes because Revit can still reach into the file and interact with an individual workset instead, unless someone already is doing that. It is recommended to Import/Link a central file, not a local file. Users should not be working in a central file so it is less likely that publish coordinates will compete with someone. Local files are usually created on the user's PC. This means using Import/Link on a local file will likely fail to work for everyone on the team. We aren't usually mapped to user's computers for file sharing. Let's come back to worksets in a moment.

We'll get the following message when we decide to change the position of a linked model that we've previously used published coordinates on.

This gives us the opportunity to commit the change to the linked file immediately (click Save Now) or postpone that action till we are really done adjusting the link (click OK). Yet another message can appear if someone has changed the linked model since it was loaded or publish coordinates was used.

As the dialog suggests, Reloading the linked file will resolve the situation easily. If we are dealing with worksets again it is possible to have a similar message appear, related to the situation where other users have used Synchronize with Central recently.

This too can be resolved by Reloading the linked file, as long as we cancel the action. If we click OK then Revit will allow us to leave the modified linked file in its new position. After we reload the link Revit won't prompt to Save the new position, a quirky outcome. We need to use Publish Coordinates on the link again, we can just leave the location name the same to publish the revised data.

In the past we could find another user listed in the borrower column for the Project Information workset when someone used the Publish Coordinates feature on a linked file. With 2014 I find that Revit seems to be able to resolve this transaction more reliably. When I am working in my local file and another user publishes coordinates I don't find any other users listed against worksets in the Project Standards group.

To reliably publish coordinates to a linked model:

• If it isn't a workset project I need to
• ask any other user to save and close the file temporarily
• Reload the link (Insert ribbon > Manage Links dialog)
• Publish Coordinates 
• If it is using worksets I need to
• Reload the linked model (Insert ribbon > Manage Links dialog)
• Publish Coordinates

Detail Level and Interference Check

I've written a couple posts in the past (January 2012 and August 2009) about creating clearance elements for use with Revit's own interference checking. Toward the end of one post I mentioned incompatibility between using Detail Level settings with forms that are intended for interference detection.

I wrote, "Keep in mind that the obvious way to manage visibility by using Detail Level won't help us for now. Why? Detail Level doesn't work with Interference Checking, the solid has to be "visible". If we assign the clearance solid to use a specific Detail Level the Interference Check tool fails to see the solid at all even if we change the view to the correct detail level."

I continued, "The Bottom line, we can't use Detail Level to manage the visibility of clearance solids. We must use sub-categories or Yes/No parameters. Using sub-categories is a broader brush solution while Yes/No is more involved because you have to manage them at the family level. When we use these methods we can turn off the visibility of a clearance solid and the Interference Check tool will still find them."

All these years later the incompatibility remains.

We can re-use common forms for clearance families if we nest them into other families, they don't need to be "Shared" to work. We can use a different category element (for example Generic Model > Clearance) and it will detected as interference based on the host's category. Just don't use Detail Level settings to control the visibility of the nested clearance family either.

I also suggested that Autodesk standardize "Clearance" as it's own category. Alternatively they could establish a sub-category of Generic Model or even for all categories like they did with Hidden Lines (for Show Hidden). This way they could, at a system level, help us define what clearance elements are, how they are defined, what they should look like and how they should behave.

Somewhat related here's a May 2009 post I wrote about Design Options and Interference checking not working well together. It's still the same in 2014.

I wrote, "The Interference Check tool does not filter out results for elements assigned to various Design Options that "interfere" with one another. Keep this in mind the next time you are reviewing the results. You'll have a lot a "meaningless" collisions if you have any number of of options."

Stay interference free my friends!

Worksets and Project Browser Sorting

I've seen and heard claims that Revit passes changes to the Project Browser sorting along to the central file and therefore on to other user's local files during a Synchronize with Central (SwC).

In Revit 2012-2014 (all that I currently have on my PC) I find that "my" project browser selection does not transfer to other users during a SwC. I do find that anyone who opens their local file will inherit the "current" Project Browser setting.

When we use SwC Revit is storing the Project Browser sorting criteria but it doesn't alter any open local file's configuration. Occasionally I find that if I watch the Revit interface during a SwC that it looks like the Project Browser sort of "flashes" as if it is changing and then restoring "my" setting. I've also noticed that occasionally Revit's "focus" changes (highlights/bold) back to the "Views" heading, when there is a difference between my local and another local's setting.

Anyone that opens a new local file will inherit the "current" Project Browser setting. Current is based on the most recent SwC and that user's setting. This means we can casually change the Project Browser setting while we are working but new local files that are opened after we use SwC will inherit "our" Project Browser setting.

It might be considered polite to remember to set the Project Browser sorting to a "standard" one before we use SwC, at least if we are the last one in the office. It's not hard to pick the browser configuration I want instead once my local file is open and it doesn't really bother me to do so. It does annoy some people though. If a team is aware of this subtle dynamic they can decide how they want to deal with it.

Finish Floors and Doors

It's a fairly common practice to create separate floors for structure and finishes. The structural "layer" of a floor may actually be modeled by the structural consultant, assuming the structural engineer we are working with uses Revit and isn't working directly in the same model with us (architecture bias in this post).

Architects usually document floor finishes. Quite often I see this done as a Filled Region exercise. The effort required to sketch a filled region is not much different than sketching a floor boundary. The benefit of using a floor instead is that's it modeled and it will be available in many views, as needed. We can tag and schedule them to study and document the design more effectively. External applications like Revolution Design's Revit Workflows offer a specific set of tools to manage creating finish floors very effectively. KiwiCodes offers their own version as part of their Bonus Tools app. These tools make the notion of using finish floors that much easier to consider.

One side effect of modeling finish floors is that they can compromise the door graphics we use, for example the panel and swing we are used to seeing in plan views. This happens because these graphic features are usually created on the work plane of the host level. The other issue is that, even if the floor doesn't obscure the graphics, the door panel, if just lines, probably won't mask the floor finish fill pattern (if one is used).

If we create a masking region (or lines) directly in the door family, to represent the door panel it will mask the floor finish as long as the Draw in Foreground parameter is checked.

Quirkiness ensues if a nested family is used. I happen to prefer to deal with swing graphics as a nested family. My logic is to make it once and use it in many families; a "kit of parts" mindset. Unfortunately the Draw in Foreground setting fails to work when the nested component is brought into the host door family.

To resolve this we need to make it possible to raise the graphics higher. Filled and Masking Regions can be assigned to a Reference Plane; Model and Symbolic lines too. This means we can use a parameter to change the elevation of the graphics, via the parameter and associated reference plane, to compensate for various floor finish conditions. The setting Draw in Foreground will allow this to work as long as we don't check it, which seems counter-intuitive.

In this image I've use the Draw in Foreground setting on native lines and masking regions, not checked on the left and checked on the right. I've also nested a swing family. The red elements are visible and the highlighted (purplish) are not visible except that they show up because I've got my cursor hovering over the family.

To get the nested swing family to show up above the floor is was necessary to not check the Draw in Foreground parameter for the masking region and lines. It was also necessary to place them on a separate work plane in the family that I could control with a parameter to raise it above the floor elevation in the project.

In the image above the only graphics that don't show up now are the bottom left line and masking region. They won't show up because the Draw in Foreground parameter is not checked. It's easy to sort out once you know.

Speaking of 3rd party applications, I used the Revolution Design tool to create floors for my testing. The app coughed when I tried to put in some floors. After looking at the error message I noticed that the doors I was working with don't map a value to the stock Width parameter, they use their own parameter to control the width. This annoyed the floor tool because it's looking for that parameter, the stock "Width". It's hard enough for programmer's to create applications that suit our varied needs. It's even harder when we create content in a different way than what they might reasonably expect in order to complete their tasks.

At first I was a bit confused but then I remembered that their floor tool will create a sketch that turns into door openings to define where the edge of the floor will stop for thresholds. The application looks at any doors it finds along the boundary of the room and creates a sketch based on the door Width parameter it expects to find. In this case the value was zero width and that made the application mad, Revit too. It was easy to fix. I just used a formula in the Width parameter that mapped it to the parameter these doors were using instead. Just another subtle thing to consider when we make content.

Workset Visibility and Linked Files

In October of 2010 I described a technique we could use to control the worksets in a linked file without having to go through the Visibility/Graphics dialog and the Revit Links tab followed with numerous options for overriding things.

Over the years things change and it appears that is true for this technique now in 2014 (possibly earlier releases). It appears to be better or at least more reliable to decide which worksets to close or open via the Manage Links dialog directly or the right click > Manage Links option when you select a linked file in the Project Browser, like this:

This came about because a member at RFO was describing erratic behavior while trying to use this technique. It would behave as expected when he turned off some other workset's visibility. I found that to be true but less specific about visibility as much as interacting with something local as well as the linked file. Bottom line, I get predictable results if I use the above method instead.

EQ Constraint without EQ

Another question via email: "I want a column that can be defined as equal width on either side of its center line but occasionally I'd like to be able to make it unequal. Is there a way to toggle on or off the EQ (Equality) constraint in a family's dimension from the project?"

It isn't possible to toggle on/off the behavior of the EQ constraint when we apply it to a dimension string. If we ignore that feature we CAN define two parameters for either side of the center line of the column and when we need them equal we can supply the same value to both. When we need it to be unequal we just provide different values. Same result, just a different way of looking at the problem.

Here's a mockup, one way to tackle it, I'm sure there are other ways, other assumptions we could make. In the first image the Equality requirement is "OFF". The conditional statements in the formula column evaluates when the "Make Equal Width" parameter is on or off and the "Width Primary Side" parameter provides a value to define how much the inequality should be, based on a notion of primary side and secondary side width values. We subtract the "Width Primary Side" value from the "Width" parameter to shift the column over.

This next image is based on the "Make Equal Width" parameter being "ON" and we divide "Width" by 2.

Soffit Conditions

I received an email the other day asking for my opinion about modelling soffit conditions. In this particular case they used a thick wall to wrap a steel beam but then worried about the results when using clash detection later between the wall and beam. Since they overlap one another it would be a clash. Determining what constitutes a valid clash when modelling and who is modelling and then doing the clash detection is a deserving topic on its own.

My response is that I prefer to "model it like we build it" as much as is reasonable or possible. In this case I'd take this approach. I'd model the ceilings, one type on either side of the beam and another for under the beam (assuming "hat" channels for structure). I'd use a separate wall type (also assuming "hat" channels for structure) for the soffit "wall" so I could adjust where the gypsum wall board started and stopped.

Here's a section view.

And a 3D view.

In early design I could probably just get away with creating the ceilings and add the walls later when sections were needed.

Filter Criteria Order Matters

Taylor wrote to me to say that he noticed a subtle quirk when he wanted to filter pipe in a schedule. He needed to focus on Mark values that contain M15 and M16 for example. He discovered that the filter would work if he put the criteria in that order but that if he happened to reverse them like this, M16 and M15, Revit no longer found the M15 pipes.

Definitely subtle.

Schedule Linked Files

We can schedule elements that are in linked files but there isn't a schedule that is only interested in telling us what linked files there are. We can determine which files are linked easily enough while working inside Revit. What if we want to document what files are linked into our model and include this information on a sheet? We can take advantage of the addition of Grids and Levels as elements we can schedule in Revit 2014.

If we assume that all projects will have levels and probably grids a schedule that is assigned to one of those categories can be manipulated to look like it is just a schedule of linked files. Then we can combine that with a Starting View if we want to see it each time our project is opened. Add the schedule to a general information sheet and it can be part of our documentation too.

I created a schedule that includes the fields for RVT Links and at least one for Grids. In this example I used Grids to drive the schedule but Levels are probably a better choice.

When we load a linked file we can supply a unique "Name" value. When we use Reload From or Reload later to update the model we can revise the "Name" parameter to show the current version/date.

Make a custom titleblock family and add the Project and Client related parameters as desired. Load the family and create a new sheet using this special titleblock. Add the new schedule to the sheet. To use this as a starting view activate the Manage ribbon and click the Starting View button. Choose our special sheet view as the starting view.

I used the Clear Cell tool, new in Revit 2014, to remove the link between the schedule name and the header text. This allows us to call the schedule something meaningful in the project browser and show something else in the header of the schedule on the sheet, as shown in the first image in the post. Since schedules can be on any number of sheets it is an easy matter to place it on additional sheets if desired.

A Doors Life

As I mentioned in an earlier post I presented a session called "A Door's Life" at the recent Central States Revit Workshop. It tackles creating a host door family that nests 2 panels, 2 frames and 2 handles. It also features a nested clearance form for clash detection and a variable plan swing angle. The host door permits rotating the 3D panel and hardware to any angle as well, though 0-180 is probably the range that's most useful.

If you are interested in more information this is the handout that attendees received (embedded here).

As the handout will tell you it isn't meant to be the perfect door. It's a demonstration of concepts and how to put them all together. If you're lucky you'll end up with something you can use right away or at the very least have a good idea how to get where you want to go.

Click to Download the completed files for each exercise.