Default manufacturer's part number field in KiCad libraries

[kuro68k]

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

kuro68k/kibom

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?

[davidsrsb]

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?

[kuro68k]

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)?

[TotalKrill]

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.

[devbisme]

I wrote KiField to handle things like that.

[hack]

[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).

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

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

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

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

[TotalKrill]

@hack

Do you really need any more than three columns to identify a given part for purchasing?

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.

@hack

I only ever use three. My BOM

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.

[kuro68k]

@devbisme

I wrote KiField to handle things like that.

Excellent, I will give it a try. Thanks.

[kuro68k]

@hack

Capacitor:Value | Description | Geometry100u | 10V tantalum, AVX TPSD107K010R0100 | 7343m10n | 50V 10% X7R ceramic | 060318p | 50V 5% NPO ceramic | 0603

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).

[Joan_Sparky]

EEschema is being refurbished now (get in touch with the developers and involved) and KiCAD.info 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.

[SembazuruCDE]

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…

[kuro68k]

I created an issue here: https://github.com/KiCad/kicad-library/issues/808

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.

[bobc]

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.

[Joan_Sparky]

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.

[kuro68k]

I’ll add the underscore suggestion to the Github.

[kuro68k]

@Andy_P

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.

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.

@Andy_P

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.

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.

@Andy_P

Resistors are easy. Capacitors? Not so much.

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.

[davidsrsb]

Using 3rd party part numbers in a change controlled schematic is asking for problems later. House part numbers are the standard way of preventing the need for frequent changes

[dchisholm]

@davidsrsb

Using 3rd party part numbers in a change controlled schematic is asking for problems later. House part numbers are the standard way of preventing the need for frequent changes

It doesn’t have to be under a change-control system. Any assembly that will ever need more than one parts purchase has a potential for problems.

Please keep KiCAD as a design tool until it is fully matured and truly state-of-the-art. Don’t try to add in MRP functionality.

Dale

[kuro68k]

@Andy_P

What about when you use multiple suppliers? I know our purchasing person trades off between all of the usual suspects when ordering, so she needs to start with a manufacturer’s part number, not the supplier’s number.

That’s why I suggest not having supplier order numbers or anything like that. And yes, the purchasing department needs to have a little intelligence to handle generic parts, that’s unavoidable.

Again, no one is forcing you to use all this stuff, it’s just that BOM generators can do so much more if there is some agreed standard for the data.

[dchisholm]

@kuro68k

. . . BOM generators can do so much more if there is some agreed standard for the data.

That is certainly true, but many of us keep pointing out that there is no real consensus on the ultimate objective of the data structure, much less a standard for the data elements in that structure.

Many of us would prefer to have the capability to define a significant number of fields - probably a dozen or more - by giving each of them a locally-defined name and filling them with the data we individually find useful. Then a BOM-Generating tool needs a way for us to define a map that essentially says, “My local field nn, which I call “Part Type”, should appear in column mm of the BOM, which the BOM calls “Description”.”

Dale