Chapter 6

Parameters

The Autodesk® Revit® platform is sometimes referred to as a parametric change engine. Parameters are the very core of what makes Revit MEP such a powerful design and modeling tool. Parameters hold the computable data that defines the properties of not only model components, but also everything that makes up a Revit project. They are the characteristics of all elements of a Revit project that ultimately determine behavior, appearance, performance, and information.

Parameters and properties are often considered synonymous, but it is the parameters that determine the properties of a component. Properties may be static, but parameters allow for change to be propagated throughout the project. For example, you can have an object with a length property, but it is a length parameter that allows you to change the length as needed.

There are four basic kinds of parameters in Revit MEP. Some parameters are hard-coded into the software. The values of these parameters can be edited as needed, but the parameters themselves cannot be removed or modified. In this chapter, these are referred to as coded parameters.

Family parameters are used to build and define graphical structure and engineering data within component families. These parameters can be customized as needed to enhance the capabilities of component objects and to extract and analyze data.

Shared parameters are useful to help maintain consistency within families and to coordinate information within a project. They are the most useful kind of parameter because they can be used in component families, schedules, tags, and annotations to report the same data in whichever format the user chooses.

Project parameters exist only in project environment, as the name suggests. They can appear in schedules but not in tags. Their main advantage is that you can apply them to all families of a particular category or even multiple categories. Project parameters can be created from the Project Parameters tool under the Manage tab.

When you realize the power of parameters in Revit and understand the types of things you can achieve with them, you will have a better understanding of why Revit can improve your workflow processes and the efficiency of your design projects.

In this chapter, you will learn to do the following:

• Manipulate the properties of parameters
• Work with parameters in families
• Work with shared parameters
• Use parameters in project files

Understanding Parameter Properties

Before you can understand how to use parameters to drive the properties of your objects, you need to understand the properties of parameters. When you create a parameter to hold some form of computable data, you want to define the way in which it will do so. Figure 6.1 shows the Parameter Properties dialog box accessed from within the Family Editor. Other versions of this dialog box that contain additional settings are discussed later in the chapter. This dialog box is the first place to go when adding a parameter to either a family, a project, or a schedule.

Figure 6.1 Parameter Properties dialog box

The first decision to make is what type of parameter to create. Family parameters can be created when working in the Family Editor, and they are limited to being used only within the family. The information that they hold cannot be used in schedules or reported by a tag or annotation. Shared parameters can be used the same way that family parameters are used, but they are unique in that they can also be used in schedules and tags. Parameter types are discussed in further detail later in this chapter.

Parameter Naming

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 that provide 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. It can be difficult to work with parameter names such as W1, W2, W3, and so on, whereas using names such as 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? These symbols can have an effect on how those parameters perform in formulas. Decide up front whether you will use height or depth to describe the third dimension of an object. The way you orient the families can also create inconsistency in parameter usage. What could be width for one family may be length for another. Considering the orientation of the family and where the parameters would go can avoid that issue.

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

Type Parameters

Type parameters are the reason why 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 that 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, which causes 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.

Type parameters also allow you to create type catalogs for families with extensive lists of parameter configurations. We will address type catalogs a little later.

Instance Parameters

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. Thus, 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. Alternatively, you can select objects by using schedules, or by right-clicking an object and choosing Select All Instances. Make sure you understand the difference between the options Visible In View and In Entire Project. Figure 6.2 shows the difference between these two options.

Figure 6.2 Selecting all instances

Selecting All Instances

Maria, an experienced Revit user in a hurry to issue drawings, is asked to remove circuit tags from the view in which she is currently working. She uses Select All Instances and mistakenly chooses the In Entire Project option. She doesn't notice the filter number indicating more than 2,000 objects selected. Maria proceeds to delete all tags and gets ready to issue the drawings. An hour later, she recognizes her error and wants to undo changes. Unfortunately, other people have been synchronizing work back to the central file, which includes some additional work to the lighting design in other parts of the building. Maria has no option but to go through the entire set to replace all tags. There is an option to tag All Not Tagged, but this is per view. Additionally, many of the tags have been moved for clarity.

