QC Sheet

I absolutely love schedules. I often create working schedules to check for errors or completeness of our model. Rather than opening every schedule, I had this idea to create a QC sheet where all these schedules can quickly be viewed from one single place. From there, I can edit the schedule and make the necessary corrections. The sheet is assigned to its own category, and set to not appear in sheet lists.

Over the length of the project, I have created over 30 schedules that check properties of sheets, views, keynotes, generic annotations, walls, sheet notes, rooms, doors, travel distances and even structural usage of CMU walls. This turns out to be really handy for daily maintenance, but especially in those last minutes before printing.

My approach with these schedules is to filter out those elements which are in compliance and thereby exposing those that are not. This makes it pretty easy to check, since the end goal is an empty schedule. For example, my current project only allows the use of fire rated gypsum board; however, imported typical details may be using regular gypsum board. A simple Keynote Legend can list any instances where regular gypsum board is keynoted. From there, by selecting Highlight in Model, I can find and correct any culprits.

Here are some other examples:

• Unreferenced keynotes (a value is assigned, but no matching description can be found in the keynote txt file)
• Blank keynotes (a keynote is placed, but no value is assigned, leaving just a question mark)
• 000000 keynotes (when placing a keynote, the user doesn’t always know what to assign. When ‘Ok’ is hit instead of ‘Cancel’ the first value is assigned)
• Rooms (any room that’s not properly enclosed, or isn’t placed)
• Sheet notes containing an incomplete reference (as a company standard, we use underscores to indicate unknown characters. For example “Refer to sheet AE-1.___”
• Sheets missing important parameters
• Egress paths exceeding maximum travel distance (we use railings as so many bloggers have posted about)
• Generic annotations with blank parameters (one noteblock schedule per parameter)
• Working Views placed on a sheet (we use a custom parameter to distinguish between printing views and working views)
• Printing Views not placed on a sheet

In addition, I also set up general information schedules:

• Door types used (this is a good way to make sure our legends show each type used)
• Door frame types used
• Door fire rating (to confirm the fire rating still matches the family type name)
• Window types used
• Wall types used

I’d be interested in hearing your uses of check-schedules.

Ghosted Background Linework

I was asked if elevations had the ability to automatically grey out elements that are farther away from the front plane. Unfortunately, there isn't a simple way to accomplish this just yet. The Linework tool allows us to manually overwrite linestyles, but this is an impossibly slow process when dealing with linked models (easily up to 10 seconds per line). With the amount of elevations we're working with, this is just not a feasible approach.

As a solution, I created a parametric rectangular detail item with a solid white region which is stretchable directly in the view and has the ability to show or hide a border.

Edit: this can also be done using a filled region, but this won't have the ability to quickly turn the border on or off. However, filled regions are more flexible for custom shapes.

When loaded into the project, the Type Mark is set as 'Transparent Mask' which allows us to easily set up a view filter.

Once we add this filter to our interior elevation view templates, we can adjust the transparency to 50 percent.

Place the mask in your view, align & lock as needed and we're done! With Revit 2013's improvement on view templates, this was an easy implementation and will definitely be added to our project template.

Sample with border shown and hidden:

Legends are Optional

Legends are great for a few reasons, but they're not so great when it comes to tagging elements in the true BIM sense. They can hold families, text, detail lines and dimensions, but when we want to add a real tag to our legend, we're stuck with dummy text.

To resolve this, some firms would create elevations of a host wall with doors and windows on a separate workset. This works fairly well; the workset can be turned of so no elements will show in any views, except for schedules where custom filters are needed to hide the legend families. Another approach is to use phases, but we have to be really careful how this is set up. Changes in Phase Filters could possibly reveal the legend families in our schedules. Neither options are fool-proof.

A safer way to create a true Legend is to use Design Options. For this to work, we'll need a dedicated Option Set with two Options, of which the primary option will remain blank. Any legend families and hosts will be added to the secondary option, and placed somewhere in the distance.

With the creation of a Design Option, the Visibility/Graphic Override dialog box now has a new tab which allows us to set which Options should be visible. By default, this is set to Automatic, which means any option that is currently set to be the Primary Option.

Since legend families and hosts are added to the secondary option, none of them will show up in a schedule. If desired, for purposes other than legends, design options can be included in schedules in the schedules' properties.

Now we can create a floor plan (working view) and elevations (legends) set to show the secondary option, and look... we can tag our families!

Project Set-Up Sheet

A recent addition to our template has been the creation of a project set-up sheet. In short, this sheet is set as the project starting view and contains only a titleblock with all possible project related parameters, such as project name and number. This creates an overview in which we quickly fill out all significant information at the start of a project, which can be reviewed for completeness before printing.

Sometimes, Revit by default has provided us with instance parameters which we decided to replace with our own instance parameter assigned to the Project Information category. Drawn By and Check By are good examples of this, where changing this parameter had to be applied to all sheets individually. Since we've now assigned these to the project, as an instance parameter, one changes applies to all sheets.

The following is a list of all parameters currently included:

     - project name (line 1)
     - project name (line 2)
     - project description (for example: new construction, interior remodel ...)

     - location
     - client name
     - parcel id #
     - property description (legal description)

     - project #
     - drawn by (not the default instance parameter provided by Revit)
     - checked by (not the default instance parameter provided by Revit)
     - issue date
     - sign & seal date
     - sign & seal area (for example: "not for construction" or "for review only")

     - template - created on (tells us which template a project was started with)
     - template - last saved by (only two people are allowed to edit the template)

     - revision schedule

Most of these parameters are embedded in the titleblock as would be expected, whereas others are placed on the cover sheet, where we use a non-conventional but flexible technique to show them. This will be a post for later though.

For the revision schedule to show all submissions, we have to either draw a revision cloud for each submission, or edit the 'Revisions on Sheet' property, which is my preferred option.

One last thing, in the sheet's properties, we assigned the sheet its own unique Sheet Discipline and unchecked the 'Appears in Sheet List' check box, which pretty much makes this an invisible sheet (in schedules).

If you have any other thoughts about this setup, or if you can think of other parameters to add, I'd love to hear them.

Tags!

Templates are most successful when the simplest of tasks have been taken care of from the start and guesswork by the user has been reduced. Nothing is simpler than loading and setting up of all tags, and you won't get annoyed when you're in a time crunch and Revit asks you to load a tag.

If you're wondering what tags have been assigned, the Loaded Tags task dialog (shortcut: LT) will list all tags assigned to be used for each element category. A simple drop-down list lets you select the default tag family to use. As you develop your template, remember to keep this list up to date.

Annotate > Tag pull-down > Loaded Tags

To be consistent, we've named all of our tags based on the following principle:

- our company's initials, so foreign tags are easily distinguished
- the word 'Tag' so all tags stay grouped together in the family browser
- the family type being tagged, for example: door
- suffix: to separate two tags for the same family type used for different purposes. For example: doors tagging basic information vs life safety information

For example:

        XYZ Tag_Area

        XYZ Tag_Ceiling

        XYZ Tag_Door

        XYZ Tag_Door (ALS)

        XYZ Tag_Floor

        XYZ Tag_Furniture

        XYZ Tag_Grid

        XYZ Tag_Keynote

        XYZ Tag_Plumbing Fixture

        XYZ Tag_Revision

        XYZ Tag_Room

        XYZ Tag_Room (ALS)

        XYZ Tag_Wall (Fire Rating)

        XYZ Tag_Wall (Type)

Once loaded into the project, you'll want to add a leader arrowhead for each type of that tag.

Select the tag > Edit Type > choose Leader Arrowhead:

If you don't find an arrowhead you like, you can edit an existing type or create your own; Manage > Additional Settings > Arrowheads. Our standard arrowhead is the Filled 15 Degree Arrow, but we also use Heavy End and Filled Dot.

Template Mentality

Recently, I visited another firm's office for the monthly Revit User Group meeting, where our host started a new project based on their template. Of course, I paid close attention to their setup in the hope to pick up a thing or two, and one of the things that struck me as odd was that they only had a single plan view set up. This lead to a conversation on template setup and mentality during the break, and it turned out we have complete opposite template mentalities.

Their thought was that for every new project, it's pretty easy to create new views, whereas our mentality has always been to set-up just about everything so no guess work is needed and no time is wasted setting up view after view, changing view names & title on sheet, adjusting phases, applying view templates, checking settings... and wondering how it was done last time. Out of the box, our project template has every type of plan view, for each phase and level with a consistent setup that every body is familiar with. All that's left is to get started on the model.

Some people may say it's just too many views, or not all are needed. That may be true, but it's actually a lot faster & easier to delete those unneeded views than it is to create those you do need, which is a philosophy carried throughout our whole template.

Contact Information

I truly dislike to do the same task twice if I can avoid it, which is a great mentality when you're setting up a template. Something that was bothering me was filling out the contact information for our consultants on the cover sheet for every new project. Initially, we used plain text in a legend, which works but it was tedious, and not my favorite way. I decided to go about this the BIM way.

I created a generic annotation family with several contact information parameters. The area on the right is for company logo's.

For each contact, a new type was created. Don't forget to add a type for your client/owner. To sort them, I prefixed the company name with their discipline:

To get the logo's to automatically switch, I created a separate generic annotation family for each logo and assigned a visibility parameter for each in the contact family. Within the contact family types, all it took was to check the matching visibility parameter.

I placed several instances on our cover sheet, and set up our most frequently used consultants as the default contacts. Using a different consultant is as simple as selecting a different family type.

If it wasn't for the logo's which have to be placed manually, this could all be set up using family type catalogs and a contact database. This would make the family smaller, but we like the logo's so for now we'll keep them.

This technique works especially well if you use the same consultants/client on a regular basis. We've been using this family for over a year now. No time is wasted & new contacts are added easily = better template.

Sheet Notes Follow Up

Quick follow-up on the sheet notes.

Since each set of sheet notes is a schedule, we could potentially end up with a lot of schedules and so I prefer to name them all 'Notes - category name'. This nicely sorts and groups all of our schedules in the Project Browser, but it doesn't read so nicely once we print our sheet.

For instance, 'NOTES - DEMOLITION' would read a lot nicer if it said 'GENERAL DEMOLITION NOTES'.

Luckily, Steve Stafford at Revit OpEd posted a nice workaround to create a custom header while maintaining a smart naming convention in the Project Browser. The result is identical.

6 - Sheet Notes

I guess it's been a while since my last post, and I was beginning to feel quite guilty for starting something and not following through. Just don't hold your breath for daily posts.

For the longest time, our template used legends for general sheet notes. This worked fairly well since legends can be placed on multiple sheets and a single update affects all instances. However, our new approach is one that has greater advantages, especially for larger projects.

We created a generic annotation with three instance parameters: Grouping, Number & Text. Together with some linework, this creates a 'physical' placeholder for sheet notes within the model. Some notes are longer than others, so we've allowed plenty of room within the annotation family to accommodate long bits of text.

Once loaded into the project, a drafting view will hold all notes.

Each column represents a Grouping. For each, I've created 30 notes, most of which are blank.

Using a NoteBlock, we can now schedule every instance of this family. We'll sort by Grouping & Number. This schedule is the easiest & fastest way to make edits to notes.

We'll now duplicate that same schedule and use filters to narrow it down to a specific category & to hide blank notes. The '99' filter is used to hide a note from the sheet, while keeping it in the project. This way, for whatever reason, it can be added back easily. Any noted filled out in our main schedule will append automatically.

After some tweaks to the schedule's formatting, the end result looks about the same as our legends from before, but the advantage we now have is that these notes are parametric and therefore schedule-able. And since they are schedule-able, they are also searchable. Large projects can contain hundreds of notes, and having the ability to filter them in a separate working schedule based on a specific word or series of words is invaluable. It certainly has proved its worth already.

Edit: I created a follow up post here.

5 - Notes to self

Something quick today... our template has evolved into a well-oiled machine, but there's a lot to it, and sometimes we need to add some instructions or reminders to make sure we don't forget anything. We do this with a dedicated region and text style in a color and font that really stand out. A quick little note or a colored region often helps out; for instance a code reference or a choice to be made between multiple options.

The below image is part of our code analysis and has a bunch of notes, code references and regions where a value is to be updated. Shown here, you'll find plumbing calculations for male/female vs unisex facilities, and their code requirements.

In this case, we also started making snippets from the Florida Building Code for easy reference. Once used, they can be removed from the view, but keep in mind, this isn't recommended for all situations. (below: FBC Table 403.1: minimum number of required plumbing fixtures)

The Project Scope section by default has a series of possible scope items. At this point, it's pretty easy to quickly delete those items that don't apply, and add those that are perhaps more unique to the project. This has been part of our template mentality from the start, as it is (often) easier to delete what's not needed, then to set up that which is needed (when you might be short on time).