Default manufacturer's part number field in KiCad libraries


It didn’t belong there in the first place.

Exactly why it doesn’t belong on the schematic.

This implies building and maintaining your own libraries, so what’s stopping you? Why do you need an empty field in the KiCad libraries if you’re going to create your own libraries anyway?


Then where should it go? Kicad doesn’t have an integrated library concept like Altium.

[quote=me]Change the footprint, you change the manufacturer part number,[quote=“1.21Gigawatts, post:41, topic:4387”]
Exactly why it doesn’t belong on the schematic.

The house or manufacturer part number doesn’t need to be printed/visible on the schematic, but it’s vital for BOM generation.

Here is the entire point: when you’re doing a design with hundreds of parts, the notion that you’re going to match generic symbols with footprints in CvPCB is ridiculous. The notion that you can get a BOM out of same is also ridiculous.

So, like I’ve said, every reasonable organization has a company standard library. The parts that are in that library are vetted: symbols, footprints, 3D models are all created and checked. Parts include a house part number that is in a purchasing database which has full manufacturer part numbers and second-source options. Purchasing knows about these parts and knows that they can be bought. Yes, this all work done up front before anyone starts designing anything.

A part placed on the schematic, then, is complete. The intermediate and problem-prone step of matching footprints to symbols in CvPCB goes away. Generating a correct BOM is easy. The BOM has parts reference designators, quantities and house part numbers. That gets imported into the ERP program which matches house part numbers to something that can be ordered, and it’s done. There is no need to look up those vendor part numbers EVERY TIME. Mistakes are avoided.

As I’ve said before: you don’t have to do it that way for trivial designs. But for real designs with a lot of parts, the time savings is significant, and the cost of ordering the wrong parts is avoided. There really is no downside.

I already build my own libraries. What’s needed is a user-definable field in the schematic symbol for my part number. Kicad offers that, I use it, it works.


That’s exactly the point we’re making.

Anybody who needs ‘atomic’/‘complete’ parts runs his own libraries anyway and KiCAD allows that - thankfully. We have no problem really. We’re pretty happy campers. And we definitely wouldn’t want to push such a solution to all other users of KiCAD by demanding the introduction of pre-made fields, as it’s pointless from our POV anyway, as to make them useful they have to be filled in which is only humanly possible with your own libs, this means it’s a custom solution right away.

Everybody else who relies on the KiCAD libs for his (hobby) work is served by the native libs and he can do amazing stuff without investing in library work. Absolutely brilliant.
I could see a sub-group of that to want to fill in a MPN field in the schematic to get the ability to have a BOM for easier ordering, but I can’t see how one would ‘like’ to do that for every design he does, so sooner or later he’ll be part of the custom library group with ‘complete’ parts anyway.
That’s why I said, I have no problem with predefining a MPN field for the native KiCAD libs etc., as long as there are at least 4 customizable fields left - for custom ‘complete’ parts libs.

Currrently everyone is served without discrimination.
Adding a MPN field wouldn’t hurt I think, but it wouldn’t help much either.

PS: @TotalKrill
… there is even the option of offering your modified libraries with the MPN field pre-filled to anyone on this planet by hosting them on github. Nothing is really stopping you.
To put a MPN field into all of them is easily done by script, no magic there.
Putting the right information into them and keeping it up to date is the hard part…


I’m taking an interest in this as the author of the kibom tool.

My goal is to have the BOM generated from the schematic and not have to edit it. That way the BOM doesn’t have to be maintained separately, it is simply exported from the schematic every time it needs updating.

The current system, if it can be called that, has a major flaw that makes it difficult to achieve this goal. The “Value” field is used for both values and part names. For example, a random Atmel microcontroller will have a part value of “ATXMEGA32E5-A”, but a passive might have a value of “15k” or “10u”. When you want to create a table with values and part names, these need to be separated.

I propose the following system for all parts:

Reference = R1, U1 etc. (no change)

Value = Values only. If part is an integrated circuit, for example, value could be 32k if the differentiating/important factor is the amount of flash memory, or 3.3V for a regulator. Diodes could be “Schottky” or “Silicon” etc.

Precision = Precision data for passives, e.g. 1% for resistors, X7R for capacitors

PartNo = Manufacturer’s part number, e.g. XMEGA32E5-AU or PMEG3015EJ.

NoPart = When “true”, indicates nothing is fitted to the pad.

