A github issue requested that KiCost support a field called PartNumber (or something like that) that the KiCad libraries now had for each symbol. I’ve got a nightly Windows version of KiCad and I’ve examined and grepped the symbol libraries but can’t find any field like that. Does such a field exist? Is it in the standard libraries that are installed with the nightly builds, or is it somewhere else?
2 Likes
I think you may have been misinformed. I don’t see a PartNumber or similar in any official KiCad libraries.
Possibly someone has added a PartNumber field to their own libraries. Personally I use “MPN” for manufacturer part number, as distributors also add part numbers so “PartNumber” could be ambiguous.
1 Like
I have never seen it either in the Libraries, but I use a special field named MFPN for manufacturer part number. Things quickly fade from memory unless you use some kind of unique way of identifying components. I would like to see a standard (even if empty) field in for a manufacturers part number, either it be MFPN, MPN or something else, just a good thing to add to every project anyway
2 Likes
I think I was confused about that same KiCost issue in the past as well. We should propose to add a standard field to the symbols if it hasn’t already been proposed. For me it’s important as it would help with exporting and importing from my browser extension.
OK, thanks for the answers.
Be careful when you start doing this - it could get very messy very quickly. For starters:
-
As already mentioned, a vendor or supplier may also have a part number. which is different from the original manufacturer’s part number. And, a particular manufacturer’s part number may be available from multiple vendors or suppliers.
-
A part number by itself doesn’t mean much unless you also know who issued and controls the part number.
-
A group of totally interchangeable parts, all from the same manufacturer, may have different part numbers depending on how the parts were packaged for sale (big reel, small reel, bag, box, wheelbarrow, boxcar, etc)
-
Many of the components we use in KiCAD have several possible manufacturers, each with a different part number. (In many organizations it is standard practice to list at least two different manufacturer’s parts for every item in your design.)
Dale
1 Like
Well MPN is pretty clearly defined and distinct from retailer SKUs. The manufacturer controls and issues it. The fact that packaging sometimes comes into it does make it a bit hairy.
In my extension I allow multiple MPNs per line item. I don’t think KiCad deals with this very well and it would be interesting to see if we can do something about this as the schematic format is getting an overhaul. We could possibly have lists or dictionaries as properties or allow multiple manufacturer fields and use the convention of “manufacturer:mpn” as the value.
It’s not something that makes sense for all components but it should be added to those where it makes sense. It would just be nice if the ecosystem settled down on a convention.
I certainly agree! I have at least minimal familiarity with over a dozen such systems. None of them truly satisfied me, but even the worst of them was an improvement over no system.
Of course, once you have a system of in-house part numbers, the next step is developing the discipline to implement it consistently. And then you need to make certain that the major stakeholders - design, purchasing, and manufacturing - have the visibility they need into what those in-house numbers represent.
Hobbyists, free-lancers, and very small shops simply don’t have the resources to perform those tasks well. KiCAD is a decent tool for schematic capture and PWB layout. Please think carefully before committing resources to adding MRP and configuration management to its list of features.
Dale
1 Like
read the answers from @dchisholm and @Andy_P very carefully, they essentially are the reason we don’t have what you desire out-of-the-box.
But fear not - KiCAD enables you to do it yourself, for your couple 100 preferred parts in your own personal libraries without much fuss.
Just do it and don’t wait for others to do the work.
IMHO - KiCAD won’t come with predefined MN number fields as neither the manpower nor the infrastructure is there to be able to manage such detailed libraries for the next 10 years.
To use the field you’d have to run your own libraries anyway, as otherwise any reload of the official repos will wipe anything you put into them.
Or you’d have to fill in each field everytime you create a new project and place components.
Sisyphus much?
Set up your eeschema for atomic parts, use your own libs and be done with it already.
The tools are there, just learn to use them.
On both points - the clear definition, and the distinction from the vendor’s P/N - I’d say that sometimes it is, and sometimes it isn’t.
While the topic of information fields is on the table, are there built-in fields containing a name, part number, revision level, and revision date for the products defined in each KiCAD project? In general, the schematic diagram, the (unpopulated) board itself, and the (populated) assembly built on that board would each have a separate P/N. (In a few organizations they all have the same number since they (supposedly) refer to the same thing.)
Each of these sets of information should be accessible from any of the tools in the KiCAD suite. E.g., in PCBNew I should be able to etch the circuit board’s name, P/N, and revision on a copper layer; and write out the assembly’s information on silkscreen; and note the schematic diagram’s identifying information on a Fab or Notes layer. Likewise, on the schematic diagram I may want a note telling me the name, P/N, etc of the board that is based on that diagram; and the identifying information for the assembly built on the board. And ALL of these annotations should automagically update when I change something in the project’s saved fields.
Dale
1 Like
MRP databases and preferred parts are all well and good but I am not interested in a solution that will work just for myself.
I think standard field name for the manufacturer part numbers to be added to symbols where there is an obvious set of MPNs makes sense. I don’t see how the rest of it has any impact. If it doesn’t make sense: don’t add it. If you have your own system, at least you know what the KiCad convention is. If you don’t like it: just ignore it.
Maintenance seems like an append only operation to me: even if a part is discontinued I don’t see the problem of leaving the reference to it. If there aren’t enough people to help with it (and I am certainly willing to help) so be it. If even one is added it’s already better than none as long as the convention isn’t broken.
For these fields to make any sense (I take it your motivation to populate them is to create a useful BOM) they either have to be populated in the KiCAD official libraries or each time you place them in your schematic.
Now, having the KiCAD libs come with these fields pre-populated you essentially ask for atomic KiCAD libraries.
Good luck with that one.
Many parts in the libs would multiply by 10-100 or many more parts… that’s just insane.
If on the other hand you just want this field to be there, alas empty, then for them to be useful you have to fill them every time you place one of these components in your schematic.
Seriously?
What use is that?
So again, what you ask for is either near impossible or just not useful, but if you personally need a field like that you can have it today, for you own personal libs.
Just set up your libs with atomic parts and voila, you got it.
The work needed to cover most possibilities for most users of KiCAD in the official libs is just to overwhelming.
Maybe someone invents/implements an open-source-way of doing this, that will make it possible to have atomic parts that are peer reviewed and 99.5% safe to use without checking, but I wouldn’t hold my breath.
Just signing up for doing a couple of parts won’t be enough to solve this puzzle.
The infrastructure needs to be there first… that’s the thing you would need to aim for if you were offering help.
PS: I’m not a dev, just a user who helps moderate this forum and others with the tool.
Yes, it’s for BOM generation purposes and to make the BOM scripts and tools for KiCad settle down on a convention.
Here is an example. You open a new schematic, you add a part “ATMEGA32U4-AU” from the standard library, why shouldn’t this have MPN field(s) with ATmega32U4RC-AU, ATmega32U4-AU and ATMEGA32U4-AUR?
MPNs frequently change, house part numbers are used to hide this from the CAD drawings.
Worse, it’s common to find identical part numbers from different manufacturers for similar but incompatible parts
This covers one specific MCU that you personally use.
Please - just in your head - repeat this process for the countless resistors, capacitors, leds, diodes, semiconductors, etc. pp. and tell me it doesn’t get mind boggling pretty fast.
I alone got 4 libs for capacitors from Kemet for 0402, 0603, 0805 and 1206 in 50V/X7R.
I also got 4 libs for resistors from Stackpole for same housing sizes.
Do you get my point now?
Again, you’re asking for atomic parts in the official libs. That’s not working with current infrastructure or procedures.
The librarians can hardly keep up with reviews and pull requests from what we hear.
I don’t think that’s right. Even if they release the same part under a new part number just add that part to the MPN field.
As mentioned previously the MPN field should tie Manufacturer and part number together. So it should be something like Atmel:ATmega32U4RC-AU in my example above. If Microchip get rid of the Atmel name and take over all the parts append Microchip:ATmega32U4RC-AU, If they rename it to AVRPIC or something stupid then append Microchip:AVRPIC32U4RC-AU.
@Joan_Sparky I think you missed the bit where I said it should be added to just parts where it makes sense. It obviously doesn’t make sense for resistors and capacitors.
It absolutely makes sense for resistors and capacitors, or how do you want to order them with your BOM?
Those 2-3 MCUs or 5 semiconductors you could easily manage by hand, but all those resistors and capacitors… how do you keep track of those?
And if your ‘solution’ isn’t one that applies to all devices or for that someone (who is that by the way) determines ‘sense’ it’s pointless to even think about it.
It doesn’t make sense for resistors, capacitors and any parts that have too many possible MPNs to manage because of the reasons you outlined. My solution for resistors and capacitors so far is to try and extract a description once they are matched with a footprint and match that against the CPL and search Octopart and Findchips.
If there is a standard way to define MPNs for components where it makes sense then it will be a solution to save anyone some work should they choose to take advantage of it. It doesn’t have to be a total solution for all parts.
I just did some digging and found the documents outlining the new format.
In those you can find for instance:
# A 74LS00 is as simple as this.
(part "74LS00" inherits "7400/rev1" (value "74LS00"))
# This is a so called heavy weight part definition of a Texas Instruments
# part number SN74HCT00NSR.
(part "SN74HCT00NSR" inherits "7400/rev1"
(value "SN74HCT00NSR")
(footprint "14-SOP")
(datasheet "http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn74hct00&fileType=pdf")
(keywords "LOGIC" "NAND")
(property "Description" "IC GATE POS-NAND QD 2IN 14-SOP")
(property "Manufacturer" "Texas Instruments")
(property "Vendor" "Digikey")
(property "Vendor Part Number" "SN74HCT00NSR-ND")
)
I don’t see why there shouldn’t be a standard for MPN in there although part actually seems to be it? Would be good to get some clarity on that.
To me it would make sense if a property field was added that allowed MPN Manufacturer combinations:
(property "MPNs" "Atmel:ATmega32U4-AU" "Atmel:ATmega32U4RC-AU")
or even better really
(property "MPNs" (mpn "Atmel" "ATmega32U4-AU") (mpn "Atmel" "ATmega32U4RC-AU"))