Quick Links - Also see the menu above and more choices on the right side of the blog (too much, but all good stuff)

\/ ...and now BIMbuilder.com Blog Posts... \/

Wednesday, September 23, 2009

A Case for Type Parameters and a lecture about Revit family management

BIM Managers. This one's for you. The post below is goint to be a real eye opener. If you don't understand everything you read in the post, don't worry. Who cares if you create families that don't follow a set protocol, follow best practices or you simply don't have time to make a Revit family correctly. Big deal right? You just need it for your own purposes. It certainly won't matter what the electrical engineer, lighting consultant, commissioning agent, contractor, subcontractor or facility manager do with the model. I mean really, it's not like you're getting paid to create a family that others can take advantage of.

Now, back to reality. Quality content is going to be key for the future of Revit and BIM. It's not enough to be able to model a part in 3D. Knowing the parameters to include, what field names are required, what constraints to use, what ID code to use and so many other criteria need to be considered when creating your own content. It's one of the reasons I keep mentioning Andekan.com. Any piece of content that ties into a building system or is used for LEED certification has to be audited. Since Andekan has been making content for manufacturers for several years now, they know what questions to ask and what needs to be included in the content. If you think you're saving money by making your own content or even downloading a number of pieces available online, you'll pay the price down the road.

I'm sorry Autodesk, but I have a major problem with Seek. I don't think every user should have the ability to download whatever content they want. Who's checking if that Revit family is accurate, the right piece, meets a particular code or specification. By having total freedom of content insertion, it's creating a potential nightmare for BIM managers and others down the road. Standards need to be created, protocols followed and rules set in place. If you think you have problems with line weights, layers and colors, welcome to the world of BIM.

I'm sorry to make this sound like a lecture, but 26 years later after the birth of AutoCAD, can someone explain to me why their are 9 million different sets of CAD standards or none at all? That's what happens when people just try to figure it out on their own. Don't even bother using Revit if you're not going to invest in professional implementation and content. You'll just create in Revit what's been a major problem in sharing DWGs between architects, engineers and consultants.

>http://inside-the-system.typepad.com/my_weblog/2009/09/the-case-for-type-parameters.html

The concept of Type parameters vs. Instance parameters seems to put many users' minds into a spin. Instead of trying to describe what the difference is, I'm going to provide a scenario where Type parameters should be used instead of Instance parameters. Perhaps by providing a concrete example, one will be more readily able to discern when to use one over the other.

I came across a Revit project file recently. Some things weren't jiving for me in trying to diagnose an issue, so I put together a quick schedule, and found this:

Image1

If you have a keen eye, you're asking yourself, how can multiple "Fixture Types" be associated with the same Family and Type (i.e, the Corp_Recessed : 277V Recess)?

Upon further inspection of this particular Family, I found the following:

Image2

The issue is simply that the method used in this project to 'type' the fixture will easily lead to inconsistencies. The Instance parameters, indicated by (default), introduce a lot of uncertainty into the model.

Take for example the following instances in the model:

Image3

I.e., what is to keep someone from adjusting the length of an "A1" fixture to be 8' long instead of 4'? What is to keep someone from adjusting the geometry of an "A4" fixture to appear like a 2x4, or even a 4x4 (instead of the apparently intended 2x2), or adjust the height too? Or... what is to keep one from mis-'Fixture Typing' a "A1" as an "A9"?

Even the Load in this family is an instance parameter... I don't think anyone would want to rely on someone to enter the proper load at each instance of all of these fixtures. For this one type containing 514 total instances, that is over 2500 opportunities for error (514 x 5 params each: length, width, height, load, fixture type). Using Type parameters for these properties avoids all such problems and will lead to a much more consistent model.

Take for example (referring to the schedule above) fixture type "E1" - is this fixture supposed to be Wall mounted or Ceiling mounted? 120v or 277v? If it makes a difference in the model number that needs to be ordered, it could be a change order waiting to happen.

To summarize: each fixture type (corresponding to a manufacturer's model number) of a lighting fixture should be uniquely identified - this is nothing new. However, the execution of how you do this can make your documentation much more consistent if applying the proper techniques in your modeling application. In Revit - this means make sure you have a separate Fixture Type for each Type of fixture. If you use the 'Type Mark' parameter built-into the software, Revit will even warn you if you inadvertently duplicate a value!

Cheers-
Martin Schmid, PE
MEP Customer Success Engineer

Source: Inside the System: A Case for Type Parameters

1 comments:

Margaret September 24, 2009 at 4:29 PM  

I have to completely disagree with this as it my family. This is the way electrical works and has worked very well since we started in systems. We have used this method on 20 some models.

  © Blogger template ProBlogger Template by Ourblogtemplates.com 2008

Back to TOP  

[Valid Atom 1.0]