I don’t think you have to solve everything in KiCad itself - it will make the software (and in this case the libraries) bloated.
You can already export a BOM with Part # information, why not take it from there? A BOM pricing tool could then also be more general, i.e. also be used from Eagle, SnapEDA or whatever, which in turn means more people could use and maintain it.
A simple implementation could be based on Google Sheets - if someone were to develop a digikeyPrice() macro, you could import your BOM into Sheets, add a column and you’re good to go with digikey prices…
KiCad users are all over the world, I use Element14 Malaysia, which is related to Farnell, but not the same.
Who is Conrad?
Maintaining uniqueness internationally gets very hard to check
I used to work at a UK company that had a component standards department. Each CAD part had a house number. This was stable with time. The database of house numbers to actual part numbers - still no ordering info, was extremely dynamic as companies kept changing the exact part number with production site, packaging and compliance changes.
If this was an easy problem, there would be no need for expensive SAP licenses
Kicad cannot export the Part # if it does not know about it first. That’s why I try to get permission to add the part # into the official Kicad libraries. I don’t want to do that work because I’m such a nice guy. Instead I want to reach the situation that the official Kicad library already has all the the Part numbers, so I don’t have to add them anymore. This can only be achieved if the following conditions are met:
-obtain permission to add a field with the part #
-reach consensus about how that field should be called.
-reach consensus about how that value should be formatted.
From this answer from @chschlue I conclude that adding a field with the part # to the Kicad symbols is out of the question, so for now, Kicad will never be able to generate a BOM with the Part # from only the information contained in the official libraries.
?!
This is only true if you rely on the official library of symbols/parts for your project and don’t add additional fields to your schematic/project in Eeschema > Tools > Edit Symbol Fields
You are free to define any field you like additionally to the ones coming from the library and each symbol you place in your schematic will have that field then.
You could do the same in the library - just no idea right now about that current project settings re extra fields is what is being carried over into the library or if there is an extra settings gui/file to make this happen for the lib files themselves.
Been to long ago I did that… heh
I run my own libs (from scratch) and they got Manf# and Manf fields defined… plenty others here do it similarly.
The BOM coming out of KiCAD then contains all the info we need to sort out ordering.
For the record: This thread was originally about supplier part numbers, not manufacturer part numbers.
Currently, symbol:MPN is a 1:m relationship and MPN to supplier PN is more like m:n.
That’s why I believe a database-backed mapping is the way to go here.
Note that a simple mapping from current (fully-specified) symbol names to MPN could work analogous to how footprint filters work. (Generally, but not always, MPNs correspond to the wildcarded symbol names with an additional suffix.)
So you want official parts libraries, not just symbols, footprints (and 3d shapes) libraries.
As has been explained further up by @craftyjon, KiCAD right now is not cut out for this level of support of user demand vs. how much work would be required (or is available) by volunteers to maintain that thing.
Symbols and footprints (and 3D shapes) are mostly script generated for the bulk of it, to keep manual work to a minimum.
It’s just not feasible how you naively (sorry) expect this to work.
Agreed. I underestimated the problems and amount of maintenance work adding supplier part numbers would cause. It would have only solved my use case (ordering parts from my specific set of suppliers), and create a burden for everybody else. The symbol library is not the place for that information.
I agree that a database that creates parts by combining a manufacturing part number, a symbol and a footprint (and possibly a SPICE model?) is the way to go. But that’s not a solution that is available today.
I am slightly against using an actual database, as I think files containing the same information would be easier to version control.
I’ve looked at the BOM generators in /usr/share/kicad/plugins/
bom_csv_grouped_by_value_with_fp.py looks for the field “Vendor”
Kicost looks for the field “manf#” (and a whole lot of simulair field names)
I would like to apologize for my poor choice of words in my previous answers. It was not my intention to offend anyone. English is not my first language.
I think @craftyjon has abstraction in mind, not a fixed PostgreSQL schema or something.
I assume you would be able to choose from pretty much anything from Oracle and ERP systems to a bunch of CSV files.
I was not aware Kicad symbols were also script generated. This gitlab page shows the scripts for footprint creation and Packages3D creation. Could you point me to the repository of symbol generators? https://gitlab.com/kicad/libraries
I’d say adding the manufacturer part numbers to the symbol creation scripts (instead of adding them to the symbols themselves) wouldn’t be impossible to do.
I respectfully disagree. Part numbers for “generic” symbols like “C” or “R” make no sense, there are too many options. Part numbers for non-generic parts, like a MCU like the STM32F030C6Tx are already part of the symbol value field.
That’s enough information as a starting point for a price search for the parts that could be used for this symbol. Even once you add the footprint information, you don’t have all the infos you need: as others have mentioned above, the same physical part (same footprint, same function) can have many pin-compatible variants, like different tolerances/precisions, different parameter (e.g. gain) values, different speeds, different RAM quantities, different chemistries (Lead vs. no-Lead), different packaging/order volumes (reels vs cut tape), etc… so any given symbol, even if for a specific part, could have 100s of different concrete versions, all with the same main part #.
So there is no general way to make “one part number” for one symbol - each symbol can have many many parts, and when it comes to prices, many prices from different suppliers. Different suppliers are relevant to different customers and different geographies.
In short: what possible value (in general, for other people, not just yourself) can it have if you add a single supplier part number to a given symbol?
This helps you, but it is not a general thing, and therefore should not be part of the general symbol libraries.
And that is also the solution I would recommend: in your design, when designing and deciding what part to order for each symbol, add the Manufacturer and Supplier Part# fields to each component in your design. Then you can export this into your BOM in the way you want.
But don’t make it part of the general libraries, because it is part of the design work each designer has to do for his circuit, and can’t be solved in a general way for everyone.
I used to work at a place where we drew schematics with the NATO stock number.
This meant that all the info was there, but you had to remember that 5905-01-088-8299 was a 10k 1% resistor
This issue has been a problem forever, and the “correct” answer to how this should work depends on the environment you work in. If KiCad is to be used in corporate design work, there needs to be a good resolution to this issue. At the same time, hobbyists and casual design engineers certainly should not be hobbled by the requirements that would be needed for that world.
Obviously, the solution needs to be some kind of support for standardized optional fields. In my own work, I opted to include in my libraries fields called MFR, MPN, VEN, VPN, with the meaning being somewhat obvious. Works most of the time, except when I forget and call one of them MFRPN, or VENDOR, which makes sorting and merging impossible. So establishing a group of fields with uniform names to contain this information has great value. If these fields are in every part, even with no information in the field, it avoids the necessity of creating them every time you make a library part. I would consider it acceptable to have these fields emptied for uploaded libraries to merge with public data.
Considering that this information is constantly changing, like when there is a part shortage and you must substitute, it does not make sense to try to keep a library or even a single schematic up to date with accurate part numbers. This is why having a part database is the best way to control purchasing. But maintaining that database can be a full time job. Using an internal company part number allows you to separate the information in your design from the everyday reality of purchasing parts. You can use generic library parts, and fill in a number in a User Part Number field as you refine the design, and that part can be purchased by finding it in a database. It allows specifying second source manufacturer, second vendors, temporary substitutes, order tracking history, etc, all tied to a simple number added in your design. The design of these number systems is another huge subject. There is some consensus that it is best to keep the numbers simple, and use search/sort capabilities to figure out the details. Making this work requires some discipline, which is in short supply here.
I see a really good opportunity for a company that provides libraries and part database to sell. JLCPCB in Shenzen provides a spreadsheet that contains almost every part you will ever need, and they stock those parts to build your boards. They include a part number from JLCPCB. https://jlcpcb.com/parts
I don’t want to spend time maintaining a database, so I have opted to put some of this information into schematics and export to Excel for final edits. It is not a good solution, but it gets the job done quickly. I mostly use the old PCAD program, which has some similarity to KiCad. The biggest difference is that I can create a “component” that is a combination of a specific symbol and a footprint and allows me to assign “attributes” to the group that can contain these part number data fields.This is the essence of the KiCad atomic library, but there is one more layer to consistently manage the information synthesis. The symbol and footprint can still be generic, but used in a specific component combination. A part like a 5% 0805 resistor can be semi-generic, containing most of the part number without a value.
I do hope that the next major release of KiCad will include some progress on this issue. At least some decisions how it fits into the roadmap, and some guidance how to do it yourself until then.
I use a small web application I wrote for this purpose that extracts the information from the KiCad BOM. I add a field with my part number and usually have different distributors for each part no. in my database. This is not too much work, I believe. There is a post about it here: KiCad BOM to Database
You could also combine existing fields and look up the part no. from a separate table in your application, e.g. value+footprint = “10k 1%+0603”->part no. but you must keep the combination unique.
Arbitrary complex algorithms can then be used then in the application, e.g. find all parts for a BOM that are not in stock and distribute them to several orders such that total cost (including postage and packing) is minimized…
A big drawback is that you cannot define user fields for aliases!
I developed a similar BOM processor a few years back which was tied into a SQL database of my parts which were managed in PartKeepr. The manufacturing and ordering information was derived from Octopart. Unfortunately, Octopart was taken over and free access was removed. This still works (at present) with a ‘paid for’ tier.
Recently, Octopart has released a new, free API but I have not had time to re-write this to use the new graphQL interface. Collating component data is always going to be time consuming and costly and access to any external service is potentially vulnerable to changes and takeovers.
