Tolerance Analysis on NX PMI: From Semantic Annotation to Proof
Product & Manufacturing Information in Siemens NX — dimensions, datums, feature control frames, surface finish and notes living directly on the 3D model — is the backbone of model-based definition. It is also frequently misunderstood: teams invest in annotating the model and then assume the tolerance problem is solved. It is not. PMI states requirements; it does not evaluate their combined effect. Understanding that gap is what makes PMI worth the effort.
How PMI actually lives in the model
NX keeps PMI as first-class objects in the part file, not as drawing-sheet decoration. From the PMI application you create dimensions and GD&T callouts that attach to model geometry — faces, edges, axes — and organize them into PMI views (reoriented model states that frame a readable set of annotations). Three properties make them different from a 2D dimension string:
- Association. A PMI dimension knows which faces it measures. Change the model and the annotation follows; delete the face and the annotation tells you it is broken rather than silently pointing at nothing.
- Semantics. A semantic feature control frame carries its datum references, tolerance value and modifiers as structured data — a downstream tool can read "position Ø0.1 MMC to A-B-C" without parsing pixels.
- Exchange. Semantic PMI survives export — NX writes it into JT and can put it in STEP AP242 — which is exactly how analysis tools, CMM programming and suppliers consume it without a drawing.
The discipline that matters: pick the geometry the requirement genuinely controls. A position frame dragged near a hole but associated to the wrong face is semantic in name only.
Semantic vs decorative annotation
NX will happily let you put non-semantic text and sketchy "PMI-like" callouts on a model, and legacy data migrated from drafting often arrives that way. The distinction matters downstream:
| Semantic PMI | Decorative annotation | |
|---|---|---|
| Geometry link | Bound to faces/edges; updates and validates | Screen position only; drifts out of sync |
| Machine-readable | Datums, values, modifiers as data | A string a human must re-read |
| Export | JT / STEP AP242 carry it structurally | Flat text at best |
| Analysis | Drives tolerance zones and chain building | Invisible to analysis tools |
If the model is meant to feed anything beyond eyeballs — CMM, supplier quoting, or stack-up analysis — decorative annotation is technical debt wearing a finished look.
Why annotated is not the same as analyzed
PMI answers, per feature: how far may this deviate? Tolerance analysis answers, per assembly: given all of those allowances at once, does the product still work? They are different questions and the model does not bridge them automatically:
- Stack-ups are emergent. Ten features each inside tolerance can still produce a binding gap or a leaking seal. No single PMI object knows about the loop it participates in.
- Key characteristics live between parts. The gap between a door and its fender, the preload on a bearing pair, the alignment of two bores across a joint — none of these belong to one part's PMI. They are properties of the assembled state.
- Joints add their own variation. Fastener clearance, float, and contact order are assembly inputs that no amount of per-part annotation captures.
- The method is a decision. As worst-case vs statistical analysis covers, the same PMI data yields different answers depending on the method — someone has to choose, per loop, deliberately.
What an analysis run consumes and produces
A real analysis reads the semantic content rather than screenshots: nominal distances between the relevant features, each feature's tolerance zone (from PMI values or fit codes resolved through ISO 286), and the mating structure of the assembly. The output that justifies the effort is not a single number but:
- the predicted range — worst-case and statistical — for each key characteristic;
- per-contributor sensitivity, so you tighten the dimension that actually moves the answer instead of the one that happened to be in the spreadsheet;
- a traceable report — which inputs, which method, which assumptions — that survives design review.
Two inputs routinely get forgotten in that list. First, clearances: the play inside a bolted joint or a splined connection is a genuine contributor that belongs in the model even though no part "owns" it. Second, the state of the PMI itself — a callout that was never associated, or a dimension that survived three redesigns pointing at a face that moved, reads as data but behaves as noise. An audit pass on the annotation before trusting the analysis is time well spent.
Getting results back onto the drawing
Analysis output has to re-enter the model loop or it becomes a static PDF. The flow that works: failing or marginal key characteristics drive tolerance edits at the source; updated values go back into PMI on the affected features; the analysis re-runs against the new state. A toleranced model and a matching report — not a marked-up screenshot — are the deliverables.
That closed loop is what we built SuperNX to automate inside NX workflows: it measures the chains straight off the model geometry, runs the analysis, and writes results back — a report plus a toleranced model. And because write-back is where unverified numbers would do the most damage, a failing key characteristic stops the PMI write-back rather than letting a bad value reach the drawing. Annotation is the requirement, analysis is the proof — the useful product keeps them honest against each other.
Practical checklist
- PMI on functional geometry only; semantic objects, not text.
- Datums chosen to match how the part is actually fixtured and measured.
- Key characteristics declared at the assembly, not implied.
- Analysis re-run on every model revision that touches a chain — stale analysis is worse than none.