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).
The solution to this is to make the tools not proprietary from the get go and allow customization of the fields they need to look for - but I wouldn’t demand that of the people who write those tools to first and foremost solve their own problem and then allow others to use them as well.
But yeah, just modify the tool to be able to associate ‘manf#’ with ‘MPN’ or ‘partnumber’ or what-have-you-got and this problem goes completely away.
If there were more predefined fields I also wouldn’t have a problem with those, I just change my libs and the tools could do the same, but it wouldn’t help kasbah’s case, as the libs that come with KiCAD will not have those fields populated.
If one wants them populated he either has to do it the moment he places such a component in the schematic (simple boards, no problem, larger boards … meh) or run his own libs which then automatically become atomic if he pre-fills those fields to not have that work every time he places a component in the schematic.
And to go through all that trouble really only makes sense if you catch 99% of the devices, especially the stuff that comes in hundreds.
‘Atomic parts’ relates to having unique symbols defined with all information set up for each and every distinct device you can use on your board (datasheet, footprint, man#, house#).
This means, cvpcb is not needed anymore.
The big problem with that currently is the way Eeschema works and references symbols (parts)… a C with 100n in a schematic is usually the same value for either X7R 50V or X5R 16V and to find a symbol for it you have to put all that information in the library name, as otherwise the part is not retrievable from the libs.
But then that library descriptor is being used as value field, which is information overload in the schematic and it has to be trimmed down, and you loose all that additional information in the process.
You would be amazed how often MPNs details change for the same part.
Different bulk packaging
Different final assembly and test location
Changes of ownership of the brand
Expressing regulations - recycling, ROHS etc
Manufacturers warehouse software change
Trying to look like someone elses part number for commercial reasons
Somebodies wild idea
How exactly do you expect KiCad to “encourage” this? The only way it could is to have the fields added to the library. There is no point in expending the effort to do so unless you also populate those fields which, if you’ve been following along, you would know is not going to happen. In my opinion KiCad and the libraries should be completely ignorant of these fields. As has been pointed out time and again here the number of parts in the library quickly grows unwieldy when we start adding such information to the library. Never mind the names of all those parts. It also forces the user to decide on things like which manufacturer while drawing the schematic. And if for some reason, ie availability, the part changes then the schematic has to be edited to reflect this. KiCad users would quickly become extinct if this were the case.
KiCad already discourages things like this by not associating footprints with schematic symbols in the library.
A compromise has been suggested and I recommend you embrace it.
Yes, they would have to be filled. For instance, if you take one resistor, set the value and mfpn field, and then copy paste it around. The resulting BOM will be better when you order components.
Just having it the field there empty will serve as a reminder to anyone using KiCAD. And will remove any doubts about which component is needed when sharing the project. It is basically the same argument as why we prefer to have an empty value field in our resistors and capacitors, it indicates that this needs to be filled.
What if the values are the same but the power dissipation is different, or the tolerance, or the temperature coefficient, … and the MPN is the same? Things like MPN are simply not part of a schematic. The schematic describes the electrical properties of the circuit. It does not matter which footprint I use until I layout the PCB. It does not matter who I buy my resistors from until I place the order. I certainly don’t want to be bothered with those decisions while I’m designing the circuit. Nor do I want to edit my schematic every time an MPN changes, especially if it is a controlled document.
That would generate an error as well in this case.
I do however agree that the MFPN does not have anything to do in the schematic normally. The concept of parts is in my opinion prefered. As it stands now the schematic symbol is the part.
It would still be the same as today wouldn’t it? We have the footprints defined in the schematic already since the symbol is the part. My prefered solution would to have the concept of “parts”. Where after the schematic is done. The part with the corresponding footprint is chosen, this would ofcourse change the MFPN and if applicable also the Spice simulation files, tolerances, prices and whatever else you feel like embedding into the part.
I see it as a “symbol” that represents potentially thousands of parts.
I don’t define footprints in my schematic, they do end up there after using CvPcb to associate the footprint with the symbol. I prefer to do the association in CvPcb as it is far more convenient.
I’m not sure you understand the magnitude of the effort required to implement what you propose nevermind the ongoing maintenance that would be required.
In the worst case, the library system would have to encompass the billions of available parts. Even if you back off and say the library must only reflect the several thousand parts you typically use, the task of creating and maintaining the library is daunting.
Well that is just wrong as it stands now, since they also define everything in them. The spice model, The footprint, The datasheet. The symbols should be viewed as the part.
I am well aware of the magnitude. Therefore I would like to have the empty field of MFPN there by default in the libraries. Same way we have the empty field of value on everything. Im not even trying to say there should be a standard library of parts. I am just saying that for any meaningful BOM there must be a partnumber or unique identifer. Therefore the MFPN should be there by default.
Still the same as with footprints today. Schematic symbols are the parts. But except for a messed up BOM you would in that case get a messed up PCB.
I also prefer to do the association in CvPcb, for the most parts at least, mostly for resistors and such though, for microcontrollers and the like i prefer the symbol to contain the footprint already. And thats what i do in my own libraries.
This implies building and maintaining your own libraries, so what’s stopping you? Why do you need an empty field in the KiCad libraries if you’re going to create your own libraries anyway?
Anybody who needs ‘atomic’/‘complete’ parts runs his own libraries anyway and KiCAD allows that - thankfully. We have no problem really. We’re pretty happy campers. And we definitely wouldn’t want to push such a solution to all other users of KiCAD by demanding the introduction of pre-made fields, as it’s pointless from our POV anyway, as to make them useful they have to be filled in which is only humanly possible with your own libs, this means it’s a custom solution right away.
Everybody else who relies on the KiCAD libs for his (hobby) work is served by the native libs and he can do amazing stuff without investing in library work. Absolutely brilliant.
I could see a sub-group of that to want to fill in a MPN field in the schematic to get the ability to have a BOM for easier ordering, but I can’t see how one would ‘like’ to do that for every design he does, so sooner or later he’ll be part of the custom library group with ‘complete’ parts anyway.
That’s why I said, I have no problem with predefining a MPN field for the native KiCAD libs etc., as long as there are at least 4 customizable fields left - for custom ‘complete’ parts libs.
Currrently everyone is served without discrimination.
Adding a MPN field wouldn’t hurt I think, but it wouldn’t help much either.
PS: @TotalKrill
… there is even the option of offering your modified libraries with the MPN field pre-filled to anyone on this planet by hosting them on github. Nothing is really stopping you.
To put a MPN field into all of them is easily done by script, no magic there.
Putting the right information into them and keeping it up to date is the hard part…
.