fix: create pcb_ports for url-loaded footprints with duplicated pad numbers - #3435
Open
marcos452652258-gif wants to merge 2 commits into
Open
Conversation
…umbers KiCad footprints loaded via URL/blob (footprintFileParserMap) were added as bare primitives without a Footprint wrapper, and existing ports were never re-rendered after the async load. Components using such footprints ended up with zero pcb_ports, making every pin unroutable. Two changes, mirroring the library-footprint load path: 1. Wrap file-parser footprint components in a Footprint child (with src) so getPortsFromFootprint reads port hints from loaded children. 2. Re-mark PcbPortRender on existing Ports after the load completes. With both, duplicated-numbered physical pads (e.g. the two positive terminals of BatteryHolder_Keystone_3002 sharing pad number 1) resolve into a primary port plus internally-connected pin1_internal_N ports with their own pcb_ports, matching the library-ref behavior. Adds a regression test using the real KiCad 10 battery holder footprint. Fixes tscircuit/tscircuit#4444
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
When a footprint loads asynchronously (URL/blob via footprintFileParserMap), source traces could keep referencing port ids from before the load recreated the ports, and SourceDesignRuleChecks never re-ran. Ports that were actually connected by a trace kept stale source_pin_missing_trace_warning entries. - Re-mark SourceTraceRender on subcircuit traces after the file-parser footprint load so traces resolve against live port ids - Add updateSourceDesignRuleChecks to NormalComponent so the marked phase actually re-runs; the check now clears its own previous warnings first, making re-runs idempotent Fixes tscircuit/tscircuit#4442
Author
|
Added a second commit fixing the related stale-warning issue #4442 (same async-load root): after the file-parser footprint load, subcircuit traces re-resolve against the live port ids and |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
KiCad footprints loaded through
footprintFileParserMap(URL/blob/static asset) were added as bare primitives without aFootprintwrapper, and existing ports were never re-marked for re-render after the async load finished. Components using such footprints ended up with zeropcb_portelements, making every pin unroutable.Repro before this patch (
kicad:Battery/BatteryHolder_Keystone_3002_1x2032, converted withKicadFootprintToCircuitJsonConverter): 3pcb_smtpad, 2source_port, 0pcb_port.Root cause
The library-footprint load path (
loadFootprintLibraryResultOrThrow) wraps loaded components in aFootprint({ src })child and re-marks"PcbPortRender"on existing ports after adding them. The file-parser path did neither:getPortsFromFootprint()can never read port hints from loaded children once available.PcbPortRender, ports whose initial render happened before the async load kept zero PCB matches andPort_doInitialPcbPortRenderbails out early (matchedComponents.length === 0), so nopcb_portis ever inserted.Additionally, footprints like the Keystone 3002 battery holder have two physical positive pads sharing KiCad pad number
1. The library path already handles this via connected-cluster analysis producing a primary port pluspin1_internal_Nports — the URL path now gets the same treatment.Changes
NormalComponent_doInitialPcbFootprintStringRender.ts: wrap file-parser footprint components in aFootprint({ src })wrapper (same as the library path) and re-markPcbPortRenderon existing ports after the async load.Verification
After the patch: 3
source_port, 3pcb_port(POS + pin1_internal + NEG), internal connection recorded, and<trace from=".BT1 > .POS" to=".BT1 > .NEG" />routes successfully.Fixes tscircuit/tscircuit#4444