Tolerance stack-up analysis is still stuck in spreadsheets — so I built a tool that reads the CAD model

chenzefeng09 — Mon, 05 Oct 2026 15:06:30 +0000

A few months ago I watched a mechanical engineer spend most of a week on a tolerance stack-up for an assembly with about thirty contributors. Not designing — adding numbers in Excel. Column per dimension, sign per direction, a comment column explaining why each sign was what it was. At the end, the answer was a single worst-case number that nobody fully trusted, because three of the dimensions were turned with the wrong sign at least once during entry and nobody could prove they'd all been caught.

This is bizarre when you think about it. The CAD model already contains every distance, every fit, every mating face. The spreadsheet exists only because nothing reads the model and asks the obvious question: given how these parts can actually vary, will the assembly still work?

What stack-up analysis actually is

Take a linear chain — the classic case is three rings stacked in a housing bore. Housing shoulder-to-shoulder is 50.00 ±0.10 mm, each ring is 16.00 ±0.05 mm. The end gap is:

g = 50.00 − (16.00 + 16.00 + 16.00) = 2.00 mm nominal

Worst-case analysis adds the tolerances arithmetically: ±0.25 mm, so g ∈ [1.75, 2.25]. Guaranteed — no conforming set of parts can break it.

RSS (root-sum-square) treats each ±t as roughly ±3σ and combines in quadrature: √(0.10² + 3×0.05²) ≈ ±0.13 mm. Much tighter, but a small fraction of assemblies will fall outside that band — you've traded a guarantee for a quantified yield.

Same drawing, same parts. One method says "your 1.80 mm minimum fails," the other says "you're at 4.5σ, ship it." Which answer you're allowed to believe is an engineering decision — worst-case for safety and unmeasurable processes, RSS where you have controlled production data. I wrote up the full mechanics with worked examples and a separate piece on choosing between the methods if you want the detail.

Where it actually breaks

The spreadsheet approach fails quietly, not loudly:

Sign errors. Thirty contributors, each entered by hand with a direction. One flipped sign and you get a confident, wrong number.
The chain isn't linear. Fastener clearance lets parts float and rotate. A flatness callout tilts a face. Real assemblies are 3D kinematics; a 1D sum is systematically optimistic about tilt-driven variation.
Contact depends on the answer. Whether a pin bottoms on the left or right face changes the chain itself — the worst case has to be searched, not summed.
The inputs live in different vocabularies. An ISO 286 fit code like H7/g6, a position callout on a bolt circle, and a general-tolerance block all express variation differently. Normalizing them by hand is error-prone.

Teams doing model-based definition hit a subtler version of this: they invest in annotating the model with PMI (Product & Manufacturing Information — dimensions, datums, GD&T living on the 3D model), then assume the problem is solved. But PMI states requirements; it doesn't evaluate their combined effect. Ten features each inside tolerance can still produce a binding gap. Nothing in the PMI knows about the loop it participates in.

What I built

SuperNX does the loop end-to-end inside Siemens NX:

Drop in a .prt file — it extracts the geometry and features directly.
It infers assembly intent — which joint is a pin-in-hole, which is a slider, which is a press fit — rather than applying a rule table.
It assigns tolerances the way the mechanism actually works (ISO 286 fits, ISO 2768 defaults, or your custom standards) and runs worst-case + statistical analysis with per-contributor sensitivity.
It writes back a traceable report and a toleranced model — and a failing key characteristic stops the PMI write-back, so nothing unverified reaches the drawing.

Two deliberate constraints, stated plainly: it only speaks Siemens NX (.prt), and every number it reports traces to a real model measurement or a published standard — if it can't be proven, it isn't reported.

It's free to start: nxtolerance.com. If you've done stack-ups by hand, I'd genuinely like to hear where the spreadsheet version broke for you — sign errors, correlated contributors, or the "thirty contributors and no one trusts the sign column" problem.

I dug up the US State Department's rejected passport photo examples — here's what actually gets applications bounced

chenzefeng09 — Mon, 05 Oct 2026 06:49:13 +0000

A few weeks ago I started building a free passport-photo tool, and I did the thing you do: I went looking for the official examples of acceptable and rejected photos. The US State Department publishes them — real sample photos with labels like "too dark," "shadows on face," "head tilted" — the actual failure modes the acceptance agents check for.

What I didn't expect: the page is a graveyard. Half the example images 404. The ones that remain are 220×220 thumbnails buried in a layout from 2012. If you want to learn what a compliant photo actually looks like, the official source is barely usable.

So I pulled the full set from the Wayback Machine — 44 real government example photos — and rebuilt the gallery the way it should have been built. Then I read the actual requirements (ICAO 9303 + the State Department's own photo guide) and cross-checked every rejection label against the written rules.

Here's what I learned that surprised me.

The rejection reasons are mostly lighting, not pose

The single biggest bucket of rejected examples isn't smiling or glasses — it's lighting defects:

Uneven lighting (one side of the face darker)
Shadows across the face or behind the head
Washed out / overexposed (too much light destroys facial detail)
Too dark (detail lost in shadow)

Pose problems — tilted head, eyes closed, not facing camera — are obvious and rare. Lighting problems are subtle, and they're the ones that bounce applications weeks later by mail.

"White or off-white background" is doing a lot of work

The spec says the background must be plain white or off-white. In practice the examples show rejections for:

Background that's technically light but has texture (a wall with visible paint pattern)
Background with a gradient (bright near the head, darker at the edges — common with on-camera flash falloff)
Slightly gray or cream backgrounds that read fine on screen but fail the "white or off-white" test at inspection

The fix that actually works: stand further from the wall so your shadow doesn't fall on it, and use two light sources at 45° to kill gradients.

Head size tolerances are tighter than they look

US passport photos require the head to be 1 inch to 1⅜ inches (25–35mm) from chin to crown. In the examples, several rejections are just… slightly wrong. The eye-line also has to sit in a band — roughly 1⅛ to 1⅜ inches from the bottom of the photo.

This is the part that's nearly impossible to eyeball when you're holding a phone at arm's length. It's also, honestly, why I built the tool — cropping to 2×2 inches is easy; getting the head-height ratio and eye-line into spec is the part that needs a ruler overlay.

The nerd detail: 300 DPI and pixel dimensions

One more thing that trips people up: a digital passport photo for the US should be 600×600 pixels minimum (at 300 DPI for the 2×2 inch print). Screenshot-quality crops often fall below that even when they look fine on a phone screen.

What I shipped

I put all 44 recovered examples — the good, the bad, and the "what were they thinking" — into a browsable gallery grouped by rejection reason: passport photo examples, official set. Each example is annotated with the actual rejection label, and every group links to a deeper explainer.

The tool itself does the crop/scale/background work: photopassport.online — free, runs client-side, no upload (photos never leave your browser).

If you're building anything in the document-photo space, the State Department's public example set is worth archiving before it rots further. And if you've had a passport application bounced for a photo reason, I'd genuinely like to hear which one — I'm keeping a tally.

DEV Community: chenzefeng09