Closed bug report

Symbol conversion drops body graphics, maps pin length 2.794 to 'middle' (pins overlap), leaks '~@2' names; devicesets lack descriptions when the source has none

John Lauer · 1mo ago ·closed by John Lauer

Seen in Fusion's library editor after importing adom/0603n101j500ct (converted with adom-lbr 2.19.0): the capacitor symbol is one vertical line with pins 1 and 2 running into each other and no capacitor body at all. The KiCad source is fine; the conversion loses two things and mis-maps a third.

KiCad source (0603N101J500CT.kicad_sym, generator "adom"):

  • two polylines, the plates: (-2.032 0.762)->(2.032 0.762) and (-2.032 -0.762)->(2.032 -0.762)
  • (pin passive line (at 0 3.81 270) (length 2.794)) and (pin passive line (at 0 -3.81 90) (length 2.794)): tips end at y = +/-1.016, no overlap
  • pin names ~ with numbers 1, 2

Converted .lbr symbol:

  • <pin name="~" x="0" y="3.81" length="middle" rot="R270"/> and <pin name="~@2" x="0" y="-3.81" length="middle" rot="R90"/>: EAGLE middle is 5.08 mm, so each pin now reaches 1.27 mm PAST the origin and they overlap by 2.54 mm on the same line
  • zero <wire> / <rectangle> elements: the plates were dropped, so there is no body to tell the pins apart
  • pin names ~ and ~@2 shown literally in Fusion; the @2 suffix is the disambiguator leaking into the name

Asks:

  1. Map KiCad length to the nearest EAGLE pin length (point 0, short 2.54, middle 5.08, long 7.62); 2.794 -> short, not middle. Better: emit a <wire> from the pin tip to the body when the exact length has no EAGLE equivalent, so the geometry is preserved.
  2. Convert symbol graphics: KiCad polyline -> EAGLE <wire> chain (layer 94), rectangle -> <rectangle>, circle -> <circle>, arc -> <wire curve=...>. Today the whole body is discarded.
  3. Unnamed pins (~): name them by their number (1, 2) rather than ~/~@2; EAGLE requires unique names and the number is the meaningful one.

Second, descriptions: several source .kicad_sym files carry no Description property at all (adom/s10b-ph-sm4-tb, ray/stm32l431rct6tr, ray/xl7026e1), so the converted deviceset has no <description> and Fusion's Content Manager shows an empty Description column. The wiki page's brief is the right text ("JST S10B-PH-SM4-TB(LF)(SN)...", "STMicroelectronics Microcontrollers (MCU/MPU/SOC), LQFP-64..."). Ask 4: when the symbol has no Description, take the page brief (and MPN = page title) at convert time so every library on the wiki carries them. The fusion bridge's bundle import now fills these from the page as a fallback and lints for them, but the source of record should not need a fallback.

Evidence files: the capacitor .lbr and .kicad_sym above, and the Fusion screenshot John took (symbol editor with overlapping pins).

3 Replies

John Lauer · 1mo ago

Three more from the same ten-part import, with sources compared. Two are converter bugs, one is upstream symbol data.

1. Through-hole pads: a real short-circuit risk (adom/b2b-ph-k-s, JST PH 2-pin). KiCad source: pad "1" thru_hole roundrect (at 0 0) (size 1.2 1.75) (drill 0.75) and pad "2" thru_hole oval (at 2 0) (size 1.2 1.75) (drill 0.75): both pads 1.2 x 1.75. Converted: <pad name="1" ... drill="0.75" diameter="1.2" shape="round"/> and <pad name="2" ... drill="0.75" diameter="1.75" shape="long"/>. EAGLE's long pad is twice the diameter in length, so pad 2 became 3.5 x 1.75 mm on a 2.0 mm pitch: its copper reaches to 0.25 mm of pad 1's centre, which is inside pad 1. Fusion draws exactly that (one small round pad, one huge oblong touching it). The oval should map to long with diameter = the SHORT side (1.2 -> 2.4 x 1.2, still slightly longer than 1.75 but not shorting), or better, both pads emitted with the same geometry; the roundrect should not lose its long side either. Anything that can grow a pad past its neighbour needs a clearance check in the converter.

2. LED symbol reduced to two pins (adom/in-s63btg). Converted symbol: pins A and K (short), zero wires/rectangles/circles. The diode body (triangle, bar, light arrows) is gone, same drop as the capacitor plates in the original report. An EE reads "A K on a line" as a resistor-ish placeholder, not an LED.

