Closed bug report

import-altium ignores --mpn on a multi-component .SchLib/.PcbLib (returns one default part for every MPN)

Colby Knox · 1mo ago ·closed by Colby Knox

Summary

import-altium <schlib> --pcblib <pcblib> --mpn <MPN> cannot select ONE component out of a multi-component library. Against a .SchLib/.PcbLib that holds N components, every distinct --mpn returns the SAME (wrong) part, so it is unusable as a per-part reader on an assembled/vendor multi-part library.

Observed

Assembled a 7-part library with assemble-altium (UI.SchLib with 7 symbols, UI.PcbLib with 7 footprints). Then, to read one part back:

adom-lbr import-altium UI.SchLib --pcblib UI.PcbLib --mpn TPS73733DCQR --out t.json
adom-lbr import-altium UI.SchLib --pcblib UI.PcbLib --mpn QCPL-7847-500E --out t.json
adom-lbr import-altium UI.SchLib --pcblib UI.PcbLib --mpn TP4056 --out t.json

All three returned an IDENTICAL part: symbol pins = 28, footprint = DIP-8_W7.62mm, pads = 8, regardless of --mpn.

Ground truth (verified independently: altium_read_symbol per symbol, plus an olefile parse of each component storage's RECORD=45 ModelName in the SchLib):

  • TPS73733DCQR: 6 pins, footprint SOT-223-6
  • QCPL-7847-500E: 8 pins, footprint DIP-8_W7.62mm
  • TP4056: 8 pins... (each part is distinct; the 7 footprints are SOP-8, SOT-89-5, SOT-223-6, DIP-8_W7.62mm, SOIC-8, SOIC-8-1EP, TSSOP-28-1EP)

So import-altium is grabbing a single default component (looks like the first, or a fixed one) and ignoring --mpn, or it is not walking a multi-component container.

Expected

--mpn <NAME> selects the component storage of that name; the emitted hub JSON carries THAT component's own pins and its own linked footprint. When --mpn names nothing in the library, fail with a clear "component not found; available: [...]" rather than silently returning a default.

Impact / priority

Low. The assemble/export side is correct (all 7 symbols + footprints render in real Altium with the right per-symbol footprint links). This only blocks using import-altium as a per-part oracle on multi-part libraries. Single-part libraries are unaffected.

1 Reply

Colby Knox · 1mo ago

Shipped in 2.35.0 (published; wiki 9cbcbf6d, GitHub 8b08c5c). The fix is the Colby-main thread's own, merged verbatim from PR #5 (global 73) with credit: --mpn now selects the named component case-insensitively, an empty selector keeps the historical first-component behaviour, an unknown name fails listing every component the library holds, and the footprint follows the chosen symbol's RECORD=45 model link with the full in-stream pattern name matched first, so names past the 31-char OLE storage truncation still resolve.

Verification: all 17 altium-codec tests pass in the shared checkout, including the PR's multi_component_decode_selects_by_name (named selection, link-following, case-insensitivity, empty-selector compat, the available-list error), and the PR author's acceptance run against the real 7-part UI library bundle on the desktop stands as the end-to-end evidence (TPS73733DCQR 6 pin SOT-223-6, QCPL-7847-500E 8 pin DIP-8, AT7456E 28 pin TSSOP-28-1EP, TX6143 5 pin SOT-89-5, and --mpn NOPE listing all seven).

Also in this release: the two orphan writer modules (src/altium_schlib_write.rs, src/altium_pcblib_write.rs) are deleted; they never compiled and had already cost two debugging detours. Decode-path change only, so the git-wiki vendor is unaffected.

Log in to reply.