lab-hardware-cad skill

Lab Hardware CAD

Design physical research hardware as parametric Python source, export STEP as the authoritative artifact, and verify the result both numerically and visually before anything is fabricated.

The hard part of lab hardware is almost never the geometry. It is that the part must mate with equipment whose dimensions are fixed by a published standard or a vendor drawing. A holder that is 0.5 mm too wide does not fit the plate reader; a channel with the wrong aspect ratio collapses during bonding; a mount whose bolt pattern is 25.4 mm instead of 25.0 mm will not reach the optical table. This skill exists to keep those numbers correct and checked.

When to use

Use for any request to design, model, or fabricate a physical part for a lab: chip, mold, mount, adapter, holder, rack, bracket, enclosure, jig, fixture, arena, or maze. Also use to inspect or modify an existing STEP file.

Do not use for finite-element analysis, computational fluid dynamics, molecular structure, or scientific plotting. Those are different skills.

Setup

uv venv --python 3.12 .venv-labcad
uv pip install --python .venv-labcad/bin/python "build123d==0.11.1" "matplotlib>=3.8"

build123d 0.11.1 requires Python >=3.10,<3.15 and pulls in the OpenCascade kernel through cadquery-ocp-novtk. The wheel is large; install once per project and reuse it.

All bundled scripts take --help. check.py standards runs without build123d installed.

Model files are executed, not parsed. gen.py, check.py, and snapshot.py import a *_model.py and call its build(), which runs arbitrary Python in the current environment. That is inherent to parametric CAD — the source is the design. Only run model files authored in this session or supplied by the user from a trusted location. If a model came from the internet, a shared drive, or an untrusted colleague, read it before running it and say that you did.

Required workflow

Follow these steps in order. Steps 5 and 6 are not optional, and step 6 is not waived by step 5 passing.

1. Route to a device family

Read the request, classify it, and load exactly one family reference. Do not load all four — they are long, and mixing conventions between families is a common source of error.

If the part genuinely spans two families — a microfluidic chip that bolts to an optical table — load the family that owns the critical interface, then read only the interface section of the second. State in your response which family you routed to.

2. Establish the interface dimensions before any geometry

Every part has at least one mating interface. Before writing code, write down for each interface:

• the source of the dimension: a published standard, a vendor drawing, or a user measurement;
• the nominal value and tolerance;
• the clearance or interference you intend, and why.

Look the number up in assets/standards.json or the family reference. Never write an interface dimension from memory. If the number is not in the standards file or the reference, ask the user for the vendor drawing or the measurement rather than guessing. A guessed interface dimension is the single most expensive failure mode in this skill.

A feature that must receive a standardised component is sized against that component's maximum material condition — nominal plus its plus-tolerance — and only then given clearance. Sized from nominal instead, it fits only the smaller half of conforming parts.

python scripts/check.py standards --list
python scripts/check.py standards --show slas-microplate-footprint

The bundled standard IDs (exact strings; do not guess variants): slas-microplate-footprint, slas-microplate-height, slas-microplate-flange, slas-well-positions-96, slas-well-positions-384, slas-well-positions-1536, cuvette-standard-10mm, optical-breadboard-metric, optical-breadboard-imperial, cage-system-30mm, sm1-lens-tube-thread.

If the part mates with nothing in this list, that is common and fine: declare no interfaces, and name every interface dimension with its source (user spec, vendor drawing, measurement) as unchecked in the report. Never declare against an unrelated standard to fill the gap — a fabricated declaration is worse than an honest "nobody checked this".

3. Choose the process before choosing the geometry

Read references/fabrication-limits.md. Process determines minimum wall, minimum feature, achievable tolerance, and whether the part survives autoclaving or contact with your solvent. FDM cannot hold ±0.05 mm; SLA resin is generally not safe for cell contact without post-cure and testing. Record the process and material in the model docstring.

4. Author a parametric model

Write model.py. The source is the authoritative artifact — never hand-edit an exported STEP file**, and never regenerate from a mesh.

Requirements:

name: boredmm, walltmm, posthmm. No bare numbers in the body except 0, 1, and 2.

• Every dimension that a user might change is a module-level named constant with units in the

standard ID) and a DESIGN block (dimensions you are free to choose).

• Expose build() -> Part. gen.py calls it.
• Group parameters into an INTERFACE block (dimensions fixed by a standard, annotated with the

overrides actually reach it.

• Derive every computed dimension inside a function, never at module level, so --param

standard ID and intent. This is what makes the interface machine-checkable in step 5. intent is "envelope" when the feature must accept any conforming part (a pocket, bore, or slot — checked one-sided at maximum material condition plus your clearance) and "match" when this part must itself conform (symmetric band). clearance is the total intended clearance in mm and must be non-negative. Declare only dimensions that constrain this part's mating features — a property of the mating equipment (a table's edge border, a typical plate thickness) is not an interface of yours. If no bundled standard applies, return [].

• Declare an interfaces() function returning the dimensions the part must fit, each with its

region for everything that must pass through or fit in (screw shafts, beam corridors, the mating part at maximum material condition dropping into its pocket), a material region for everything that must remain (a ridge, a ledge, a screw seat), and a bbox bound for every size limit the user stated. Map every geometric requirement in the request to one entry; these catch the errors that isvalid, the bounding box, and declared numbers cannot see. gen.py runs them on every generation and fails the build when one fails. Schema and worked examples: references/build123d-patterns.md.

