Test out PCBSchemaGen with the powder-doser project

[Copilot]

Exercises the PCBSchemaGen flow against an external design — the single-Pico-W powder-doser bench rig from vertical-cloud-lab/powder-doser PR #61 (head 147e505) — mirroring the reproduction work in PR #2. First brings in all commits from PR #2 (the netlistsvg dependency fix + Task 1/17 artifacts).

Changes

• Merged PR Document required netlistsvg dependency; commit reproduction artifacts for paper examples #2 branch (copilot/attempt-simple-test-run) — netlistsvg dependency docs/.gitignore fix and the Task 1 / Task 17 reproduction artifacts.
• reproduction/powder_doser_test_module/ — new external reproduction:
  • powder_doser_test_module.py — ground-truth SKiDL transcription of PR #61's pin/net table (20 nets), rendered to .net/.svg/.png with a 0-error ERC report.
  • run_powder_doser.py — replicates task/run.py's feedback loop (LLM → extract SKiDL → syntax/ERC check → netlist+SVG render → retry with the error fed back) for this board.
  • powder_doser_llm_skidl.py, powder_doser_llm.{net,svg,png,erc}, powder_doser_llm_stats.json, task_output.txt — actual loop output: claude-sonnet-4-6 produced an ERC-clean schematic on attempt 3, net-for-net identical to the ground truth.
  • README.md — provenance and reproduction commands.
• reproduction/README.md — index updated with the powder-doser entry.

Note on parts modeling

The bench-rig breakouts (Pico W, DRV2605L, DRV8871, Pololu Tic T500, servo, solenoid, ERM, D24V22F5, shunt regulator) are not in PCBSchemaGen's power-electronics test library, so they're defined inline via SKiDL's SKIDL tool rather than Part("test", ...):

def make(name, ref, pins, footprint="Package_TO_SOT_SMD:SOT-23"):
    t = Part(tool=SKIDL, name=name, ref_prefix=ref[0], dest=TEMPLATE, footprint=footprint)
    for num, pname, func in pins:
        t += Pin(num=num, name=pname, func=func)
    return t(ref=ref)

No production code changed; artifacts are generated outputs. The API key is read from the environment and never written to any committed file.

CELUS suitability evaluation + re-prompt

Adds an evaluation (per the PR thread) of how usable the generated files are as input to a component-driven board-synthesis tool such as CELUS, and demonstrates that the gaps are promptable.