This experience doesn't put Maria off. She knows what happened and why, and the drawings go out on time. She now reinforces this particular behavior in training sessions.

---

An instance parameter can be set to be a reporting parameter. 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, for example, you can use a reporting parameter to recognize the thickness of the host wall. 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. Just keep in mind that Revit will not let you change a type parameter to an instance parameter if that parameter is used in a formula of a type parameter. The rule of thumb is that instance parameters can't “drive” type parameters. Thus, it is best to know up front what kind of parameter to create.

Parameter Discipline, Type, and Grouping

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 6.3 shows the drop-down list of available disciplines.

Figure 6.3 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 6.4 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 6.4 Type Of Parameter 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 the parameter value doesn't have specific units and will always be numbers, it is best to use Number instead of Text; this will allow you to use it in formulas if you ever need it. 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 you have 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 6.5 shows an annotation family for graphic scales with several nested annotations loaded. A Family Type instance parameter has been created to allow the use of any of the nested families.

Figure 6.5 Family using Family Types 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 any value other than a number consistent with the unit of measurement you are using for airflow. This can cause problems with schedules when an object does not have a value for this parameter and you want to use something such as N/A or a dash to indicate that the value is not actually 0.

By default, the Type Of Parameter option is set to Length. This was introduced in 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 6.6. However, Revit will make a “best guess,” placing a parameter for HVAC/Airflow into the Mechanical - Airflow group, or one for Electrical/Luminous Flux into the Photometrics group, for example. The user can override this but should consider other users and content creators. If you are using shared parameters, it may well be a best practice to accept the defaults, unless the company documentation is very good. This will lead to less confusion, because coworkers will know where to find similar data in families and projects.

Figure 6.6 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. The Group Parameter Under 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. Parameter grouping is another area in which 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. If you are not going to use the default for Group Parameter Under all the time, it may be a good idea to take it a step further and create a company-standard document that outlines what Type Of Parameter setting goes in what Group Parameter Under setting. By finding the same parameters always in the same group, your users will be more efficient and comfortable with your company families.

Using Parameters in Families

Many parameters are created when working in the Family Editor. As content is planned, created, or edited, it becomes clear which type of data is needed for either analysis or reporting or to drive the geometry. Because “flexing” to test a family is an important task, you are able to directly edit dimensional parameters, which are not locked in the family, without having to access the Family Types dialog box.

Dimensional Parameters Lock Function

You now have the ability to lock dimensional parameters in the Family Editor so that 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 prevents only the accidental dragging of an object while working in the drawing area.

Parameter Types

When creating type parameters in a family, you set a specific 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. Changing a type dimension, or any other type parameter in a project, has to be carefully considered. Do you want to change a standard object, which could affect many instances of a family, or should you create a new family type? The answer to this may not always be as simple as it first seems.

Parameter Types

While creating a lighting plan, Samir loads a family—Recessed Parabolic Luminaire, type 2′ × 4′ — and places it in multiple locations. During the design process, the engineer indicates that she wants a different layout with 2′ × 2′ fixtures. Samir could change the type parameter for length to 2′ and have an immediate result. However, he knows that by doing so, he is not changing many of the other design criteria parameters, so he duplicates the family type, creates a new 2′ × 2′ type, and enters the design and dimensional parameters. He now needs to select and change the required existing luminaires from their current type to that new one. Although this process may take slightly longer than the first option, Samir is confident that any calculations will be correct and future changes will take even less time to make.

---

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 intended for the parameter to have initially when placed into a project. The addition of the Properties palette has had an effect on this behavior. The first attempt to place an instance of a family will not always have the default value defined in the family for an instance parameter. Subsequent placement of the same family will use the last input value. The value can be modified prior to placement of the family. If you edit a family that exists in your project and then load it back into the project, 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 by using the small box at the far right of the Visibility parameter value in the Properties Palette. Figure 6.7 shows the settings used to associate the visibility of the diagonal line with a Yes/No parameter.

