Parametric Air Terminal Family Breaks When Hosted to a Sloped Ceiling
You are building a content library for a client who standardizes on a single ceiling diffuser family. The family is face-based, with a nested bezel and a nested damper, and a type parameter for neck size driving the diffuser geometry via formulas. It works correctly when hosted to flat ceilings. On a project with a 15-degree sloped ceiling in an atrium, the diffuser inserts but the nested damper does not rotate with the ceiling; it stays horizontal and protrudes above the ceiling plane. Additionally, when the client changes the neck size from 300 mm to 400 mm, the nested damper does not resize - only the outer bezel does. The client wants one family that works on both flat and sloped ceilings and resizes fully. The library must be delivered in two weeks and will be used by 30 staff.
1. Diagnose both defects and describe the family structure changes required.
Read the worked answer
Defect 1 - nested damper not rotating: the damper is likely nested as a non-face-based or non-work-plane-hosted component, or it was placed on a reference plane that is not the host face. When the family is hosted to a sloped ceiling, the host face rotates, but a nested component only follows if it is hosted to the same work plane as the host and its own hosting behavior allows rotation. Fix: make the nested damper a face-based or work-plane-based family, and in the parent, host it to the ceiling's host reference plane rather than to a level or a fixed plane. Confirm the parent family's own hosting is 'Face Based' (not 'Ceiling Based' if you need sloped support - Ceiling Based families only host to horizontal ceilings).
Defect 2 - damper not resizing: the neck size parameter drives the bezel because the bezel's geometry is constrained by dimensioned reference planes tied to the parameter. The nested damper's internal geometry is not tied to any parameter in the parent. Fix: create a matching neck-size parameter inside the nested damper family, then in the parent, link the nested family's parameter to the parent's neck-size parameter (Modify > Family Types > associate, or use the nested family's parameter as a formula target). Without this association, the nested family keeps its own fixed dimensions.
Structural summary: face-based parent, work-plane-hosted face-based nested damper, one shared neck-size parameter associated across parent and nested, and no reliance on level-based hosting.
2. The client also wants the family to schedule neck size and airflow and to survive being copied between projects. What content-governance steps do you take before delivery?
Read the worked answer
Governance steps:
- Shared parameters. Neck size and airflow must be shared parameters from a controlled shared parameter file, not family parameters, so schedules and tags work across projects and the values survive copy/paste. Create them in the client's shared parameter file with defined names, GUIDs, and data types (length, airflow).
- Nested family parameters. Ensure the nested damper exposes the shared parameters so the parent can associate them; otherwise the schedule reads blanks.
- Purge and audit. Open each family, purge unused, and run a family audit. Check for unused types, orphaned reference planes, and any imported CAD. Verify no parameter names collide with the client's existing library.
- Hosting test matrix. Test the family on: flat ceiling, 15-degree sloped ceiling, vertical wall (if allowed), and unhosted placement. Test neck size change at both 300 and 400 mm and confirm the damper and bezel both resize. Test copy/paste between two projects and confirm parameters persist.
- Versioning and documentation. Name the family with a version suffix, record the shared parameter file version it depends on, and write a one-page usage note covering hosting requirements and the parameters that must be present in the project. Deliver the shared parameter file alongside the family - a family dependent on shared parameters is unusable without it.
- Rollout. Because 30 staff will use it, publish to the client's content library with a read-only status and a change log so local edits do not fork the family.