Thursday, 8 August 2013

Parameters Part 4 - Schedules

This is the fourth installment on Revit parameters which I consider to be the i in BiM. Part 1 introduced the concepts of parameters and the types available. Part 2 showed how drawing information such as walls and doors could be manipulated in views based on parameters to convey fire strategy information. In Part 3, I showed how parameters can be included in tags which conveys scope on general arrangement and detail drawings.

Part 4 will deal with schedules which are a useful means to communicate and compare large amounts of data. The Revit model is a database with a graphical front end. Because of this, when values are updated in objects, they are immediately updated in schedules and vice versa (bi-directional) as the graphical objects and the schedule data are one of the same. There some limitations as graphical information such as placement and direction of objects is not easily scheduled and generally better conveyed through drawings. Revit schedules are a significant improvement on spreadsheet schedules though. While spreadsheets provide very useful tools for filtering and sorting data, the disjoint with the graphical data requires significant effort keeping the information coordinated between drawings and schedules. With reduced fees and timelines, design professionals often complain about how labour intensive the industry is. If there was one sure fire way to reduce time and effort, schedules in Revit are the low hanging fruit.


I am going to use the sample project provided by Revit which is available here. Schedules are available in the Project Browser. Revit comes with some sample schedules which you can customise or delete as you wish.

Continuing on from my example of the Fire Performance parameter from earlier posts, I will make some changes to the Door Schedule. I used Fire Performance to identify the fire performance required by my Fire Engineer. I also have door types which include a Fire Rating. I want to ensure that the door fire rating meets or exceeds the performance required by the Fire Engineer. Fire Rating is an in-built parameter and as it is associated with a Door Family, it is a type parameter i.e. all doors of this type will have the same fire rating. My Fire Performance value is an instance parameter as I purposefully made it so.

Double click on Door Schedule to open it. The door schedule includes some basic fields which you would expect from a door schedule.

On the Properties window, you can modify the contents and look of the schedule by editing the Fields, Filter, Sorting/Grouping, Formatting or Appearance.

When you click on any of the Edit buttons, the others will be available in the tabbed dialog box also.

As this post is focusing on parameters, I am going to ignore formatting and concentrate on Fields and Filtering. Revit offers the fields which are appropriate to the family being scheduled. In the case of doors, all fields for doors are available. As doors lead to and from rooms, Rooms are also available. It can be useful on a door schedule to know which room the door belongs. Rooms also contain a field for Level which allows the floor level to be included also.

If you are using my sample model and shared parameters file, you will notice that Fire Performance is available. Select it and add it below Fire Rating. Click OK to apply the changes.

In my sample project I assigned fire performance ratings to 4 doors. As the Fire Rating for these door types under performs, I either need to upgrade the rating for this door type, select another door type or create a new door type based on this type but with a higher fire rating. Clearly I would need to complete the exercise of including the fire performance for all doors before I could make this decision, but I now have a very good means to check this information.

Visually scanning for discrepancies can be tedious and prone to error. Here is where Filters can help out. On the filters tab, select Fire Performance equals FD30 and Fire Rating does not equal FD30.

Now we have a list of doors which do not match the Fire Engineers criteria.

This may seem simple but when dealing with large amounts of data, filtering can be a quick and effective means of validating data. The above example relates to one piece of information about doors but this process can be used for any objects that can be scheduled including floor finishes, sprinkler heads, furniture, equipment, etc. A similar example to the door fire rating example is slip resistance for floors. You want certain areas to achieve a higher slip resistance performance and it is useful to filter out all finishes that don't achieve this resistance.

You are not restricted to the parameters that come with Revit. I have used my own shared parameter named Fire Performance.


Consistency in information is important. Notice in the filter that I compared a Fire Performance of FR30 with a Fire Rating of FD30. These are different values but I know they both mean a fire rating of 30 minutes. I would be better if the codes used were consistent. I also tend to use codes where I can rather than relying on loose English e.g. '30 minute rating' or '30 minute' which are 2 different values to Revit Filters.

Consider parameter values when creating families such as doors. If you are creating a single swing 20 minute fire rated door, use a consistent value for the Fire Rating parameter.


Scheduling parameters is quite straightforward but with a little effort at achieving consistency in the data, filters can be used to do some heavy work associated with validating large sets of data.

In the 4 posts I have covered the basics of parameters and how you would use them practically every day. The next post will delve into advanced features such as data types and advanced filtering.

1 comment:

  1. Excellent posts... I have been reading this series of posts on parameters and am enjoying it.

    If I understand this correctly, in this instance, you are basically using the 'fire performance' parameter as a method to check against the actually rating of the objects (listed as 'fire rating' in the schedule above). So, in terms of the names of the parameters could you have 'Fire rating' and 'Required Fire Rating' (instead of 'fire performance')? Perhaps that would be a clearer way of defining actual vs required?


Note: only a member of this blog may post a comment.