kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

Hello, Kaspar!

I am not happy at all with embedding information in pre-defined (hardcoded) fields/attributes/labels. Simply because I think there is simply no standard way to do that.

Here, we keep all non-mandatory or volatile information of the components outside of the schematics in a separate database (MariaDB).
The only thing we need to sync in between the different worlds (schematics, layout, database, order department, ...) is currently a
PartName plus some UniqueID (which is an index or a version of a PartName) in the schematics. Other fields/attributes are mapped on demand from the database into the schematics. The reason for that is that we stay extremely flexible.

This way we can work with our own PartNames as we wish, add values, tolerances, sizes, geometric information, step models, datasheets, manufacturers, distributors, links, prices, stock information, assembly information, ... you name it, from the database into our schematics. We can even map our PartNames to the names of our customers if they wish to use their own system to manage the assembly.

It is off course desirable to have a way to save generic attributes in the schematics (as properties).
But they don't need to be (or must not) pre-defined as "Manufacturer" or "MPN" or similar.
I don't see a reason to encode a manufacturer name into the schematics at all. Their names change quite requently nowadays.

For example: Sometimes, we can ask the assembly house to use their "standard" resistors for i.e. a 1k 1005M (0402) 1% thin film and they tells us afterwards which they soldered on our boards. For a pull-up resistor to enable a DC/DC, we don't need to care about a manufacturer at all, as long as it's within the specification. But in some special cases - i.e. some high voltage safety-fuse-circuit-magic, we want to have exactly one type of i.e. fusable resistor from this exactly one manufacturer because only that is specified and approved to to some mandatory safety-standards. But the manufacturer is still not hardcoded in the schematics... we just have a resistor with a special UniqueID (index) which is locked in this project, this Partname+UniqueID maps to exactly this one type of component from one manufacturer in the database.
We can add an exclamation mark (!) to the schematics as a minimum or make just more properties visible to tell the reader that there is something very special with this resistor.

Otherwise, the is example looks quite simple in the schematics: 
Partname  (UniqueID)
R-1005M-102 (ID=0) is some 1k Resistor in 1005M housing (0402), usually Tol=+-1%, Ptot>0.05W, but manufacturer, if you ask you can even use a Tol=+-5% to save money...
R-1005M-102-F4 (ID=F4) is a special 1k Resistor in 1005M housing (0402) with Tol=+-1%, TK=+-50ppm, Ptot=0.0625W, Mfg=KOA, MfgNo=12345XYZ, ...


Regards,

Clemens

On 2016-12-20 23:50, Kaspar Emanuel 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 <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 <http://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
>