kicad-developers team mailing list archive

[Kevin Bortis <kevin@xxxxxxxxx>]

Hi Kaspar

On Tue, Dec 20, 2016 at 11:50 PM, Kaspar Emanuel <kaspar.bumke@xxxxxxxxx> wrote:
> 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 and on the
> standard library GitHub issues.
>
> 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 currently work on a prototype for a slim PDM system for KiCAD. [1]
As described, I don't find it a good solution to embedded the MPN in
schematic symbols. It could be OK for highly specialized IC symbols
like an SoC, that no other manufacturer produces, but for resistors,
transistors etc. it is higly toxic. In my view, you don't need a
separate symbol for each resistor. The symbol for a resistor need only
to exist exactly once. If you have to change the symbol for any
reason, you only do your work once and propagate the change to all
resistors in a design by simply updating them in a batch. If you embed
MPN information in the symbol, you have to copy that symbol for every
value you use. Managing libraries will be a nightmare. What you really
need for BOM management is an additional abstraction. You have to
place a component, which is defined at least of one symbol, one
footprint and metadata like the value or description.

Component
  |
  | - Symbol
  | - Footprint
  |      |
  |      | - 3D Model
  | - Other Data like link to Datasheets

> 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:
>
> An MPN is really a manufacturer and part number tied together. A
> manufacturer may use the same part numbers as another.
> 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 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.

To create a small and effective library that is easy to manage, the
ideal workflow could be something like the following:

1. Create resistor symbol
2. Create footprint for e.g. size 0402 (1608M)
3.1 Create component in your library tool for 1k 1% 100ppm
3.2 Assign resistor symbol
3.3 Assign footprint
3.4 Assign Manufacturer and Orderable Part Number

You now have the ability to create a second resistor using the same
symbol and same footprint. So you have cleanly separated the abstract
symbol from the orderable part.

Some might be worry that this is to complicated to implement and that
the current way of doing things might be affected, but it is easy to
implement without modify to much in KiCad.

The only thing that we really need in the file format of symbols,
schematics, footprints etc. is an **UNIQUE ID** that is assigned to
the symbol by the used library manager when placing the component to
the schematic. This ID should be a parameter which is completely
optional. Once the KiCad code have better support for plugins, anyone
could implement their own library manager besides the standard one
which is ERP, PDM, DB or whatever aware.

You can then easily create an external bom manager which uses this
unique ID to assign MPN, second source components, obsolescence
management, lifecycle management etc. etc. So please don't bloat the
file format to much, only provide the necessary features that plugins,
external tools can manage MPN and other information.

  [1] https://lists.launchpad.net/kicad-developers/msg26913.html

Regards Kevin

>
> 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.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>