dankbuild Electronics

Measuring a dev board for 3D printing when the size is not published

Method·Not a build-log

If you just want a holder, do not read this. Search Printables, MakerWorld, Cults3D or Yeggi for your board and you will find a ready-made model, free, from people who have printed theirs. They have more models than this site will ever have and that is the right place to get one. This page is about the step before a model exists: how you decide a dimension nobody has written down, and how you check a generated solid before you spend filament on it.

Nothing described here has been printed. The two parts this page refers to have not been printed — not by me, not by anyone I know of. Every check below is a check a computer performed on geometry. No printer, no caliper, no fit, no tolerance, no material result, no photograph of a part. Read this as a method, and judge the method; there is no finished object at the end of it.

What I tried, and what actually came back

The part in question parks an ESP32-S3-DevKitC-1. To cut a bay for it you need the board's outline width. The repository's own notes claimed that dimension could not be sourced: that the vendor's board page renders with JavaScript and that the dimensions PDF it links to returns 404. Before repeating a claim like that in public I re-ran it. The claim was stale, and this page is the correction.

What I got, this run. The documentation URL the notes were built on, docs.espressif.com/projects/esp-dev-kits/en/latest/esp32s3/esp32-s3-devkitc-1/user_guide.html, still returns HTTP 404 — so the original negative result reproduces exactly. But one negative on one URL is not a proof of absence, and walking up the path shows why: the directory index at .../esp32-s3-devkitc-1/index.html returns 200, and every link in it points at user_guide_v1.1.html, which also returns 200. The guide was renamed to a versioned filename, and the old unversioned path was simply left to 404. Nothing was withdrawn. A link rotted.

That guide's related-documents list includes an item labelled “ESP32-S3-DevKitC-1 Dimensions source file (DXF)”, served from dl.espressif.com/dl/schematics/esp_idf/. It returns 200, as image/vnd.dxf, 743,753 bytes, alongside a PDF rendering of the same drawing at 124,348 bytes. The dimensions source exists and is public. Publishing “you cannot get this” when you can is the same category of error as inventing a number, so the bench parts page now carries the correction.

One place still carries the old wording, and it is worth saying which. The original claim is a header comment inside models.cjs, and that file's body is concatenated verbatim into the geometry module the browser runs — the string “JS-rendered” is present in the committed module today. The parity check described at the end of this page asserts that module byte for byte, so rewriting one sentence of English in the generator is not a prose edit; it forces a regeneration of the geometry and a re-verification of the plate against the published STL. That is a different change from writing this page, and doing it as a drive-by is exactly the habit the check exists to prevent. So models.cjs.txt still reads “its linked dimensions PDF 404s”. It is wrong, this page is the current reading, and the correction is owed to the generator the next time its geometry is legitimately rebuilt.

Available is not the same as written down

So I opened the DXF. It is an AutoCAD 2013 file, and it contains zero DIMENSION entities — there is not a single dimension callout in it. Its text entities are silkscreen designators: R9, U4, J2, ESP32-S3-DevKitC-1. The header's drawing extents cover the whole annotated sheet rather than the board outline, so reading them as a board size would be wrong by a wide margin. The PDF rendering has no extractable text layer at all; it is a picture of a drawing.

This is the useful lesson, and it is more general than one board. The authoritative source is vector geometry, not a table of numbers. To get a width out of it you open it in CAD and measure the outline yourself. So measuring is not avoidable here — it was never avoidable. The only real choice is where you measure: in CAD, against a file, or in plastic, against the board on your desk. Both are measurements. Neither is a number someone handed you, and that is exactly why this page will not quote one.

Why a printed gauge beats a confident guess

The measurement instrument here is a stepped gauge: six U-channels of increasing width, 24.6, 25.0, 25.4, 25.8, 26.2 and 26.6 mm, defined in models.cjs. You lower the board into each from above; the narrowest channel it settles into without forcing is the board width, to within the 0.4 mm step. A rib count beside each channel identifies it, so the reading survives putting the part down and picking it up again. The channels are only 16 mm long and open at both ends, so you engage a short section of the PCB edge instead of fighting the pin headers.

A ladder of six trial widths is cheap. A guess is not, because a guess is indistinguishable from a fact once it is written into a parameter file — and search will happily hand you a confident width belonging to a different board in the same family. The gauge cannot be wrong in that way. It has no opinion; it only fails to fit.

Make being wrong cheap: leave the uncertain axis open

The second half of the method costs nothing and matters more. In the bench plate, the devkit bay is open at both ends on purpose. Only the width is constrained; the length is not. Get the length wrong and the board simply overhangs the end of the bay. It cannot fail to fit. That is a design decision made specifically because a dimension was uncertain: you spend a constraint only on the axis you can defend, and you let the axis you cannot defend run off the edge of the part. test-fit.cjs asserts that openness rather than trusting it, with a check whose name says what it is for: “the devkit bay is OPEN end to end, so an unverified board LENGTH cannot bind”.

Four layers between the geometry and the printer

Generated geometry looks right in a preview long after it has stopped being right. Four independent checks stand between the model and a print, and one of them caught a real defect.

  1. The mesh cannot self-overlap. stl.cjs builds solids as boxes that touch but never interpenetrate, and its check() rejects any pair with positive overlap on all three axes at once — the self-intersecting shells that make slicers produce nonsense.
  2. The dimensions are asserted, not eyeballed. test-fit.cjs takes a scan line through the finished solid at wall height and reports the clear span, the way a caliper would. Running it now returns 9 assertion(s) passed. This is the layer that earned its place: during design it caught a stray term that had inflated the devkit bay by millimetres, which would have left the board rattling in a part that still looked correct on screen.
  3. The bytes on disk are re-read by a stranger. verify-stl.cjs parses the written STL again with an independent reader, because a generator validating its own memory tells you nothing about what landed in the file. Nothing is written at all unless the mesh check passes first — see build.cjs, which leaves no file behind when a model is invalid.
  4. The copy in your browser cannot drift from the copy on the command line. This is the strongest layer. The same geometry now runs client-side from geometry.mjs, and test/web-geometry-parity.test.cjs fails if that served module differs by one byte from the CLI source, or if the plate it builds stops matching the published STL. Its output, verbatim, from this run:
ok web-geometry-parity — geometry.mjs is a byte-exact render of stl.cjs + models.cjs,
and the plate it builds is byte-identical to models/esp32/esp32-bench-plate.stl
(4884 bytes, 96 triangles, 120.3 x 63.1 x 5.6 mm)

What this does not tell you

It does not tell you the board's width — the whole point is that you measure it. It does not tell you that any of this fits, because nothing has been printed. It reports no tolerance, no print time observed on a printer, no material result, and no experience from anyone who has used any of it. What it offers is a way to proceed honestly when a number you need is missing: check whether it is really missing or just moved, measure rather than assert, leave the uncertain axis unconstrained, and make the machine re-check the file it just wrote.

The parts and downloads this method produced are on the ESP32-S3 bench parts page, along with every source file quoted above.


← All electronics build-logs