I see a lot of confusion here between what is a schematic part. usually a circuit is designed around a specific part, i.e. a Texas NE555 in SO8 package. This part has a very specific set of parameters, and a similar part from another manufacturer, i.e. Fairchild might have some parameters that make it unusable in the current design.
So really a part number is the combination of a component, a physical outline (package) and a manufacturer. So the best way to handle this is to use the full part number and the manufacturer name using two fields “PN" and “MFG”. anything else is just a compromise, and a recipe for disaster in real manufacturing. For hobbyist, I understand that such a strict behaviour might not be warranted, but in my opinion, it is still the best way to handle schematics. Just my $0,02, Jean-Paul N1JPL PS: I have delt with billions of electrical components in the course of my active work life (around 40 years), so I have seen probably all the mistakes that can be made. > On Dec 20, 2016, at 7:37 PM, Clemens Koller <[email protected]> wrote: > > 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 : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
