Why not start an official KiCad Atomic library?


So, since I started this thread, I was going to offer the following. However, I realized I wanted to think it through a little better. But, then, several seem to have caught-on to where I was mentally headed. Here it is:

How about this for a start?
Like the device suppliers I mention, create a unique intelligent “house” part-number for KiCad (KPN).
This is just the “part number”:
Ref Designator - (Value/Simple Part Number) - Mounting Type - Footprint - *Optional MPN



Concentrating on the IC first. This KPN would basically just be a “data holder”. The actual symbol and the actual footprint would remain where they are now. The Texas Instruments NE555P and LM555CN Fairchild/ON Semiconductor can both use the same symbol and same footprint.

For example:

With intelligent part number creation, the symbol and footprint are specified in the name itself. The MPN in the KPN would be the orderable device number.

Contained inside the “KPN” would be several fields. For example from the TI 555 datasheet:

Order-able Device
Package Type Package
Eco Plan
Lead/Ball Finish
MSL Peak Temp
Op Temp (°C) Device Marking

Hope this gets some thoughts generated to help make this happen.


I think you meant that one house number may have different MPNs. Certainly it could be done that way. The simple fix for this is not allow it for the KPN library. Each library entry must be it’s own unique entry.


I’m glad you asked! I know of one situation where it seems like the KPN is just the easiest way. It just so happens that Digkey has thrown a monkey-wrench into the works. A person can order their Digi-reel. The MPN of the part number is the same, but the order-able part number is not.

Using a KPN, then the OPN (Orderable Part Number), could be the MPN or the Digikey number.


My comment was slightly off-topic since I thought of all the past discussions where people asked for an additional field to be added to the current (non-atomic) libraries to house their HPN/MPN/etc. but could not agree to a common name for that field.

If it were called “KiCad Part Number” there would be no mistake as to what the purpose is: An identifier for the part inside the KiCad libraries.

This was not to say that the KPN field should be pre-populated with a number, it ist just a name for a field. People are then free to use that field for their HPN, MPN, PON or any other numbering scheme they need for their purposes.

Anything that @Sprig wrote after my first comment pretty much says everything else about the use for the KPN inside the atomic libraries.


Why not start with what EAGLE has done, and take advantage of all their thought and experience?

I don’t think Atomic Parts should be separate as they are a superset of the Symbol and Part.

KPN sounds good, but I think there should also be a ‘display key’ field. It’s nice to have a globally compatible idea, but the truth is most users have a set (relatively) few number of ‘favorite’ parts that they go back to again and again across numerous projects. I think those are the best candidates for Atomic Parts – all the project-unique and one-off uses don’t really warrant the time to create an Atomic Part, and keeping track of and using all that madness (in the form of huge KPN’s that are just ‘foreign keys’ that concatenate various other part database fields) seems to be an endless blackhole. Maybe I’m talking about a Favorite Parts as a subset of Atomic Parts…

Also, I’m pretty sure there needs to be built-in the expectation that the datafields are going to grow in number, change names, and be different amongst various supplies, manufacturers, and users. EAGLE allows this, although clumsily, in their “packages”, “attributes” and also “technologies” features that are attached into devices (ICYDK, a device is a part + symbol and the pin-pad interrelations).


Actually there is a very good reason, which is that people have different requirements. Usually that means there are different applications, but often people doing the same task have different requirements depending on the scenario. Anyone who says “there is one solution that fits everyone” probably hasn’t done much work with engineering, or people.

At work we design with an in house part number which specifies a functional part, and we provide a list of manufacturers with second sources if applicable. It’s up to manufacturing/purchasing to decide what packaging they want, and where to buy.

That is just one of many scenarios. Small companies with no specialist buyers, companies who outsource. Probably people working in safety critical would never let purchasing decide on a part, they might even need to sign off parts on a batch basis.

Anyway, nothing I’ve seen here suggests there is anything close to agreement, nor is anyone willing to put in the effort to make it happen. People seem to think if there was a default, approved KiCad field name, all the rest would magically happen.

I am increasingly of the idea that the best way forward for commercial users of KiCad is to partner with information providers who already have the data and a business model to support it. For KiCad users creating Open Source projects, they will have to make do with public sources of data. Arguably as soon as you attach a specific MPN or vendor SKU to a part, you entering non-Open territory anyway.