DEV Community: Poetical Engine

I Open-Sourced the ISO 286 Fit Tables Behind My Tolerance Tool

Poetical Engine — Sat, 10 Oct 2026 03:43:49 +0000

Tired of PDF tables, I keep a computed subset of ISO 286-2 in code — limits & fits for the hole-basis combinations that actually show up on drawings: IT5–IT8, shafts f/g/h/k/p, all 13 size bands to 500 mm. Plus ISO 2768-1 general tolerances.

Now it's a standalone MIT repo. Three ways to use it:

python iso286.py 25 H7/p6
# H7/p6 @ 25 mm  [interference]
#   hole      0 / +0.021 mm
#   shaft     +0.022 / +0.035 mm
#   clearance -0.035 … -0.001 mm

Or the same module in TypeScript, or just fits.json as raw data.

https://github.com/chenzefeng09/iso-286-fits

Honest scope note: this is the common-design subset — shafts outside f/g/h/k/p, grades outside IT5–IT8, and shaft-basis fits aren't in it. For those you still need the full ISO 286-2 tables or an interactive lookup. The free browser version of this calculator lives at https://nxtolerance.com/standards if you want numbers without code.

Where it came from: I built this for a tolerance-analysis tool on NX .prt models, and realized the table itself was worth more released than locked inside one app. Corrections welcome — tabulated values match the standard, but a second pair of eyes never hurt.

Worst-Case vs Statistical Tolerance Analysis — How to Actually Choose

Poetical Engine — Sat, 10 Oct 2026 02:18:09 +0000

Worst-case and RSS are not two tools that compute the same thing with different precision — they answer different questions. Worst-case asks can this assembly ever fail with conforming parts? RSS asks how often will it fail in production? Choosing between them is a business and risk decision that engineers make implicitly every time they reach for a method by habit. This guide makes the choice explicit. (The mechanics and a worked example are in the stack-up guide; this article is about the decision.)

The recap in one line each

Worst-case adds tolerances: T = ΣTi — guaranteed bounds, pessimistic at scale. RSS adds variances: T = √ΣTi² — a statistical band, typically much tighter, that a small fraction of assemblies will still escape. Everything else in this article is about when the guarantee is required and when the fraction is acceptable.

When worst-case is the only honest answer

Safety and regulatory scope. If a failed stack-up hurts someone or breaches a certification requirement, "about 3 ppm" is not an answer — it is an admission that conforming parts can still hurt someone. Brake travel, medical dosage mechanisms, crash structures: worst-case, full stop.
You cannot verify the distributions. RSS on a process you have never measured is numerology. First articles, new suppliers, one-off tooling — if you do not know the actual spread, you do not have a statistical model, you have a hope formatted as math.
The contributors are correlated. Features machined in one setup, cavities in one mould, parts from the same batch drift together. Correlation defeats the independence assumption at the heart of quadrature — worst-case correlation is a real outcome, not a remote one.
The chain is short and hostile. With two or three contributors, the worst-case penalty is small and the RSS benefit is modest anyway. Do not spend statistical assumptions where arithmetic is cheap.

When statistical analysis legitimately saves money

Manufacturing cost against tolerance is not linear — it is a staircase. Moving a ±0.10 mm requirement to ±0.05 mm rarely costs 2×; it can move the feature off finish-machining and onto grinding, and tightening further forces lapping or selective assembly. Each step on that staircase is a different machine, a different cycle time and often a different supplier tier.

RSS buys room on that staircase. In a chain of n comparable contributors, RSS allocation lets each individual tolerance widen by roughly √n versus the worst-case split — six parts each get about 2.4× more tolerance for the same assembly requirement. Widening ±0.05 to ±0.12 on several features can legitimately move an entire part down a process step. That is real money, and it is why production engineering defaults to statistical methods where they are defensible.

Defensible means: independent contributors, a controlled process (Cpk data you actually looked at), distributions that are at least plausibly normal-ish, and a fallout rate someone has consciously accepted — typically the fraction of assemblies beyond a ±3σ-equivalent band.

Hybrid strategies that work

WC shell, RSS interior. The safety-relevant loop — the one that opens the brake, unseats the seal — is verified worst-case; the non-critical loops inside the product go statistical. Most real products are exactly this, and making the boundary explicit is what design reviews are for.
Inflated RSS for non-normal inputs. Where contributors are uniform or skewed rather than normal, a common correction multiplies the RSS band by a factor (about 1.5 for uniform distributions — the Bender/dynamic-RSS style adjustment) before calling it a 3σ-equivalent. It narrows the optimism without abandoning the method.
Mean-shift budgeting. Processes drift; the classic convention allows about ±1.5σ of mean shift on top of the spread. Folding a shift term into the model is more honest than pretending the mean is pinned forever.
WC on purchased parts, RSS on yours. Vendor components often arrive with datasheet limits that are true worst-case bounds — treat them as fixed extremes and analyze only your own chain statistically.

The misconceptions that burn people

"RSS is a loosening budget." It is not free tolerance. RSS moves the risk from "impossible" to "rare" — a real number of real assemblies will fail, and that rate is a commitment, not a rounding error.
"RSS handles everything if n is large." Independence failures do not average out; they are systematic. Correlated contributors can make the actual spread worse than worst-case predicts if the model assumed they cancel.
"3σ means impossible." A ±3σ band still leaks roughly 0.27% of assemblies in the ideal normal case — per loop, per unit shipped. At volume, that is a queue at your door.
"Mean-centred forever." Tool wear, thermal drift and operator differences shift means continuously. A model with no shift term is calibrated to a factory that does not exist.
"Pick one method for the whole product." The unit of choice is the loop, not the product. Mixed methods are normal engineering.

Five questions before you trust the answer

What does a failure of this loop cost — warranty, rework, or someone hurt?
Do I have process data for every contributor, or am I assuming distributions?
Are any contributors made together, from one die, batch or setup?
What fallout rate am I accepting, and who else has signed that off?
If the answer is marginal, which contributor's sensitivity is highest — and is tightening that one cheaper than my fallback?

The last question is where tooling earns its place. SuperNX reports per-contributor sensitivity alongside both worst-case and statistical results, so the "tighten or accept" conversation is about a ranked list of dimensions rather than a single fused number — the decision framework above applied to the actual model instead of to instinct.

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

Poetical Engine — 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

Poetical Engine — 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.