ACP Revit Mechanical common mistakes
ACP Revit Mechanical · Understand the traps and how to avoid them.
Editing the shared coordinate system or project base point in the local copy after linking the architectural model, then synchronizing, which shifts every linked model and hosted HVAC element.
Candidates treat the base point as a drafting marker and move it to align views visually, not realizing that acquiring coordinates from the link is a one-time, project-wide operation that propagates to all team members.
What to do instead
Acquire coordinates from the architectural link once, publish the resulting shared coordinates, and thereafter only move the project base point with the clip state understood; verify alignment by spot-checking a known grid intersection before syncing.
Creating worksets per view or per floor rather than by functional ownership, so that HVAC, plumbing, and linked-model content end up on the same workset and cannot be isolated or permissioned.
Worksets are misread as a visibility tool equivalent to view filters, so candidates subdivide by whatever they are currently looking at instead of by who edits the content and how it must be loaded.
What to do instead
Define worksets around ownership and load behavior (for example, one per discipline system group plus a dedicated workset for each linked model), document the scheme in the BIM execution plan, and use view filters and templates for visibility instead.
Modeling duct runs with the wrong system classification or without assigning a system, then expecting the air terminals to appear in the supply, return, and exhaust system schedules.
Candidates focus on geometry and elevation and assume the system is inferred from the connected air terminal family type, but system membership depends on the connector's system classification and an explicit system assignment.
What to do instead
Before drawing, confirm the duct system type and the family connector classification match; after layout, use the system inspector to verify every terminal is connected to the intended system, and correct connectors in the family editor rather than overriding in the project.
Placing a single flexible duct segment to connect a main to a diffuser across a long, offset distance, producing a sagging, oversized, or self-intersecting run that fails coordination review.
Flex duct is the quickest way to close a gap, so it is used as a routing shortcut rather than for its intended short final connection, and the automatic routing behavior is not checked.
What to do instead
Route rigid duct to within a short final offset of the terminal, use flex only for that last connection, set the flex length and preferred bend radius as type parameters, and review the run in 3D before issuing.
Setting pipe slope only on individual segments and then assuming the whole run drains, leaving fittings and short branch stubs at zero slope or with reversed slope.
Slope is a per-segment instance property, and the slope value shown in the properties palette reflects only the selected element, so candidates believe a single application propagates along the connected run.
What to do instead
Use the slope controls and the slope arrow while drawing the run so each new segment inherits the slope, then select the full run and verify slope values and invert elevations segment by segment, checking the rise/run direction against the intended flow.
Building pipe systems with the wrong pipe type or system classification, so the fittings resolve to the wrong material and the system cannot be sized or scheduled as domestic water, sanitary, or hydronic.
Pipe type, system classification, and fitting routing preferences are three separate settings, and candidates change only the one visible in the properties palette without checking the routing preference that governs which fitting families are inserted.
What to do instead
Establish pipe types and routing preferences in the project template before modeling, verify the system classification on the pipe connector, and test a short run to confirm the correct fittings are placed before committing to full routing.
Using nested shared parameters incorrectly, or creating project parameters where a shared parameter was required, so equipment data does not appear in schedules or tags.
Candidates add parameters directly in the project or family without loading them from the shared parameter file, so the parameter exists in one context but is not recognized as the same parameter elsewhere.
What to do instead
Create equipment parameters in the shared parameter file first, add them as shared parameters in the family, mark them for scheduling, and verify after loading that the schedule field and tag label resolve to the same parameter.
Over-constraining family geometry with locked dimensions and alignment constraints, so the family breaks or produces constraint errors when a type parameter changes.
Candidates lock every dimension to make the family behave predictably, not realizing that redundant or conflicting constraints cannot be satisfied simultaneously when parameters drive the geometry.
What to do instead
Drive geometry from a small set of named parameters with reference planes, lock only the dimensions that must remain fixed, flex the family at extreme parameter values in the family editor, and remove constraints that duplicate a parameter relationship.
Running a heating and cooling load analysis with default or unverified construction and space settings, then reporting the result as the design load.
The analysis tool runs without complaint on incomplete space bounding, so candidates accept the output without checking that spaces are enclosed, that the building construction and internal loads match the project, and that the location and weather data are correct.
What to do instead
Before running, verify the project location, confirm every space is bounded and placed at the correct level, review construction types and internal load values against the project basis of design, then compare results against a hand check for one representative zone.
Building schedules that report wrong totals or missing elements because filters, sorting, and the itemized versus totals display were not reconciled before the schedule was placed on a sheet.
Candidates add fields and filters until the schedule looks plausible, but do not check whether filters exclude elements without the parameter populated, and do not verify that the totals row aggregates the same set of rows that is displayed.
What to do instead
Audit the schedule by temporarily removing filters to see the full element count, confirm the parameter is populated on all included elements, verify sorting and grand totals settings, and cross-check one schedule total against a filtered view count.