Figure 6.7 Yes/No parameter used in a family for visibility

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 is 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. Another way of accomplishing similar results is using the Family Type option mentioned previously.

---

Type Catalogs

Families can sometimes become crowded with many types. The number of type parameters used to define a family type potentially increases 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 that has the same name as the family and is located 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:

1. Start a new spreadsheet file. The first column of the spreadsheet will be a list of all the family types. Each column after that will be a type parameter within the family. The type parameters must exist in the family file and have some value in order to be used in the type catalog.

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 6.8 shows an example of a type catalog for a motor connection family

Figure 6.8 Sample type catalog

It is easy to see why a type catalog for this family is used; otherwise, all 15 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 a best practice to use the actual name under which the parameter is grouped. 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.

2. Once you have finished creating the spreadsheet, you can save it as a CSV (comma-separated value) file. If you receive a warning that some of the features of the file may not work when saved to CSV format, you can click Yes to save the file.

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.

3. Choose family types by selecting them from the list. You can select multiple types, as shown in Figure 6.9. You can filter the Specify Types dialog box based on specific parameter values by using the drop-down list under the heading of each column.

Figure 6.9 Specifying types from a type catalog

Formulas

Not all parameters in a family are used to drive the geometry directly; many are used to hold data that results from the creation of the geometry and that will be used for driving additional geometry or spatial relationships. This is done by creating a formula for a parameter. One common example of this occurs when a diameter measurement is required. When you are adding a duct or pipe connector to an equipment, in most cases you would want to be able to access the diameter of that connector in a project environment. In order to do this, you would select the connector and from the property palette click on the button right next to the Radius parameter. This would allow you to create your own parameter and access the Radius of the connector in a project environment. The limitation is that the parameter says Radius not Diameter, and working with the Radius of a connector can be challenging, especially for the very small fraction pipe sizes. To avoid this confusion you would need to create a Radius parameter and use it in a formula. It is worth mentioning that you only have to do this for the connectors, because in Revit MEP 2013 you can apply diameter to extrusions without the need of a radius parameter. 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, parameter names, and context sensitivity are all 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, or if a parameter name is misspelled.

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

Figure 6.10 Boolean formula for a Yes/No parameter

Formulas using if statements are 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″ (600 mm); otherwise, the Width value would be 1′ – 0″ (300 mm).

Coded Parameters

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 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 after 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.

Parameter Use

Starting a new job in a consulting engineer's office, Brian finds that the drafting standard is to indicate duct type and construction by using textual information rather than doing so graphically. This means having 18 duct types defined in the project template, each with an identical Type Mark parameter. However, duplicate type marks produce an error message (which can be ignored). The way around this is for Brian to create his own shared parameter type mark, MyCo Type Mark. This method works well for Brian, allowing him to maintain his drafting standards and maximize his efficiency.

---

Lookup Tables

One coded parameter that is unique is the Lookup Table Name parameter. This parameter exists in some families and can utilize a lookup table for dimensions. These are primarily duct, conduit, and pipe-fitting families. When you install Revit MEP 2013, 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 Name”, 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 it will apply the defined value given in the formula if none is found in the table. The following image is the formula used to determine the value of the Fitting Outside Diameter (FOD) 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 that value is applied to the FOD 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 FOD.

For more information on working with parameters in family files, see the Families Guide, which can be accessed from the Autodesk WikiHelp site under Revit ⇒ English ⇒ 2013 ⇒ Revit Help ⇒ Build the Model ⇒ Revit Families.

Using Shared Parameters

Shared parameters are the most versatile parameters you can use, but they also require the most management. Used properly, shared parameters can help ensure that your schedules are coordinated, and that your construction documents are reporting the correct information. Shared parameters can be type or instance parameters that are used in families or as project parameters. The main advantage to using shared parameters is that the data they hold can be exported or reported in tags and schedules.