• reproduction/powder_doser_test_module/CELUS_EVALUATION.md — documents how CELUS builds a board (block diagram of functional blocks → real parts captured as "CUBOs"), maps CELUS's board-creation requirements against what the run provides in an 11-row matrix, and scores the first run (2 fully met, 4 partial/implicit, 4 missing — real footprints, MPN, manufacturer, datasheet — 1 out of scope). Lists each unfulfilled requirement, what would need to change, and the solutions found (with caveats).
• reproduction/powder_doser_test_module/celus_reprompt/ — an executed re-prompt:
  • run_powder_doser_celus.py — the same feedback loop with the prompt extended to require MPN/Manufacturer/Datasheet/Block fields and a real footprint on every component, a readiness gate (reject-and-retry on any missing field), and deterministic BOM + block-diagram derivation from the netlist.
  • powder_doser_celus_skidl.py, powder_doser_celus.{net,svg,png,erc}, powder_doser_celus_bom.csv, powder_doser_celus_blocks.json (8 blocks + 20 typed interfaces), powder_doser_celus_stats.json, task_output.txt — loop output: claude-sonnet-4-6 passed on attempt 1, net-for-net identical to the first run with 0 ERC errors, raising coverage to 10/11 requirements (only mechanical/form-factor remains, outside PCBSchemaGen's electrical scope).
  • README.md — artifact index, reproduction command, and caveats.
• The directory and reproduction/README.md indexes link to the evaluation. SKiDL part fields (MPN/Manufacturer/Datasheet/Block) are written into the KiCad netlist, so the added metadata flows into the BOM with no change to connectivity.

Datasheet verification

Per the PR thread, the sourcing metadata (MPN / Manufacturer / Datasheet) on every component has now been verified against the powder-doser project itself and the manufacturers' material, replacing the model-supplied values that were unverified, wrong, or pointed at dead/fabricated URLs.

• The decisive source was already in the project: powder-doser PR #25 mirrors vendor datasheets under hardware/vendor-files/<part>/ (with per-part SOURCES.txt/SPECS.md), and the PR #61 BOM in hardware/test-module/README.md pins each part's identity. Each value was cross-checked against the manufacturer's own page (and the TI chip datasheets for the drivers) and every link confirmed reachable.
• Corrections applied (in powder_doser_celus_skidl.py + powder_doser_celus.net): servo Hitec → Power HD (Adafruit #1142), solenoid Zonhen → Adafruit #412, ERM Generic → Adafruit #1201, stepper Generic → StepperOnline 11HS18-0674S, barrel jack dead CUI PDF → Adafruit #373, and the dead Nichicon UVR datasheet URL → the live one.
• powder_doser_celus_bom.csv was re-derived from the corrected netlist (readiness gate passes, 14/14 components complete; connectivity, block diagram, and ERC are unchanged — still 0 errors).
• reproduction/powder_doser_test_module/celus_reprompt/DATASHEET_VERIFICATION.md — new file with the per-part verified datasheet/source table, the corrections made, and the remaining caveats (live distributor stock/price still to confirm; bulk caps are generic-by-spec; breakout footprints are pin-count generics; Tic T500 #3134 vs #3135 is the same controller). CELUS_EVALUATION.md (R8 now verified) and celus_reprompt/README.md caveats were updated accordingly.

[sgbaird]

@lbwinters could you have a look at the files generated here?

[lbwinters]

@sgbaird To me the files generated by PCBSchemaGen seem much more complete than the ones generated by LaMAGIC. Looking through I noticed a more complete logic diagram as well as thorough lists of component specifications, which will be needed in the next step using a tool like Celus to create the initial board design. Can we query copilot to evaluate the effectiveness of the SchemaGen files in providing the necessary information for a tool like celus?

Something like:

@copilot In the scope of our project guidelines of creating a PCB for the powder doser using only automated tools, evaluate the usefulness of the files generated by SchemaGen to be imported into a tool such as Celus. Evaluate the file and complexity requirements necessary to create a board in Celus and figure out how many of those requirements are fulfilled by the schema gen test run. For the requirements that are not filled, list what they are, and what would need to change. Explore if you can reprompt SchemaGen to run in such a way that would fulfill these requirements. Report back with all solutions that you found.

[sgbaird]

Thanks!

@copilot implement Luke's request in #4 (comment)

[Copilot]

@sgbaird To me the files generated by PCBSchemaGen seem much more complete than the ones generated by LaMAGIC. Looking through I noticed a more complete logic diagram as well as thorough lists of comp...

Done in f9f40ba. I evaluated the powder-doser SchemaGen files against CELUS's board-creation requirements and demonstrated a re-prompt that closes the gaps.

Full write-up: reproduction/powder_doser_test_module/CELUS_EVALUATION.md

How CELUS builds a board: it isn't netlist-in/layout-out — you describe the system as a block diagram of functional blocks with typed interfaces, and its engine matches each block to a real orderable part (a "CUBO" = symbol + footprint + BOM metadata). So it needs functional blocks, typed interfaces, pin connectivity, power domains, real footprints, and per-part MPN/manufacturer/datasheet/BOM.

What the first run already gave (the hard part): a complete, ERC-clean, named 20-net connectivity contract with correct power rails and pin types — the electrical intent CELUS can't guess. Score: 2/11 fully met, 4 partial/implicit, 4 missing (footprints, MPN, manufacturer, datasheet), 1 out of scope (mechanical).

The gaps were all promptable. celus_reprompt/ re-runs the same feedback loop with the prompt extended to require, on every component, an MPN/Manufacturer/Datasheet/Block field and a real footprint, plus a readiness gate that rejects-and-retries if any field is missing. On a pass it auto-derives a BOM (.csv) and a functional block diagram (.json: 8 blocks + 20 typed interfaces) straight from the netlist. claude-sonnet-4-6 passed on the first attempt and the design did not drift — net-for-net identical to the first run, still 0 ERC errors, now 10/11 requirements met (only mechanical/form-factor remains, which is outside PCBSchemaGen's electrical scope).

Caveats: the model-supplied MPNs/datasheets are plausible and correctly formatted but not verified against live distributor stock, and breakout footprints are generic pin-headers sized by pin count — both should be confirmed (or matched by CELUS's own catalog) before ordering. CELUS also ingests requirements/CUBOs rather than a raw KiCad .net, so a thin importer (or per-part CUBO import using the BOM/footprint/datasheet) is still a small follow-up.

[lbwinters]

@sgbaird It got close but not quite there! Based on the generated report, copilot can reprompt SchemaGen to get everything it needs except for the actual verifiable data sheets for components. I'm thinking with a rerun though, it can get everything necessary from SchemaGen and then search online databases for the data sheets. Does that sound accurate enough to you, or do you think I need to go in and find those data sheets manually?

If it sounds good to you, here's a potential reprompt:

@copilot These solutions look good. Let's run that reprompt you mentioned in order to check off each of those requirements. For data sheets that cannot be confirmed by SchemaGen, search from within our powder doser project or online databases to find the necessary information to confirm the information. Verify with several sources that those data sheets are for the correct components and contain correct information before finalizing

[sgbaird]

@lbwinters sorry, I missed this. Often times it can't access due to bot prevention. It would be best if you could go download those data sheets and add here manually

We'll give it a try though - I thought I had done this at some point already. If copilot checks every single branch and every PR comment, should be able to find it if it exists here. Also can probably grab some things from online.

@copilot do above

[Copilot]

@lbwinters sorry, I missed this. Often times it can't access due to bot prevention. It would be best if you could go download those data sheets and add here manually

We'll give it a try though - I ...

Done in dacf180. I ran the verification pass against the powder-doser project itself and the manufacturers' material, and confirmed/corrected the datasheet metadata.

The strongest source turned out to be already in the project: powder-doser PR #25 mirrors vendor datasheets under hardware/vendor-files/<part>/ (with per-part SOURCES.txt/SPECS.md), and the PR #61 BOM in hardware/test-module/README.md pins each part's identity. I cross-checked each against the manufacturer's own page (and the TI chip datasheets for the drivers) and confirmed every link resolves.

That exposed several first-run values that were wrong or pointed at dead/fabricated URLs, now fixed:

• Servo (M3): Hitec → Power HD (Adafruit #1142 = Power HD HD-1810MG); the old hitecrcd.com link didn't exist.
• Solenoid (SOL1): Zonhen + fabricated zonhen.com PDF → Adafruit #412 (mechanical/coil datasheets committed in vendor-files).
• ERM (M1): Generic → Adafruit #1201. Stepper (M2): Generic → StepperOnline 11HS18-0674S (full datasheet committed; old link was a wrong-vendor Pololu category page).
• Barrel jack (J1): dead CUI PDF (403 → belfuse.com) → Adafruit #373.
• Bulk caps (C1–C3): dead Nichicon e-uvr.pdf (404) → the live UVR-series datasheet.

Full per-part source table and the remaining caveats are in reproduction/powder_doser_test_module/celus_reprompt/DATASHEET_VERIFICATION.md. The corrected BOM was re-derived from the netlist (readiness gate passes, 14/14 complete; connectivity + block diagram unchanged, ERC still 0 errors).

Three things still need a human/another tool: live distributor stock/price (I confirmed identity + datasheets, not availability); the bulk caps are generic-by-spec (any 100 µF radial electrolytic at the rated voltage — I used representative real Nichicon UVR MPNs); and breakout footprints remain pin-count generics. On the Tic T500, the PR #61 BOM says #3134 while vendor-files uses #3135 — same controller, just connectors-not-soldered vs pre-soldered; I kept #3134 to match PR #61. You mentioned bot-prevention often blocks downloads — I didn't hit that here since the verified PDFs are already committed in your powder-doser repo, so I linked to those + the manufacturer pages rather than re-hosting binaries.