If we can agree on a standard it will make it much easier for people writing BOM plugins and for open source projects to manage people working on their schematics (kinda like programming language style guides). Cleaning up the standard libraries is a fair bit of work but can probably be automated somehow.

One thing we will need to think about is what should be shown by default on the schematic and in footprints. For ICs I’d suggest the PartNo rather than the value in most cases, for example.

Is there a better place to propose this or is this it?


How about redefining “Precision” as “Data” and agreeing to use a CSV structure. You abuse tolerance with dielectric in your example and I would like to see power rating and voltage possible. Making the last character in each element %, V, D, P(package), W and so on perhaps?


Fair point, “data” is a better description.

Perfection is the enemy of progress here. There is no perfect solution, but we can make big improvements anyway.

It strikes me that one thing which might be very useful is a bulk library editor. If parts could be edited in a table it would make normalizing them much quicker. Perhaps there are tools to handle this kind of thing already (XML)?


The nopart is already implemented isnt it? But maybe thats just for PCBNew. I am thinking of the Virtual flag you can set.

Also, I really like the idea of this. Not asking anyone to prefill the entire libraries. Just having default fields there, with a name agreed upon will make external tools much better, or at least easier to write. There already is a field for Datasheet in the symbols by default, I cannot see why we cant have more fields. The libraries can follow in their own pace in my opinion and nobody is forcing the use of theese fields on anyone. They can be safely ignored, not breaking anything backwards.


I wrote KiField to handle things like that.


[quote=“kuro68k, post:44, topic:4387, full:true”]
The current system, if it can be called that, has a major flaw that makes it difficult to achieve this goal. The “Value” field is used for both values and part names. For example, a random Atmel microcontroller will have a part value of “ATXMEGA32E5-A”, but a passive might have a value of “15k” or “10u”. When you want to create a table with values and part names, these need to be separated.[/quote]

Do you really need any more than three columns to identify a given part for purchasing? I only ever use three. My BOM would typically look like this (of course I omitted other columns like quantity, designator, etc. for brevity).

Value | Description | Geometry
100u | 10V tantalum, AVX TPSD107K010R0100 | 7343m
10n | 50V 10% X7R ceramic | 0603
18p | 50V 5% NPO ceramic | 0603

Value | Description | Geometry
ATXMEGA32E5-A | Atmel | TQFP32
MP1542DK | MPS | MSOP8

Value | Description | Geometry
4V7 500mW | zener, MMSZ5230B | SOD123
SS26 | | DO214AA

What engineer or purchasing department/agent would have trouble understanding that?


Im guessing every department/agent would be able to read that. But would a program? Because that would be nice. Then it could show availability directly from maybe Digikey/Mouser or whatever based on tolerances or MPN or whatever.

Try MacroFab part sourcing tool. It is very nice. But if it could get the MPN directly from the schematic or pcb file. It would be even better. Right now it cant. Because everyone defines the part differently, so the tool uses search based on the Value field, which still include a bit of manual searching, unless you put ex. “10k, 0603, 1%, yageo” in every value field. But then you have focused on the implementation that MacroFab uses.

Having more fields instead of less would make it easier to generate automated tools for the part sourcing. Have you every used Altium, they have direct integration for DigiKey etc.

I can always manually add fields, and do not want to lose that feature. But the thing is, if add my fields, someone else will use other fields and the tools handling the sourcing or BOM or whatever will not use any of them, since there is no defined standard. It doesnt have to be perfect, but from the current system of adding fields on an induvidual basis there is room for improvement. I dont see why or how extra default optional fields will damage anyones workflow.


Excellent, I will give it a try. Thanks.


Um… So, where exactly does the 100u part go on the board, and how many of them do you need?

The other problem is what do you display on the schematic? It would make sense to display the value, 100u, but you would likely want to mention that it is a tantalum as well. The 10V and specific part number aren’t relevant there though. Because you wedged them all into one field there is no way of displaying only the important bit.

When managing larger BOMs it also really helps to have defaults. That’s why I created the default system in Kibom. I don’t want to have to manually edit hundreds of resistors to be 1% if I can avoid it. Actually some CAD packages have a table editing feature that really helps with this, Kicad would benefit from it. Anyway…

I mention this because with your merged fields, it is a little bit harder to do bulk changes. It’s harder for app to parse too, and more error prone when trying to determine if multiple parts are the same (e.g. when ordering what I really want to know is how many 18pf 0603 X7R caps to order, without having to count lines).