Shared parameters are parameters that are created with their settings stored in a TXT file. It may help to think of this file as a library of parameters, similar to a library of model components.

When you need to add a parameter to a family or project, you can use one from your shared parameters file. This helps with the management of your content and project standards because you can be consistent in your use of parameters. It also helps with maintenance by allowing you to avoid duplication of parameters, which can cause coordination issues. Multiple parameters with the same name can show up as available for use in a schedule, and you will not be able to tell which one is the correct one to use.

You can create a shared parameter by doing the following:

1. Click the Shared Parameters button on the Manage tab. When you create a parameter in the Family Editor or add a project parameter, you have the option for it to be a shared parameter. Selecting this option activates the Select button in the Parameter Properties dialog box.

2. In the Edit Shared Parameters dialog box, you must first create a shared parameters file. Click the Create button to select a location for the file.

You can have multiple shared parameters files, so it is a good idea to create a folder in a common location that you and others can access. You can access these files by clicking the Browse button in the Edit Shared Parameters dialog box, which is shown in Figure 6.11.

Figure 6.11 Edit Shared Parameters dialog box

There are two components to a shared parameters file. The parameter group is a level of organization that you can establish to group parameters together. This is not the same group as shown in the Parameter Properties dialog box for defining where parameters will be listed. These groups are available so that you can keep your shared parameters organized. A typical method of organization is to create groups based on family categories. Figure 6.12 shows an example of parameter groups created for parameters that apply to specific family categories.

Figure 6.12 Method 1 - using family categories

Notice that a group has been created for VAV units. Although it is possible to create a group with any name, keep in mind that the parameters must be assigned to a category. In the case of these parameters, they will be applied to all mechanical equipment if used as a project parameter, even though they are specifically designed for VAV units. The parameters in this group could be added to a lighting fixture family if chosen. Parameter groups can be renamed or deleted by using the buttons in the lower-right corner of the dialog box. You cannot delete a group until all parameters have been removed from it.

Another way to organize your shared parameter groups is to follow the Group Parameter Under pull-down in the Parameter Properties dialog box. When you use this method, the position of the parameter grouping will be identical in both the shared parameters file and in the properties of the family, as shown in Figure 6.13.

Figure 6.13 Method 2 - using Group Parameter Under

3. After you have established a group in your shared parameters file, you can begin to create parameters. Click the New button in the Parameters section of the Edit Shared Parameters dialog box to open a Parameter Properties dialog box. This is not the same dialog box that you get when you create a parameter in the Family Editor or in a project. This is a simple dialog box, because all you need to define for a shared parameter are the Name, Discipline, and Type Of Parameter settings, as shown in Figure 6.14. The parameter that you create will be added to whatever group you have active when you click the New button.

The Name, Discipline, and Type Of Parameter settings are the same options used when creating a family parameter.

4. Once a parameter has been created, you can select it and click the Properties button to view its settings. The settings cannot be changed after a parameter has been created. If you want to change a shared parameter, you have to delete it and re-create it with the new settings. If you do so, you will have to add the parameter back to any object that had the parameter being replaced.

5. If you create the parameter in the wrong group, however, all is not lost. Simply select the parameter and click the Move button, which allows you to move the parameter to another group.

Figure 6.14 Parameter Properties dialog box for a shared parameter

Choose and establish shared parameter settings very carefully. A parameter that is deleted from your shared parameters file will remain in any families or projects—you will not be able to add it to anything new. There is a get-out clause here if you have deleted a shared parameter that you later wish to keep. Open any family or project where you know the parameter exists. Select the parameter in the Type Properties dialog box and click Modify. Once you're in the Parameter Properties dialog box, click the Export button. This exports the shared parameter to a parameter group in the shared parameters file called Exported Parameters, and the parameter can be moved if necessary, as described earlier.

You can add a shared parameter to a family by doing the following:

