Fabrication Generator: cones, cylinders and clamps with a second implementation that checks the first

Problem

Cones, cylinders and band clamps are the parts a plate shop develops most often, and the ones most often developed slightly wrong. Free calculators take a diameter and hand back a blank without asking which surface the diameter was measured on, whether the part is rolled or bump-formed on a brake, or what the seam allowance is. The result is a blank that is short by a thickness, a cone whose facets do not close, or a clamp with one tab where two were needed. Each mistake is discovered on plate.

The demonstration goal: one program a brake operator, a roll operator and a laser operator can all work from, producing the five files a job actually needs, with every assumption printed on the drawing.

Constraints

• Portable: one executable, no installer, no admin rights, no runtime, no network, no account.
• Real DWG for the drawing — not a renamed DXF — without a paid CAD SDK.
• Diameters measured the way a fabricator measures them: at the cut edge, with calipers.
• No invented shop data: K-factor, bend allowance, seam and roll settings are inputs or are labelled as assumptions on the drawing.
• Works under any Windows locale and keyboard layout, because a decimal comma read as a thousands separator is a scrapped plate.
• Built and validated on one machine; no physical part made. Stated, not glossed.

Engineering logic

The formula that matters is the thickness datum. On an as-cut cone the end is a narrow band of width t lying in the plane of the plate, perpendicular to the generator, so its radial extent is t·cos θ, not t:

OD − ID   = 2·t·cos θ
mean dia  = ID + 2·K·t·cos θ        (K = 0.5  →  ID + t·cos θ)

It reduces to the cylinder rule ID + t as θ → 0, and there is a test for that limit. Every free calculator tested ignores thickness entirely; the common shop shortcut carries the cylinder rule over to cones unexamined. The difference on the reference cone is small — 0.382 mm on diameter, 1.2 mm on a 1,902 mm blank — and it grows with taper. It is also exactly the kind of difference that is a shop decision rather than a bug, so it is quantified and printed instead of silently chosen.

For press-brake cones the bend angle between facets is not assumed to be 360/N. The faceted shell is constructed in three dimensions and the dihedral angle measured from the actual panel normals; the end profile is kept as arcs, not chords, because each flat facet keeps the arc edge it had in the blank. Treating it as a chord polygon overstates out-of-round by about 10 %.

System

Five .NET 8 projects with one-way dependencies: pure geometry (no UI, no file formats) → materials and gauge tables → a renderer-independent drawing model → exporters (DXF via netDxf, DWG via ACadSharp, PDF via PDFsharp, JSON) → a WPF application. Exporters consume the drawing model and never recompute geometry, so a number on the PDF is the same number in the DXF.

Each job produces one folder: *_CUT.dxf (1:1, layer CUT holds cut geometry only), *_DRAWING.dwg (AC1032), *_DRAWING.pdf (vector, to scale), *_JOB.json (every input, to regenerate or revise) and a README with every derived dimension and the assumptions in force.

What the product refuses to do is as much a part of the design as what it does: it will not invent a K-factor from a material name, will not silently apply a bend allowance (it reports bend data and prints VERIFY BEND ALLOWANCE AGAINST SHOP TOOLING), will not guess a seam, will not calculate roll positions without a machine profile, and will not claim structural capacity, bolt rating or code compliance.

Validation

Four independent methods, none of which was adjusted to match another. All figures are from the release validation report for v0.2.0, dated 2026-09-02, reproduced under src/content/work/fabrication-generator/ in the site repository.

• A second implementation in Python, deliberately derived by different routes (the faceted-cone dihedral from a cross product of real edge vectors rather than any closed form), agreeing with the production engine on 508 checks across 60 boundary cases to 1e-7.
• Independent file parsers: the DXF re-read with netDxf and with ezdxf; the DWG converted by the ODA File Converter and re-parsed, with bulge values surviving the round trip — proof it is a real DWG.
• Eight external calculators driven in a browser with the same inputs: seven agree to every digit they print; one differs on the thickness datum described above, and that difference is on the record.
• The published executable itself, driven through its own user interface from a clean folder: every dropdown opened, the Ukrainian keyboard layout switched in, a job generated, all five files written and checked, the window closed and reopened.
• A person looking at the PDF. Every automated check passed a drawing whose bend table was clipped at row 21 of 23 and whose NOTES block — including the bend-allowance warning — had dropped off the sheet. Visual review found it. It is now part of the release gate.

One more check, added for this page: this site's TypeScript geometry core, written separately from the generator, develops the same cones. Two implementations, two languages, one datum.

The generator prints S-1002 to two decimals and the reference cone to seven, so agreement is to the printed precision. Regenerate: npx tsx scripts/crosscheck-generator.ts.

Result

• 1,078 checks, 0 unexplained failures, at release 0.2.0.
• One real defect in the shipped 0.1.0 (the GUI threw on the first click of any control) found, root-caused to a globalization setting, fixed, and fenced with 147 new tests — and the lesson recorded: 168 passing tests had not constructed the window once.
• Two further defects found only by the new UI tests: typed input destroyed on a unit switch, and unit conversion drifting by re-reading rounded text. Both fixed; five round trips now return exactly 600.
• A thickness-datum convention that every free calculator gets silently wrong, quantified at 0.063 % on the reference cone, documented as a shop decision.
• A single 64.4 MB executable, verified to need nothing beside it.

What was not achieved, stated plainly from the report: no physical part has been made from the output; no measured shop bend data ships; springback is not modelled; DWG dimensions are text rather than associative entities; the executable is unsigned.