When you choose to add a parameter, it is likely that you have a specific purpose for it. That may sound like an obvious statement, but it is important to consider when you decide what to name the parameter. There is no harm in naming your parameters in a descriptive manner, especially when you are working with others who need to understand the purpose of a parameter. However, it is possible to be too verbose. Long parameter names can cause the annoyance of having to resize columns within dialog boxes in order to read the name.

Consistency is the key to good parameter naming. It can be frustrating to go from one family to another and see different names for parameters of the same information. Using descriptive words is also helpful, especially when you have similar parameters within the same object, such as a component that is made up of multiple shapes with each requiring a width parameter. Having W1, W2, W3, and so on, as parameter names can be difficult to work with, whereas using names like Housing Width, Lens Width, and Bracket Width make it easier to make adjustments or changes when working in the Properties palette or Type Properties dialog box of the object.

If you intend to abbreviate measurements such as length, height, or radius, be sure to use a consistent format. Will you use the abbreviation as a prefix or suffix to the descriptive portion of the name? Will punctuation such as dashes or parentheses be used? Decide up front whether you will use height or depth to describe the third dimension of an object.

Parameter naming is important because when you refer to a parameter in a formula, calculated value, or filter, Revit is case sensitive and content sensitive. Spelling and capitalization accuracy are critical, so develop a naming convention that is as simple as possible while still being easily understood.

Type parameters are the reason that you can have multiple variations of a family within one file. Family types are driven by one or more type parameters. When you are creating a parameter, it is important to decide whether the parameter will be used to define a type within the family.

Type parameters can cause the most damage when misused because they enact changes to every instance of the family type to which they belong. For this reason, you will receive a warning when editing a type parameter in a schedule view, and accessing a type parameter in a model view requires an extra mouse click.

Type parameters do not always have to define a family type. In some cases, you may want to define a parameter as a type parameter so that changes can be made to a family everywhere the family exists in a project. For example, if you are creating a parameter for the finish color of an object, you could make it a type parameter so that when you change the value of the parameter, it changes all instances of the object.

Type parameters do require that if you need to change just one or a few instances of an object, you will have to create a new family type. This can lead to having several types within a family, causing your Type Selector to be cluttered and confusing. If you are creating a type parameter that will define a family type, it is best to name the family type as it relates to the value of the type parameter(s). A light fixture family defined by its width and length parameters would likely have family types with names such as 2 4 (600 1200) and 1 4 (300 1200), for example.

Instance parameters provide the most flexibility for editing an object. They are easily accessed via the Properties palette when an object is selected. Create instance parameters for values that you want to be able to change for just the selected object. Using the finish color example again, if the color is an instance parameter, then you could have one family type that could vary in color, without having to create a separate family type for each color option.

The drawback to instance parameters is that they apply only to the selected objects, so if you want to change an instance parameter value for all instances of an object, you will have to select each object and change it individually or use the tools that allow you to select all instances of a family.

An instance parameter can be set to be a reporting parameter. This is a new feature for Revit MEP 2011. A reporting parameter will hold a value that can be used in formulas for other parameters or to drive the behavior of another parameter. These are most useful in families that are wall or ceiling hosted because you can use a reporting parameter to recognize the thickness of the host wall, for example. Some portion of a dimensional reporting parameter must be associated to the host in order to be used in a formula.

Once you have defined a parameter as either instance or type, you can change it if required for the desired behavior. However, switching a parameter from type to instance, or vice versa, can cause problems if the parameters are used in formulas, so it is best to know up front what kind of parameter to create.

The Discipline drop-down list in the Parameter Properties dialog box contains the different disciplines that can be assigned to a parameter. Parameter discipline is important for defining the measurement units that the parameter value will have. Figure 19.2 shows the drop-down list of available disciplines.

Figure 19.2. Parameter discipline options

The Type Of Parameter option in the Parameter Properties dialog box is directly related to the chosen discipline. Each discipline has a unique set of parameter types that relate to the various units of measurement for that discipline.

Figure 19.3 shows the Type Of Parameter options for the Common discipline. Notice that many of the types are the same as in the Project Units settings for the Common discipline of a project such as Length, Area, and Volume.

