I would like to generate a bill of materials from Kicad, containing the order codes of the used parts, for instance farnell, mouser, digikey, conrad, and so on.
In the Kicad Library Convention, S6.2 I see only the following fields are allowed:
Reference field is selected appropriately for the symbol and is visible
Value field contains the name of the symbol and is visible
Footprint field contains footprint link for fully specified symbols and must be invisible
The footprint field must be empty for generic symbols
Datasheet entry [1] is filled out, and is invisible
The symbol contains no other custom fields
Additional documentation is provided via two other fields:
Description field contains comma-separated device information
For symbols with a default footprint, the simplified footprint name should be appended to the description e.g. SOIC-8
Part name should not be duplicated in the description field
Keywords field contains space-separated keyword values. These values are used to assist in part searching and should not include filler words
Why was the decision made to not include or allow fields that contain ordering information?
In my opinion it would be nice to have standard fields in the library that show where a part can be bought.
Because it’s next to impossible to maintain. There many more suppliers than the four you named and each of them has several options like reel, tray, re-reel, cut tape, RoHS, non-RoHS, lead-mercury-and-cadmium-only…
Each time one is added or updated, a merge request and review is required.
I once did a search on mouser for a 1k THT resistor on Mouser.
They had several hundred different versions.
Ordering information also goes obsolete quickly. Conrad for example (used to?) change order numbers each year and it would be a impossible to keep such info up to date.
[Edit:]
It was in the days of the paper catalogs and I was still young (past century) that I compared a bunch of products from different catalogs. After a while I noticed that a part of the type number changed for each catalog. Apparently the year of the catalog was encoded in the order numbers.
[/Edit]
Some EDA progams have (links to?) some kind of database which may also do inventory management and generate ordering info if stock runs low. That would be a better place to put such info. KiCad does not have such a system built in however.
Agreed, this can potentially add a lot of fields. But as far as I can tell, this is static data. I have never seen a supplier re-use their ordernumber to point to another part. Worst case scenario is that the symbol library gets bloated with order codes that are no longer relevant, as that code can no longer be used to actually order the part.
I agree this will make the review process of new parts longer, and it increases the amount of times a part receives updates.
The other side of this coin is that I can’t let other people benefit from the work I have to do. For all the components I use in my designs, I have to add fields with the order codes anyway. For me it’s not such a big step to make merge requests after I’m done, and I can also check the merge requests coming from others to see if their order codes are correct.
The alternative is that I fork the official libraries and add the order codes there. This creates the situation that I have to strip out the ordering codes before I can summit new parts to the official library.
I understand the thought process behind the decision, but this removes almost any benefit for me to submit new parts to the library.
Agreed. For commodity parts it’s not worth it to put all of the options in the library. I’m talking more about “more unique” parts like this IC for example: “ATMEGA328P-AUR”
Farnell has 2 options, mouser also has 2, conrad does not have it, RS components has 2 options.
They do? I maintain an Altium library at my day job that stores Conrad and Farnell order codes, and I am yet to see this happen. Getting out of stock, sure, but not pointing to another component altogether.
KiCosts aims to solve (part of) that problem, but it relies on extracting the manufacturer part number from the schematic. From their web page:
KiCost’s main use is generating part-cost spreadsheets for circuit boards developed with KiCad as follows:
For each part in your schematic, create a field called manf# and set the field value to the manufacturer’s part number. (You can reduce the effort of adding this information to individual parts by placing the manf# field into the part info in the schematic library so it gets applied globally.) The allowable field names for part numbers are:
mpn pn p#
part_num part-num part#
manf_num manf-num manf#
man_num man-num man#
mfg_num mfg-num mfg#
mfr_num mfr-num mfr#
mnf_num mnf-num mnf#
Distributors stock code can be also used through the specific field name listed bellow and they are prioritized to get the part information.
Digi-Key: digikey# digikey_# digikey-# digikeypn# digikey_pn# digikey-pn#
digikeypn … digikeyvendor# … digikeynum … digikeyvp# … digikeyvpn …
Mouser: mouser# …. …
I’m the one working on database interface. It won’t be directly connected to getting ordering information from vendors but will be possible to do that kind of thing. There are also other possibilities, like plugins to fetch information from vendors, etc.
I wouldn’t be fundamentally opposed to maintaining an order number/link/whatever library (separate from symbols), BTW, but I really wouldn’t want to deal with loads of one-line changes to the actual symbol libs.
The way I personally see this working in the future:
Library (public or personal/corporate) maintains the part info including full MPN
User’s choice of plugin can retrieve information from the vendors about orderable PNs from that MPN. Maybe there are plugins for a variety of services like Octopart, etc. This info gets added to specific designs, not the libraries.
Users get whatever specific information they want in their BOMs; KiCad library team doesn’t have to maintain anything specific to vendors.
Right now KiCad doesn’t have “good enough” support for fully-specified parts in my opinion. So, I’m going to work on fixing that, and then eventually the KLC could be updated if the library team wants to store fully-specified parts (rather than collections of symbols and footprints) in the official public library.
There is a difference between a library of symbols and footprints and a library of parts. I use the word “part” here to mean:
A specific symbol
One or more specific footprints (since some parts can have various valid footprint choices)
Metadata, including at minimum a MPN
Right now you can create such libraries of parts by adding a bunch of fields to KiCad symbol libraries, but there is no standard for doing so, and there is no easy way to re-use one symbol on multiple MPNs. This is one problem I’m trying to solve with the database libraries project, but database libraries is not the only way this could be solved.
Either way, I think KiCad first needs at least one better way of defining “part libraries” as opposed to “symbol libraries with part metadata attached to symbols” before the official KiCad library starts accepting part data.
I think the developers and library team would prefer not to standardize adding part information to symbols in the existing library because that doesn’t solve the problem of wanting to share symbols between multiple parts.
I see your point. Adding part information using symbol fields is not a long term solution, as I do agree part information can better be handled by a layer (database) above the symbols.
I do think having a standard for part information can be useful, as standardized information can later be ported from the symbols into a database. Non-standard data is much harder to feed into the database, and no data is impossible to feed into the database.
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.