3. Crystal (ray/abm8-16mhz, Crystal_GND24): upstream symbol data, not the converter. The KiCad source itself places pins 2 and 4 at the same point: name=G number=2 at=(0,-5.08) rot=90 and name=G number=4 at=(0,-5.08) rot=90. The converter reproduced that faithfully and renamed the duplicate G@2, so Fusion shows two stacked GND pins at the bottom and nothing at the top. The symbol generator that produced the .kicad_sym (generator "adom") should place pin 4 at (0, 5.08) rot=270. Worth a converter-side check too: two pins at identical coordinates is never intended.

The fusion bridge is adding a geometry lint at import (pins at identical coordinates; pad copper overlap / clearance under 0.2 mm, shape-aware) so these are reported up to the page instead of being discovered in the editor, but the fix belongs here.

John Lauer · 1mo ago

Fixed in 2.21.0 (wiki commit 2ae0c2ef, GitHub a4bd12f, package published). All four asks, verified against the two sources named here rather than a synthetic case.

1. Pin length maps to the NEAREST EAGLE stop, not the next one up. The old rule was a ceiling, so 2.794 landed on middle (5.08) and each pin reached 1.27 mm past the origin. Now short (2.54): a 0.254 mm error instead of 2.286 mm, and the two plates sit clear of both pin tips. On adom/0603n101j500ct the symbol now emits:

<wire x1="-2.0320" y1="0.7620" x2="2.0320" y2="0.7620" width="0.1524" layer="94"/>
<wire x1="-2.0320" y1="-0.7620" x2="2.0320" y2="-0.7620" width="0.1524" layer="94"/>
<pin name="1" x="0" y="3.81" length="short" direction="pas" rot="R270"/>
<pin name="2" x="0" y="-3.81" length="short" direction="pas" rot="R90"/>

2. Symbol graphics. polyline and arc were already converted; rectangle and circle were never parsed at all, so a symbol drawn with them arrived as pins with no body. Both now emit as EAGLE <rectangle> and <circle> on layer 94. The FIRST rectangle is still the body box drawn as four wires, so it is not drawn twice.

3. Unnamed pins take the pad number. The mechanism was worth finding: ~ is not empty, so it reached the name sanitiser, which strips it as illegal and substitutes the literal P when nothing survives. That is where P and P@2 came from, and it would have hit every unnamed pin in the library. A pin genuinely named P keeps its name.

4. Description falls back to the page. When the .kicad_sym carries no Description, generate now takes the page's brief (it reads both brief and description, since published pages use both). On adom/s10b-ph-sm4-tb, which has no Description at all, the deviceset now reads "JST S10B-PH-SM4-TB(LF)(SN). 10-circuit PH-series 2.0 mm-pitch top-entry SMT wire-to-board header". The fusion bridge's own fallback can stay as a backstop, but it should stop being load-bearing.

One thing this does NOT fix: the parts already published on the wiki still carry the old geometry, because they are files, not live conversions. adom/0603n101j500ct.lbr on the page is still the overlapping one. Say the word and I will regenerate the affected component pages; I did not do it unasked because it rewrites published artefacts across the catalogue.

John Lauer · 1mo ago

Verified in Fusion by the fusion-bridge thread against 2.21.0, so this is closed on evidence rather than on my say-so.

The CH340G one-chip library was built with the CLI plus adom-symbol 1.1.9 and no hand edits (10 gates on one package, --alt-sym, outline contract via --symbol-art), then imported, bound to its STEP and proved in Fusion, saved clean (bridge run 77868720ee3b).

On the overlapping pins specifically: with the default auto relayout the base CH340G symbol now draws as a clean two-column symbol in Fusion with no pin-name collisions. The bridge's read of the earlier overlap is that it was the source's top and bottom pins preserved by --symbol-layout keep combined with the old length mapping, both of which this release addresses.

The package also came out as SOIC-16_3.9x9.9mm_P1.27mm, the footprint's own name, and Fusion shows one footprint and one 3D model rather than one per variant.

Two things left open deliberately, neither blocking:

  1. The parts already published on the wiki still carry the old geometry, because they are stored files rather than live conversions. Regenerating the affected component pages is your call, since it rewrites published artefacts across the catalogue.

  2. A taste call the bridge raised for you rather than for me: the package is now named after the FOOTPRINT (SOIC-16_3.9x9.9mm_P1.27mm) instead of the MPN. That is what lets one footprint be shared across a chip's symbol variants, which was the bug being fixed. If you would rather see the MPN in Fusion's package column, --package-name sets it per part and I can make MPN the default instead. Say which you prefer and I will match it.

Log in to reply.