Figure 19.3. Parameter type options for the Common discipline

There are additional options for parameter values that are not a unit of measurement. The Text option allows you to input anything for the value of the parameter. This is the most versatile option, but from an engineering standpoint, it offers the least amount of intelligence because a text string provides only information, not computable data. If you are creating a parameter that is scheduled and want the ability to input either numbers or text or a combination of characters, then the Text option is best.

The Family Type option for a parameter is a useful tool when using multiple nested families within a family. You can create a Family Type parameter to toggle between all the nested families. When the host family is loaded into a project, the parameter can be modified to display any of the nested families by selecting from the list in the Family Type parameter. Figure 19.4 shows an annotation family for graphic scales with several nested annotations loaded. A Family Type instance parameter has been created to allow for use of any of the nested families.

Figure 19.4. Family using Family Type parameter

You can use the Yes/No option if your parameter requires a simple yes or no value. The value for this type of parameter appears as a check box, which can be used to control the visibility of objects or to verify that a condition exists.

Other disciplines have options for Type Of Parameter that relate to units of measurement for that discipline. It is important to know that when you select a specific Type Of Parameter setting the value used for that parameter must be consistent with the unit of measurement. For example, if you choose the Air Flow option for the HVAC discipline, you could not input a value of anything other than a number consistent with the unit of measurement you are using for air flow. This can cause problems with schedules when an object does not have a value for this parameter and you want to use something like N/A or — to indicate that the value is not actually 0.

By default, the Type Of Parameter option will be set to Length. This is new to Revit MEP 2011, whereas in older versions the default was Text. In older versions, it was easy to overlook this setting because of the versatility of the Text type, but with Length being the default now, it is important to set the proper type.

You can determine where the parameter will show up in the Properties palette or Type Properties dialog box of an object, as shown in Figure 19.5.

Figure 19.5. Parameter groups

The option for grouping parameters is sometimes confusing to people because they think that it is related to the Type Of Parameter setting. This setting does not have any bearing on the Type Of Parameter or Discipline settings, so you could have a Duct Size parameter that is placed in the Identity Data group. To make it easier to keep parameters organized, new functionality has been added that automatically associates a parameter type with an appropriate group. So if you create a Length parameter, it will be placed in the Dimensions group, Air Flow parameters are placed in the Mechanical-Airflow group, and so on. You still have the option to place a parameter in any group you choose, but now the defaults are more intuitive.

Parameter grouping is another area where being consistent is important to improved workflow and efficiency. You want to be able to find your parameters in the same location for each family while editing in your model.

You now have the ability to lock dimensional parameters in the Family Editor so they cannot be changed while working on the geometry of a family. There is now a Lock column in the Family Types dialog box with a check box for each dimensional parameter. What is nice about this feature is that if you do not lock a parameter, you can change its value while working on the geometry, eliminating the need to stop and access the parameter to change its value manually. An object that is constrained by a dimension can be moved, and the parameter's dimension value will adjust. This eliminates the pesky Constraints Are Not Satisfied warning dialog box that appeared in previous versions. However, this warning will appear if a dimensional parameter is locked and an object is moved.

You also have the ability to edit the value of a dimensional parameter in the drawing area by clicking the text, just as you would edit a dimension object. This can be done whether the parameter is locked or not. Locking only prevents the accidental dragging of an object while working in the drawing area.

When creating type parameters in a family, there will be a set value for each family type. When the family is inserted into a project, the values established in the family will remain until the family type is edited. Instance parameters can be given a default value when created in a family. These parameters are easily identified in the Family Types dialog box via a suffix of (default). This is the value that the parameter will initially have when placed into a project. If you edit a family that exists in your project and then load it back in, the instance parameter values will not change from their existing states in the project. Fortunately, the dialog box that warns you that the object already exists in the project gives you the option to overwrite the family and its parameter values, which will change any instance parameters to the value as it exists in the family.

As mentioned earlier, Yes/No parameters are great for controlling the visibility of objects. After creating a Yes/No parameter, you can select the desired object and set its Visibility parameter to the value of the Yes/No parameter using the small box at the far right of the Visibility parameter value. Figure 19.6 shows the settings used to associate the visibility of line work with a Yes/No parameter.