• Declare a checks() function of go/no-go gauges measured from the built solid: a clear

• Put the process, material, and every interface source in the module docstring.

"""SLAS microplate carrier for a custom stage insert.

Process: FDM, PETG, 0.2 mm layer.  Tolerance budget +/-0.3 mm.
Interfaces:
  - Plate pocket: ANSI/SLAS 1-2004 (R2012) footprint 127.76 x 85.48 mm, +/-0.25.
  - Stage bolts: user-measured, 40.0 mm centres (drawing in docs/stage.pdf).
"""
from build123d import *

# --- INTERFACE (fixed by standard; do not tune) ---
plate_l_mm = 127.76   # ANSI/SLAS 1-2004 nominal
plate_w_mm = 85.48    # ANSI/SLAS 1-2004 nominal
plate_tol_mm = 0.25   # ANSI/SLAS 1-2004; the pocket is sized to nominal + this
# --- DESIGN (free) ---
pocket_clearance_mm = 0.40   # per-side; FDM, see fabrication-limits.md
wall_t_mm = 3.0
floor_t_mm = 2.5
body_h_mm = 12.0


def pocket_mm() -> tuple[float, float]:
    """Pocket at the plate's maximum material condition plus clearance per side.

    A pocket sized from nominal jams on roughly half of conforming plates.
    """
    growth = plate_tol_mm + 2 * pocket_clearance_mm
    return plate_l_mm + growth, plate_w_mm + growth


def interfaces() -> list[dict]:
    """What this part must fit. `check.py interfaces` verifies every entry."""
    pocket_l, pocket_w = pocket_mm()
    return [
        {"feature": "plate pocke

See references/build123d-patterns.md for the builder-vs-algebra choice, the interfaces() contract, sketching, selectors, fillets, and threaded-insert bores.

5. Generate and run the checks

python scripts/gen.py carrier_model.py --outdir out/
python scripts/check.py facts out/carrier.step
python scripts/check.py interfaces out/carrier.manifest.json
python scripts/check.py geometry out/carrier.step --model carrier_model.py

gen.py also evaluates the model's checks() gauges against the solid it just built, prints each PASS/FAIL, records them in the manifest, and exits non-zero on a failure — so a part that violates its own declared geometry never silently becomes an artifact. check.py geometry re-runs the same gauges against the exported STEP, which is the authoritative artifact.

out/ is a scratch convention, not a requirement. When the user asked for deliverables in a specific place, generate there (--outdir .) or copy the STEP, manifest, and DXF to it before finishing — a deliverable that exists only inside out/ has not been delivered.

gen.py writes carrier.step (authoritative), carrier.stl (mesh preview and printing), and carrier.manifest.json recording the source hash, resolved parameters, declared interfaces, library versions, and measured bounding box, volume, and validity. The manifest is the provenance record — keep it with the artifact.

check.py facts reports isvalid, bounding box, volume, surface area, centre of mass, and solid count. A part that reports isvalid: false is broken geometry; fix the source before going further.

check.py interfaces evaluates every entry the model declared against the standards database and exits non-zero on failure. Be clear about what it does and does not verify: it checks the declared numbers — catching a transcribed dimension, the wrong standard, and nominal-instead-of-MMC sizing — but it never measures the built geometry, and a value computed from the same constants it is checked against passes with zero headroom by construction. Do not cite it as evidence the geometry is right; facts and the snapshot are the geometry checks. An empty declaration list passes: a part that mates with nothing in the bundled database has nothing to declare, and its interface dimensions are instead named as unchecked in the report.

Use interfaces rather than check.py fit for anything internal — a pocket, bore, or slot does not appear in the part's outer bounding box, which is what fit measures. Reach for fit only to check one number by hand (--value footprint_length=128.81), or when the part's own outline is the interface, such as a gasket cut to a plate footprint.

For assemblies, check that parts do not interfere:

python scripts/check.py clearance out/carrier.step out/lid.step --min 0.3

6. Snapshot and actually look at it

python scripts/snapshot.py out/carrier.step --out out/carrier.png

Then read the PNG. This step is mandatory after every generation and every modification. Deterministic checks passing is not a reason to skip it: is_valid and a correct bounding box are both fully consistent with a pocket cut on the wrong face, a boss placed outside the body, or a fillet that ate a feature. Those errors are obvious in a picture and invisible in the numbers.

Know the render's limits too. A feature much smaller than the frame — a 0.3 mm mold ridge on a 40 mm part, a counterbore step on a plate — may not be decidable from the views at all. Do not report seeing something the image cannot resolve; that is worse than not looking. For such features the skill has instruments: check.py bores prints every cylindrical face (diameter, axis, position, span, sweep) so you can reconcile the drilling against the model's intent, and check.py probe answers a one-off "is this region clear / is material present here" without editing the model. Cite the measured numbers; report from the picture only what the picture actually shows.

The six views are true orthographic projections, and the outlines are the model's real edges drawn without hidden-line removal. So a circle visible "through" material is a bore on the far side, not a window — the part is not transparent. Read it that way rather than reporting a hole that is not there.

State in your response what you saw in the snapshot, not merely that you generated one.

7. Repair through the source

If any check fails, edit the parameters or the model code, rerun gen.py, and rerun both step 5 and step 6. Never patch the STEP.