Managing shared parameters should be treated with the same importance as managing your content library. Because these parameters provide intelligence that carries through from a family all the way to your construction documents, it is important that they are maintained and used correctly. Preventing users from having full access to this file is one way of managing this, much in the same way as many libraries have restricted, read-only access.

One category for which shared parameters can become cumbersome is the Mechanical Equipment category. Typically, many characteristics of a mechanical unit are required to be scheduled, so shared parameters are necessary. Some of these characteristics are the same unit of measurement, but for a different component of the unit. Since you cannot add the same shared parameter to a family more than once, you may need to make multiple parameters of the same type. It is best to try to keep your shared parameters as simple as possible for this category. Naming parameters specifically for their use is helpful in keeping track of them. In addition, developing a standard for where these parameters are grouped in the families will help you avoid confusion when editing the properties of a family.

Even though it may initially require a bit of work, adding these parameters directly to your Mechanical Equipment families rather than as project parameters will go a long way in keeping your families from becoming overcrowded with unused parameters. Consider keeping a document such as a spreadsheet that lists all of your custom parameters and indicates whether they are family or project parameters, what parameter group they exist in if they are a shared parameter, where they are grouped in the properties of a family, and whether they are used as a type or instance parameter. Having this document open will be helpful when creating new content, because you will know what parameters already exist and how to use them. As new parameters are created, the document can be updated. If you work in an environment with multiple users, it is best to keep only one copy of this document in a common location. You can organize the file and list in what family the parameter is used or you can do it by schedule. Figure 6.15 demonstrates a sample Excel file that manages the shared parameters by schedules that they belong to.

Figure 6.15 Sample Excel file organizing all shared parameters

Using Parameters in Projects

Parameters are typically handled at the component level for building objects, but there are also parameters for non-component objects such as views, sheets, and annotations. You may need to create custom parameters for system families that cannot be edited in the Family Editor. These parameters can be added to designated categories within your project so as to assign them to system families. Your projects themselves can have parameters that convey project-specific information. Understanding how to use parameters in a project is the key to getting the most benefit from constructing an intelligent model with computable data.

Project Parameters

The only way to add a parameter to a system family is to add it by creating 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, shown in Figure 6.16. This is the same dialog box as in the Family Editor but with additional settings to assign the parameter to an object category. The object category list includes all the component families, system families, in-place families, and even metadata that may not be physical geometry like views, sheets, project information, and so on.

Figure 6.16 Parameter Properties dialog box for a project parameter

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 to which the project parameter you are creating or the shared parameter you are loading is applied 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.

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. You can easily give the parameters values by creating a schedule of the elements and including the project parameters in the schedule.

Yes/No type parameters will be set to Yes (selected) 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.

Parameters in Schedules

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 6.17. Clicking this button opens the Parameter Properties dialog box; this is the same dialog box that you get when you click Project Parameters. Essentially you can create project parameters from the Project Parameters dialog box or from a schedule. All of them will appear in the Project Parameters list. However, there is a difference where you create them from. When you create the parameters from a schedule, they will automatically be applied to the category of the schedule. For example, if you are scheduling mechanical equipment, creating a parameter in that schedule will automatically apply it to all mechanical equipment. But what if you want the same parameter to apply to other object categories as well? You can do this from the Project Parameters dialog box, where you will be given the opportunity to select any additional categories. As we mentioned in the beginning of this chapter, project parameters will appear in schedules but not in tags (see Figure 6.18).

Figure 6.17 Schedule Properties dialog box for adding parameters

Figure 6.18 Parameter Properties dialog box

Using the Calculated Value feature of a Revit schedule will create a parameter to hold the value, but this parameter is not added to the elements in the schedule or the Project Parameter list.

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 it is useful for filtering your schedules. Some people may prefer to create this parameter as a project parameter, which is easier and faster. I recommend creating it as a shared parameter and including it in all your families with a predefined value. This way, as you load boilers, chillers, AHUs, and so on, they will automatically display on the appropriate schedules, assuming you have given them the appropriate value for the parameter and the schedule is using that as a filter.