Figure 19.6. Yes/No parameter used in a family for visibility

Real World Scenarlo: Yes/No Parameters in Nested Annotation Families

To control the number of annotation families that are nested into a family, Yes/No parameters within an annotation are very useful. One example is for electrical receptacles. Many receptacles look essentially the same in the model, but the symbol used for each type may vary. Instead of creating a separate annotation symbol for each type of receptacle, consider using Yes/No parameters within one annotation to account for each symbol. The image shown here is an annotation family with all of the line work and regions required to represent each type of symbol used.

The visibility of the lines and regions are associated with Yes/No parameters so that when this annotation is nested into a family, the Yes/No parameters can be associated with parameters in the family. The result is a single receptacle family that can represent multiple types of receptacles, as shown here.

Families can sometimes become very crowded with many types. The number of type parameters used to define a family type will increase the number of family types. When these families are loaded into a project, all of the family types are loaded. This can quickly cause your project to be overloaded with unused family types. One way to remedy this scenario is to create type catalogs for families that contain many types.

A type catalog is a .txt file that contains values for the type parameters of a family. Having a type catalog associated with a family allows you to select only the family types you want to load when you insert the family into a project. You can create a type catalog for a family by creating a .txt file with the same name as the family in the same folder as the family file. Because type catalogs are .txt files in comma-delimited format, it is easier to edit them using a spreadsheet program such as Microsoft Excel.

To create a type catalog, do the following:

You cannot use instance parameters in a type catalog. If you leave a parameter value blank in the family, the type catalog will ignore the parameter when the family is loaded. So even though the parameters in the family are essentially placeholders for the type catalog, they need to have something input for their value. Figure 19.7 shows an example of a type catalog for a motor connection family.

Figure 19.7. Sample type catalog

It is easy to see why a type catalog for this family is used; otherwise, all 23 family types would be loaded when this family is inserted into a project. Notice that the format for the type parameters is ##parameter name##group name##. The group name is relatively unimportant because the parameter is already grouped in the family file, so Other can be used. For consistency, however, it is best practice to use the actual name that the parameter is grouped under. It is not a necessity, but this format is important because otherwise the columns cannot be parsed when the family is inserted into a project. Use decimals for measurement values. The units of a dimensional parameter should be defined in the column heading, such as ##DuctSize##Other##Inches.

Once the file is saved, you can browse to it and rename the file with a .txt extension to convert it. If you receive a warning that the file might become unusable when the extension is changed, click Yes.

When a family with an associated type catalog is inserted into a project, a dialog box will appear that allows you to see the parameter values for each type and choose which family types you would like to load.

Figure 19.8. Specifying types from a type catalog

Not all parameters in a family are used to directly drive the geometry. Many are used to hold data that results from the creation of the geometry, which will be used for driving additional geometry or spatial relationships. This is done by creating a formula for a parameter. One of the most common occurrences of this is when a diameter measurement is required. Revit will only dimension the radius of a circle, so a diameter parameter must be created by using a formula. The radius of the geometry is dimensioned and applied to a parameter, which is then used in a formula to generate the diameter measurement.

One nice feature of formulas is that you can change the value of the parameter that is created by a mathematical formula, and the value of the parameter used in the formula will update accordingly. Mathematical operators and Boolean functions can all be used. Placement of parentheses, proper units, case, and context sensitivity are all very important for your formulas to work properly. A warning will appear if the result of a formula does not match the units for a parameter as well as if a parameter name is misspelled.

Formulas can even be used for parameter types such as a Yes/No parameter. Figure 19.9 shows a Boolean formula for a Yes/No parameter to determine when the box should be selected. The formula indicates that the box is either deselected or selected when the conditions of the formula are true.

Figure 19.9. Boolean formula for a Yes/No parameter

Formulas using if statements are very powerful for providing exact conditions and variations in parameter values based on other parameter values. The format for an if statement is as follows:

if(condition, result, default result)

