update_footprints_from_library sends front-side pads on an inner layer the board lacks

Open
  • Is something wrong?
#103 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
backend

Research direction

Start with build_updated_instance and the CopperStack check it applies to back-side footprints, then compare the front-side path that copies library pad layers unchecked. The issue also names place_component and update_pcb_from_schematic as likely sharing the gap, so look there too. Done means an In<k>.Cu layer missing from the board's stack is refused on both sides with the same diagnostic, with a test covering the 4-layer case.

Written by the indexing model from the issue text.

Description

bug

Imported from mixelpixx/Konnect#863, opened by pauliuszaleckas on 2026-10-09. The original repository is archived.

Problem

update_footprints_from_library checks inner copper against the board's stack only when it mirrors a back-side footprint. A front-side refresh copies the library's pad and graphic layers as they are. A library footprint with pads on In5.Cu, refreshed onto an F.Cu footprint on a 4-layer board, is sent to KiCad with pads on a layer the board does not have, and the plan reports success.

KiCad keeps such pads: a board saved after SetCopperLayerCount(4) still writes (layers "In5.Cu") (see inner_layer_flip_missing.kicad_pcb in the mixelpixx/Konnect#831 PR). The pad then has no copper anywhere on the board, with no warning.

Reproduction (unit level, on the mixelpixx/Konnect#831 branch)

build_updated_instance(&current_instance(BlFCu), &library, CopperStack::new(4).unwrap(), …) with a library footprint whose pads are on In5.Cu returns Ok, and the prepared pads carry BL_In5_Cu. The same call with BlBCu refuses with layer 'In5.Cu' is not on this 4-copper-layer board.

Expected

Either side refuses an In<k>.Cu the board's stack does not have, with the same diagnostic. place_component and update_pcb_from_schematic probably share the gap and are worth checking at the same time.

Found while working on mixelpixx/Konnect#831, and kept out of its scope.

Dominant language
Rust
Stars
34
Forks
9
Avg merge
9h 26m
Merged PRs (30d)
226

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Copperpour/Copperpour

All issues in Copperpour/Copperpour

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.