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.
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.
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.
# 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:
What you propose is already doable. Add the field to you components then go forth and populate. But I think you would soon abandon the idea as it’s simply not practical. It’s only even feasible for a handful of ICs, those with only one manufacturer.
For instance, my current board has 29 ICs in total but only 7 different types of IC and most of these have only one manufacturer. 7 is a pretty manageable number. However, my board also has 121 capacitors, 194 resistors, 26 inductors, … Some of the capacitors can be X7R but many need to be C0G/NP0, some resistors can be 1% but many need to be 0.1%, and most of the inductors have various power handling requirements. As you can see most of my time is spent managing the discrete passives and not the ICs. Your proposal would be of little benefit in this case.
If you were designing a board with mostly ICs such as CPU, RAM, Flash, and very few passives then it might make more sense. But honestly how much time do you think it would actually save you?
I am already doing in a way I like for my own projects. I would simply like a convention that will make various tools like KiCost, my extension, whatever BOM tool de-jour to work together better.
7 components is 7 things you don’t have to do. Makes sense to me. In the future everything will just be ICs anyway.
We already have datasheets linked in and a manufacturer field. Not sure why people are so resistant to this on here. Does nobody think this is a little step towards making things easier? I would like to stop arguing over the “why” and get more into the “how”.
Nobody is actually addressing the issue though: having even one or two parts defined and setting a convention is way better than having nothing. What it enables for the tooling like KiCost and 1clickBOM is valuable to us, who are writing these tools (if I can presume @devbisme thought it would be a good thing to make use of in KiCost).
I think the first step would be to enable lists and key: value type data in the property expression allowing multiple and precise MPNs per part. This could then be used by everyone no matter if these fields are added in the standard library.
It would be nice to have some conventions for certain part attributes, like manufacturer’s part numbers, so tool builders would know where to look for things. If I build a library with a field called manf#, and somebody else builds a library with a field called ‘MPN’, then the tools have to be able to find part numbers in both fields. And the problem gets worse as more people make more libraries using different field names for the same things.
I’m not asking for atomic parts (whatever those are) or re-writes of libraries or anything else. But is there, or can there be, a list of field names and definitions of what they contain which library creators and tool builders can follow to minimize incompatibilities?
Currently we have a schematic symbol for a 7400 part and we can choose from a number of footprints that satisfy most (all?) variations of this part. To add the manufacturer’s part number to the schematic symbol in the library we now need a new symbol for each variation, 74F00, 74HC00, 74HCT00, 74AHCT00, 74LS00, 74ALS00, 74LVT00, 74LVC00, … you get the idea. Is that going to happen? Of course not. Nor is it feasible for any passives.
I think the fields and their names are the least of the problems associated with adding such information to libraries. The tools could always be made configurable and even accept more than one name for the same field. Then if people want to add this information to each schematic they create then the tool could make use of it. That approach is certainly more feasible and doable without expending any developers efforts.
Edit: We, as a community, could decide on some names for these fields if you feel that is at least a step forward. Then the tools could be adapted and people could at least put this info in their schematics.
If KiCad can encourage a convention it will have much more impact than just deciding as a community. I will make a request for comment on the dev mailing list. If any other tool writers would like to see encouragement towards convention for an MPN field in KiCad please speak up (@opticalworm, @reinis, @SchrodingersGat, @John-Nagle, @crashbang_proto).
.