The default result is the value given to the parameter when the condition is not met. You can use other parameters to define the condition. For example, if you want a Width parameter to equal the Length parameter under certain conditions, you could write this formula:

if(Length>2' 0"(600mm), Length, 1' 0"(300mm))

This formula would cause the Width value to equal the Length value when the Length is greater than 2′-0″ (600mm); otherwise, the Width would be 1′-0″ (300mm).

When you create a family, certain parameters exist by default. These parameters are hard-coded into the software and cannot be removed. You can use these parameters where they apply to avoid having to create custom parameters.

These parameters vary depending on the category you choose for the family. The coded parameters under the Identity Data group are common to component families and are also included in system families within a project.

There are, however, a few that do not appear in the Family Types dialog box when working in the Family Editor but do appear in the Type Properties dialog box once the family has been loaded into a project. The most notable of these is the Type Mark parameter. This parameter is often used to identify a component with a tag or in a schedule. Because this parameter does not exist in the family file, you cannot use it in a type catalog. One way to avoid creating a custom parameter that does essentially the same job as the Type Mark parameter is to have your type catalog create family types named with the same value you would use for the Type Mark. Then you can tag or schedule the Type parameter instead of the Type Mark parameter.

One coded parameter that is unique is the Lookup Table Name parameter that exists in families that can utilize a lookup table for dimensions. These are primarily duct, conduit, and pipe fitting families. When you install Revit MEP 2011, an extensive library of lookup tables is installed that can be referenced by families.

Lookup tables are .csv files that work like a type catalog. They provide values for dimensions based on other dimensions within the family. The data in lookup tables can be driven by design codes or manufacturing standards to ensure the graphical accuracy of your components. Pipe fittings, for example, have a nominal diameter that is used to identify the size, but the actual outside diameter is slightly different especially for different pipe materials. A lookup table can provide the outside diameter dimension for each nominal diameter that exists in the table.

The Lookup Table Name parameter is used to identify which .csv file the family is referencing. The location of your lookup tables is defined in your Revit.ini file. When you type in the name of a lookup table, you do not need to include the full path to the file, only the name and file extension. As with parameter names, referencing a lookup table name is case and context sensitive.

Once you have referenced the lookup table with the Lookup Table Name parameter, you can access the data in the table by using a formula for the value of a parameter. The formula using lookup table data is as follows:

text_file_lookup(Lookup Table Name, "Column Nam", Value if not found in table, Value found in table)

The result of this formula will apply the value found in the table to the parameter or the defined value given in the formula if none is found in the table. The image shown here is the formula used to determine the value of the Fitting Outside Diameter parameter of a pipe fitting family. The FOD column is searched for a value that coincides with the value given for the Nominal Diameter and applies it to the Fitting Outside Diameter parameter. If the Nominal Diameter value given in the family does not match one in the table, then the Nominal Diameter + 1/8″ is used for the Fitting Outside Diameter.

For more information on working with parameters in family files, see the Families Guide, which can be accessed from the Documents On The Web section of the Revit MEP 2011 Help menu.

The only way to add a parameter to a system family is to add it by creating what is known as a project parameter. This allows you to customize the information you want from elements within the model. Space objects can be given a lot of useful data to help make design decisions and to analyze the model performance. Project parameters make it possible to add this data to spaces and other elements that cannot be physically edited.

You can add a project parameter by clicking the Project Parameters button on the Manage tab. In the Project Parameters dialog box, you can see a list of any parameters that have been added to the project. Clicking the Add button opens the Parameter Properties dialog box, as shown in Figure 19.13. This is the same dialog box as in the Family Editor but with additional settings to assign the parameter to a category.

The settings for creating a parameter or adding a shared parameter are the same for project parameters. The only difference is the Categories section of the dialog box. This is where you can select the Revit category that the project parameter you are creating or the shared parameter you are loading is applied to in the project.

Project parameters are a great way to use shared parameters in families without having to edit each family individually. The check box in the lower-left corner indicates that the parameter will be added to all elements in the project that belong to the selected category. So if there are parameters that you want to use on a particular category of elements, such as light fixtures, you can create the parameters as shared parameters and then load them as project parameters into your project template file. Then whenever you load a family belonging to that category into your project, it will have the desired parameters, which can be used for scheduling or tagging.

Figure 19.13. Parameter Properties dialog box for a project parameter

The Categories section lists all MEP-related categories that the parameter can be applied to. Like the Visibility/Graphics Overrides dialog box, you can select the box below the list to show all Revit categories. Project parameters can be added to multiple categories, allowing you to quickly add information to multiple objects.

When you add a parameter to your project and it is applied to elements in the chosen category, the parameter will not have a value. The parameters can be easily given values by creating a schedule of the elements and including the project parameter(s) in the schedule.

Yes/No type parameters will be set to Yes (checked) by default and appear to be uneditable when they are viewed in a schedule or the properties of an element. You can click the grayed-out check box once to make it editable.

Family parameters and some coded parameters cannot be used in schedules. If you do not want to use shared parameters in your families, you can create project parameters for scheduling information about components. In the Schedule Properties dialog box at the center of the Fields tab is an Add Parameter button, as shown in Figure 19.14. Clicking this button opens the Parameter Properties dialog box just like when working in a family, but instead of the Family Parameter option, you have the Project Parameter or Shared Parameter option (see Figure 19.15).

Figure 19.14. Schedule Properties dialog box for adding parameters

Figure 19.15. Parameter Properties dialog box

As you can see in Figure 19.15, there is no choice for a category in this dialog box because the parameter will be applied to the category of the schedule. All elements within the category will get the parameter even if they are not in the schedule. For example, if you are creating a Mechanical Equipment schedule that will only include VAV units and you create a parameter within the schedule, it will be added to all mechanical equipment.

Use of the Calculated Value feature of a Revit schedule will create a parameter to hold the value, yet this parameter is not added to the elements in the schedule.

Whether they are shared parameters or not, project parameters are required for scheduling system families such as duct, pipe, or cable tray. It is easiest to create these parameters when you are building the schedule for such elements. Once the parameter is created, you can access it from the Project Parameters button on the Manage tab to add it to other categories or make any necessary changes. Creating these parameters in schedules within your project template will ensure that they are consistently used from project to project.

One useful type of project parameter to create is for the schedule type of an element. This parameter can be applied to any category that is scheduled and is very useful for filtering your schedules. There is no need for this to be a shared parameter since it is not information that you will be tagging in your construction documents. This kind of parameter should be included in your project template to ensure consistent use and coordination with any preestablished schedules you have in your template(s).

Understanding how to use parameters to get the information you require is the key to successfully reaping the benefits of a BIM solution. Knowing where and when to use certain types of parameters will make it easy for you to manage the data within your Revit projects.

Views and sheets are system families, so you need to use project parameters to include additional information or functionality in them. This type of information may be necessary for construction documentation or simply for organizing your project for more efficient workflow. Depending on their use, these parameters may need to be shared parameters.

One of the more common parameters for views is the Sub-Discipline parameter. This parameter allows you to assign a sub-discipline value to the properties of any view to establish a secondary level of organization within the Project Browser. This parameter is already established in the default template files provided with Revit MEP 2011.

Much of the information that appears on a sheet border is common to every sheet. If the parameters that hold this information were unique to each sheet, it would be very time-consuming to make certain changes. Project parameters that are applied to the Project Information category can be included in your titleblock so that the value can be changed in one location and globally updated to all sheets.

One example is for total sheet count. Including this information on a sheet as an editable parameter would require creating a shared parameter. A label of this parameter could then be placed within the titleblock family. The shared parameter could then be added as a project parameter applied to the Project Information category, as shown in Figure 19.16.

Figure 19.16. Project parameter for sheet total

Notice that the parameter is an instance parameter. You cannot create type parameters for the Project Information, Sheet, or View categories.

When the project information is edited, the value will be updated on every sheet in the project. Figure 19.17 shows this example on a titleblock in a sample project.

Figure 19.17. Shared parameter used on a sheet

Combining the power of shared and project parameters can give you the ability to report, tag, or schedule any data within your model or about your project in general. Once you understand how to use parameters effectively, the real work becomes managing them for consistency and accuracy within your projects.