Creating and Using Parameters in Families and Schedules

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.

1. Download the Ch6_Project.rvt and Ch6 Shared Parameters.txt files found at www.sybex.com/go/masteringrevitmep2013.

2. Open the Ch6_Project.rvt file. Open the VAV Schedule view. Access the Fields tab of the Schedule Properties dialog box, and click the Add Parameter button.

3. Create a Project parameter called Schedule Type with the following settings:

• Instance
• Discipline: Common
• Type Of Parameter: Text
• Group: Identity Data

4. Click OK to exit the Schedule Properties dialog box. For each VAV listed in the schedule, enter a value of VAV for the Schedule Type.

5. Access the Filter tab of the Schedule Properties dialog box. Apply the settings shown in the following dialog:

6. Click OK to exit the Schedule Properties dialog box. Notice that now only the VAVs are listed in the schedule. Click the Project Parameters button on the Manage tab of the ribbon. Notice that the Schedule Type parameter is now a project parameter that will be added to any mechanical equipment loaded into the project. Exit the Project Parameters dialog box.

7. Open the 1 - Lighting ceiling plan view. Click one of the light fixtures in the view, and click the Edit Type button in the Properties palette. Notice the Ballast Voltage parameter in the Electrical group. Click OK to exit the Type Properties dialog box.

8. Open the Lighting Fixture Schedule view. Access the Fields tab of the Schedule Properties dialog box. Notice that the Ballast Voltage parameter that exists in the lighting fixture family is not listed in the Available fields list because it is a family parameter.

9. Click the Add Parameter button on the Fields tab of the Schedule Properties dialog box.

10. In the Parameter Properties dialog box, select the Shared Parameter option and click the Select button.

11. Click the Edit button in the Shared Parameters dialog box. Click the Browse button in the Edit Shared Parameters dialog box, and browse to the downloaded Ch6 Shared Parameters.txt file location. (Note: If you have never selected a shared parameters file, you will be asked to select one. Browse to the location of the downloaded file.)

12. Set Parameter Group to Lighting Fixtures. Click the New button under Parameters on the right side of the dialog box.

13. Create a new parameter named Fixture Voltage. Set Discipline to Electrical. Set Type Of Parameter to Electrical Potential. Click OK to exit the Parameter Properties dialog box. Click OK to exit the Edit Shared Parameters dialog box.

14. In the Shared Parameters dialog box, set the parameter group to Lighting Fixtures. Select the Fixture Voltage parameter from the list, and click OK to exit the Shared Parameters dialog box.

15. In the Parameter Properties dialog box, select the check box in the lower-left corner to add the parameter to all elements in the category. Set the parameter as a type parameter, and click OK to exit the dialog box.

16. Notice that the Fixture Voltage parameter is now in the Lighting Fixture schedule. You can now input values for voltage into the parameter.

Voltage and Number of Pole Parameters - Instance vs. Type

Revit MEP has a little-known feature. The Voltage and Number Of Poles parameters allow you to specify circuit information when you create your circuits. The family lists the available voltage definitions for the project. Refer to the following dialog for an example:

---

View and Sheet Parameters

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 subdiscipline 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 2013. 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 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 6.19.

Figure 6.19 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 6.20 shows this example on a titleblock in a sample project.

Figure 6.20 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.

Working with Formulas

