kicad-developers team mailing list archive

[Kaspar Emanuel <kaspar.bumke@xxxxxxxxx>]

Hi all,

there has been a lot of discussion lately about a standard manufacturer
part number (MPN) field in schematic symbols in the user forum
<https://forum.kicad.info/t/default-manufacturers-part-number-field-in-kicad-libraries/4387/55>
and on the standard library GitHub issues
<https://github.com/KiCad/kicad-library/issues/808>.

Most of the discussion revolves around how far this should be taken but in
my reading there have been no real objections, and some very strong support
from creators of external scripting tools, to simply standardize on a field
for MPN in KiCad and not necessarily fill it in.

I understand that the schematic format is currently in flux and it may be
better to achieve feature parity with the old format *first of all* but
nevertheless would propose the addition of a standard MPN field after that.

The two minor gotcha with this:

   1. An MPN is really a manufacturer and part number tied together. A
   manufacturer may use the same part numbers as another.
   2. A schematic symbol can have multiple part numbers tied to it.

I would like to invite discussion on accepting and implementing this
proposal. I have looked over the new s-expression based format spec
<https://lists.launchpad.net/kicad-developers/msg23302.html> but am not at
all familiar with how KiCad will read it and represent it internally.

I know that the current spec for properties is thus:

(property "Manufacturer" "Texas Instruments")

I propose to extend it to allow for lists as properties:

(property "MPN" "Texas Instruments" "NE555")
(property "MPN" "Fairchild" "NE555")

Or, if it is problematic to have properties with the same “MPN” label:

(property "MPN" ("Fairchild" "NE555") ("Texas Instruments" "NE555"))

or

(property "MPN" "Fairchild" "NE555" "Texas Instruments" "NE555")

The exact representation is not hugely important though as long as it takes
into account the two gotchas mentioned above.

It would be grand if the discussion was kept to simply what this is
proposing: *adding a suggested/standard field, that can be left blank, that
will help interoperability in the external tools ecosystem*. No more, no
less.

Cheers,

Kaspar

P.S. Some selected quotes from the kicad.info discussions

devbisme (creator of KiCost and KiField)

I’m not asking for atomic parts (whatever those are) or re-writes of
libraries or anything else. But is there, or can there be, a list of field
names and definitions of what they contain which library creators and tool
builders can follow to minimize incompatibilities?

kuro68k (creator of KiBom)

If a standard emerges for the MPN I’ll support it.

​