EEschema is being refurbished now (get in touch with the developers and involved) and wont help with that task.
All you can do here is drum up some enthusiasm and maybe initial coordination, but to get things moving you really need to get involved with the development of KiCAD - the sooner the better.


In Eeschema’s Schematic Editor Options there is a tab called Template Field Names. In this is where you can define for the schematic you are working on a whole plethora of custom fields that will be auto generated (and populated if you define the Default Value) whenever you go to edit a schematic part. I have 13 in the schematic I opened to check the exact english translation names:

No clue what the maximum number is. The makers of the different BOM tools can suggest to their end users what to populate that preferences tab with in order to get proper compatibility with the fields the tool requires.

I’ve tried using Octopart’s CPL, but their list of parts is quite limiting (for the parts that CPL doesn’t have I’ve tried making CPL-like part numbers for my own internal use). For example, the CPL doesn’t list a 180ohm resistor, but I needed to use that value to get the maximum brightness on an LED and still fit in my power budget. And, the regular Octopart still can’t search on a CPL part number…


I created an issue here:

It seems that at some point last year Github disabled cloning and submitting pull requests for wikis, otherwise I would have done that directly. Please comment there and hopefully we can make this official.


Something I haven’t checked, but don’t user defined fields with no value get stripped?

In order to keep the field, a default value might need to be used as a placeholder.


I set the default value to ‘_’ (underscore).
And the if I create a new symbol (part) in the editor it comes pre-filled with underscores then.

If you have a script that runs through an existing library and you want to add those fields you need to also put some symbol in - underscore in my case - as otherwise they get stripped.


I’ll add the underscore suggestion to the Github.


You give an example of a manufacturer’s part number for a microcontroller, and embedding that number in the symbol makes sense. You place XMEGA32E5-AU on the schematic, and bang! You can generate a BOM with no post-fiddling.

But, what about resistors? Remember the real goal is to have a BOM which includes orderable part numbers, something you can submit to Mouser or DigiKey or whomever without doing any further part-number lookup. This means that a BOM which has a line 100k 1% 0805 resistor isn’t useful, as you now have to go and look up a real part number for that description.

If the part number is embedded in the symbol, then you need, in your library, one symbol for each resistor value you will use. Your library can become unwieldly fast. That said, two companies I worked at did just that – there were several company sub-libraries, one was called something like 1% 0805 resistor, and when placing parts, you had to go the library and select the right resistor value. And if you had to change the value, you ended up deleting the one resistor from the schematic and pulling one with the new value from the library.

Like I said, unwieldly, but in all fairness, it was workable since not every single possible 1% 0805 resistor was in the library.

This is where the scheme of a “family part number” can be used. But it requires some kind of post-processing that takes a partial part number (the “family”) and merges it with the part value to make a final orderable part number. If you look at, say, Panasonic’s part numbering scheme for resistors, it follows an obvious pattern where the only variant is the value.

Actually, it’s more than that, the part number code also includes tolerance and power rating (or case size), so if you have all three of those values, your post-processing can generate the final part number.

But it all still requires that extra post-processing.

I suppose a compromise is this: you place the generic symbol RES_0805 on the schematic, and fill in value and tolerance, and after finishing the schematic, your BOM generator can go through and look for all of those things, work out the actual manufacturer part number, and keep it in the BOM generator’s running list of parts. The final result is a separate BOM with quantities, part numbers, reference designators and the like, all from one operation.

This requires that you choose one vendor for your resistors and your BOM generator knows that vendor’s part-number scheme.

Resistors are easy. Capacitors? Not so much.


I think that’s a bad idea. We tried it at work, the problem is that after a while parts go obsolete or out of stock and the data becomes stale. It’s better to have an application that can recognize things like resistors and capacitors and automatically select the cheapest, in-stock option that meets the required spec.

Often the suppliers have uniform order codes for generic 1% 0805 0.125W resistors that you can simply slot the R value into. They don’t specify a manufacturer, you just get whatever is cheapest and available at the time, because really most people don’t care if it’s a Panasonic or some other brand.

Just have a default setting. Non-polarized = X5R/X7R, 16V, ceramic, everything else can be inferred from the footprint or simply require the user to add some metadata. It would help if Kicad supported table editing of parts.