VAV Box Schedule Shows Wrong Airflow After Family Swap
A 220-room hotel project uses a single VAV box family with a shared parameter for design airflow. Mid-project, the mechanical contractor asks you to swap 40 terminal units on the guest-room floors from the original family to a manufacturer-specific family that carries its own airflow parameter with a different name and unit (L/s instead of CFM). After the swap, the VAV schedule shows blank airflow for all 40 units while the remaining 180 units are correct. The schedule is filtered by a shared parameter 'Zone Served' and sorted by level. The engineering team is issuing a 60% design package tomorrow and the airflow values feed a duct sizing calculation export. The manufacturer family was loaded from a third-party source and its parameters are not shared.
1. Explain why the schedule cells are blank and identify the two viable remedies with their trade-offs.
Read the worked answer
The schedule is reading a shared parameter ('design airflow') that exists in the project. The original family's parameter was bound to that shared parameter definition. The manufacturer family has a family parameter of a different name, and because it is not a shared parameter, it cannot map to the project's shared parameter. Revit schedules show blanks rather than errors when a scheduled shared parameter is absent from an element's family - the 40 swapped units simply have no value for that parameter.
Remedy A - edit the manufacturer family: open the family, add a shared parameter using the project's shared parameter file with the exact same name, GUID, and data type, then associate the family's native airflow parameter to it via a formula (Design Airflow = Native Airflow Param). Reload. Advantages: preserves the manufacturer's geometry and data; the association is live, so future edits to native values propagate. Trade-off: you must convert units inside the formula (L/s to CFM, factor ~2.119) and the association must be done in the family editor, which requires the family to be editable and re-saved - a content governance decision, since you are modifying vendor content.
Remedy B - add the shared parameter directly to the swapped instances and enter values manually. Faster, but creates 40 static values that will not track the manufacturer's native parameter, and any future family reload may drop them.
Given a 60% package due tomorrow and a calculation export depending on the values, Remedy A is correct for durability; Remedy B is only acceptable as a same-day stopgap if you flag the values as unverified.
2. The duct sizing export reads airflow in CFM. Describe how you validate the converted values before issuing, and what you check in the schedule itself.
Read the worked answer
Validation plan:
- Unit check first. Confirm the manufacturer parameter's unit type is actually L/s and not a unitless number. If it is unitless, the formula conversion will silently produce wrong values - this is the most common failure and must be verified before any conversion.
- Build the conversion into the family, not the schedule:
Design Airflow (CFM) = Native Airflow (L/s) * 2.11888. Revit handles unit conversion automatically if both parameters carry correct unit types, so prefer associating parameters of matching unit types and letting Revit convert, rather than hard-coding a factor. Hard-coded factors break if the vendor later changes units. - Spot-check a sample. Take 5 of the 40 swapped units, read the native L/s value from the family, compute the expected CFM by hand, and compare to the schedule. A 200 L/s unit should read about 424 CFM.
- Schedule integrity checks. Confirm the schedule's filter on 'Zone Served' still returns all 220 units - a family swap can break the filter if the new family lacks that shared parameter, which would hide rows rather than blank them. Confirm sorting by level still groups correctly. Add a calculated value or conditional formatting to flag any row where airflow is zero or blank so the issue cannot recur unnoticed.
- Export check. Open the calculation export and confirm 220 rows, no zeros, and that the 40 swapped units are within the expected range for guest-room terminals.
Document the family modification in the content log so the next project does not inherit the mismatch.