Formulas let you create some truly intelligent families and in most cases can increase your designers' efficiency by automating certain tasks. Working with formulas in Revit has its own challenges that you need to be aware of. They are case sensitive, they are “aware” of units, and they won't work properly if your parameters use mathematical symbols (/*-+) in their naming convention. Table 6.1 lists basic operators used in formulas. Table 6.2 gives a list of conditional statements used in formulas.

Table 6.1 Basic operators

Table 6.2 Conditional statements

Sample Conditional Statements

Conditional statements are a very powerful way of controlling the behavior of your Revit families. For the most part, conditional statements work exactly the same way they do in Excel or any other program that supports them. Here are few examples for the most common conditional statements:

Simple if Statement

if (Neck Size<10″,16″,18″)

Formula That Returns Strings

if (Neck Size>10″,“Neck Size is too Big “Neck Size is Correct”)

Using Logical and

if(and(Maximum Air Flow < 1000 CFM, Auto Size), 8″, 10″)

Using Logical or

if(or(Maximum Air Flow < 1000 CFM, Auto Size), 8″, 10″)

Using Logical not

if(not(Top Alignment), 0″, tan(15°) * b)

Using Logical not for Yes/No Parameters

not(myCheckbox)

Using if with Yes/No Condition

Length>10

(Note that both the condition and the results are implied.)

Embedded if Statement with Logical and

if(and(Maximum Air Flow < 391 CFM, Auto Size), 8″, if(and(Maximum Air Flow < 641 CFM, Auto Size), 10″, if(and(Maximum Air Flow < 1001 CFM, Auto Size), 12 1/2″, if(and(Maximum Air Flow < 1651 CFM, Auto Size), 15″, if(and(Maximum Air Flow < 2201 CFM, Auto Size), 17 1/2″, if(and(Maximum Air Flow < 3001 CFM, Auto Size), 18″, OVERRIDE HEIGHT))))))

Revit can be very picky about the units that you use in formulas. For example, you can't use Number parameter in a CFM parameter unless you do some sort of conversion. In most but not all cases, simply multiplying or dividing by 1 does the trick.

Rounding

Prior to Revit 2012 there were two options for rounding numbers: running them through an integer parameter (which automatically rounds them up) or adding 0.49 to the formula. In most formulas the rounding needs to be to the next higher whole number, even if the number isn't higher than .5, such as for the occupancy of people. If the number is 2.4, it really needs to be 3. For example, 2.4 + 0.49 = 2.89, which will be rounded to 3.

As of Revit 2012 we now have three additional functions to use, Round(x), Roundup(x), and Rounddown(x). Note that x is unit-less (also known as number, not CFM, not GPM, and so on). The Round(x) function rounds to the nearest whole number, for example:

round (1.2) = 1
round (1.5) = 2
round (1.7) = 2

round (-1.2) = 1
round (-1.5) = 1
round (-1.7) = 2

The Roundup(x) function rounds to the largest whole number greater than or equal to x, for example:

round (1.0) = 1
round (1.4) = 2
round (1.6) = 2
round (-1.0) = -1
round (-1.4) = -1
round (-1.6) = -1

The Rounddown(x) function rounds to the smallest whole number less than or equal to x, for example:

round (1.0) = 1
round (1.4) = 1
round (1.6) = 1
round (-1.0) = -1
round (-1.4) = -2
round (-1.6) = -2

The Bottom Line

Manipulate the properties of parameters.

The parameters used to define the properties of elements have properties of their own that define the behavior of the parameters and how they can be used.

Master It

It is important to know when and where parameters can be used for extracting data from the model or project. It is also important to understand how instance and type parameters are used. Describe how the use of instance and type parameters affects the way data is changed in a family.

Work with parameters in families.

Parameters created in family files are useful for defining the geometry of a family, and also for assigning engineering data to the family.

Master It

Certain families can have multiple family types. If a family has many types, all of them will be loaded into a project when the family is loaded. What can be done to limit the number of family types that are loaded when a family is inserted into a project?

Work with shared parameters.

Shared parameters are very useful because they can be used in schedules and in annotation tags. Shared parameters can be applied directly to families or added as project parameters.

Master It

Managing shared parameters is as important as managing your component libraries. Explain the importance of keeping a common shared parameters file for multiple-user environments.

Use parameters in project files.

The use of parameters is not limited to component families. Parameters can be added to any element that makes up a Revit project.

Master It

Parameters can be added to system families only by creating project parameters. When you create a project parameter, it will be added to all the elements in the chosen category. Explain why managing project parameters is important to using them in schedules within a project.