Current situation (at least for me) looks as the ideal with the given parameters. (number of people, available time, number and structure of libraries that someone has to maintain)
This out of the box experience could easily be a greater headache for others, (and also a less “learning” opportunity for someone; but that’s minor) i’m only trying to avoid this headache here
Validate official library parts before edit them as you like and move them to your custom-production libraries.
Libraries shipping with software is nothing if the software is bad. Should a professional change the software that uses just because some other software suite offers better libraries? Personaly i don’t think that this would be a valid reason.
To sum up, those 4 fields are mandatory for historical reasons, so only those 4 fields are in the default libraries to keep the minimum maintaining effort low. If there were 5 or 50 or 500 people active in the repos, libraries could have been shaped different.
Also, KiCad v6 brought Plugin and Content Manager with it, this is also helpfull in case someone wants to maintain a more “appropriate for production” library and share with the rest of the community.
That’s not a twist.
It’s common sense.
KiCad already has quite extensive libraries, and they won’t disappear because of such a (relatively small) definition change.
It could even come with some guidelines for named fields with specific meaning (such as the current Footprint, Reference, Datasheet, Value and maybe some others.
Another extension I’d like is the ability to rename field names.
With this, it would be easy to fix incompatibilities if different users have different habits.
Standardized field names have advantages because naming issues are avoided in the first place, but it’s an ideal that is not attainable with all the pre-existing databases out there.
I don’t agree at all here. In your previous example you make a big deal about some opamp variants, but it’s not a big deal for a lot of the KiCad users. KiCad has adequate tools to fill in the missing BOM information. You mentioned the AD8622 in that example. If the one specified in the schematic is not present at my favorite store I’d just have a quick look at a datasheet and substitute the part.
There is nothing wrong with the fully specified database driven design, but it’s just another frame of mind. If I’d had to choose between a loosely coupled and flexible design compared to some enforced database driven paradigm then I’d choose the simple and flexible method myself. But there is no reason to have to choose. Database driven design can be added so those who wish so can do it while those who do not like need nor want it just keep the workflow they are used to.
For quite a number of my parts I just turn around, open a drawer and take it out.
No need to mess with part numbers, ordering and days or waiting.
Adding part numbers for several hundreds of series of resistors is really a complicatation that a lot of KiCad users have no interest in.
I do not understand what this is supposed to mean:
Currently KiCad is based on the paradigm of filling in data when needed, which is quite simple and effective. You may call it “dumb” but it’s easy to understand, it works, and it’s good enough for lots of people.
This simple approach and the database driven design are just two different workflows and KiCad could easily support both without “dumbing anything down for unskilled users”.
This discussion has nothing whatsoever to do with repairing boards or bringing up boards based on a schematic. You can do that with a PDF schematic and, maybe, another PDF with real part numbers if information beyond a simple schematic is required.
This is about designing and manufacturing boards. More accurately, this is about the flawed out of the box experience KiCad provides to a newbie or a student because of a decisions, that, while historical, is objectively wrong. Why objectively? Because if you do not modify anything in a stock KiCad application you cannot even order the parts you’ll need to make the board.
And this is OK if it is a hobby. Not the way it is done for anyone doing non-trivial design. Try to do 10, 20 or 50 boards a year using this approach and you’ll figure it out. Try doing boards with a thousand components and see what happens.
Things aren’t done they way they are because I say so. Process evolves over time and with the benefit of hard-learned lessons.
I have yet to see anyone tell me that they can actually build the simple analog circuit I posted to this thread without part number and manufacturer fields. It can’t be done. And that’s the problem. Out of the box.
It is possible to discuss changes or new features you’d like to see without such hyperbole. Clearly you are not correct about this given the number of new users every year that get boards manufactured using KiCad without all the pain that you are imagining. You are assigning way more weight to the fact that KiCad does not come with libraries of parts including orderable MPNs than other people do. It’s fine for this one thing to be super important to you, but it’s less fine to keep insisting that everyone who doesn’t hold this view paramount is wrong, or unprofessional.
Sure it can be done.
I just throw in a few pin compatible opamps and test on my bench if it’s good enough for the application.
It just seems to be filtering a bit in audio frequency range. Nothing special, and I also don’t care about the extra limitations you’re trying to enforce.
I’ve probably got a working product before you’ve even ordered the parts.
This discussion is going nowhere.
Those are just vastly different worlds and trying to get everybody into the same frame of mind is a futile excersice of utopianism.
You started this discussion by complaining about the “Value” field in the symbol libraries. This is what prints on a PDF copy of the schematic. This is the field that contains information like those I gave examples of: the values of resistors, capacitors, and inductors, and the base part number of integrated circuits.
You cannot order anything with KiCad “out of the box” because KiCad does not have a huge database of all orderable parts in the world. Are you suggesting that it should? It’s not linked into Octopart or other search site because they demand legal agreements (and money) for the service. I know, because I looked into providing a link from KiCad to Octopart.
If you have a corporate database of pre-qualified parts, then you want to connect KiCad to that database. Someone else may have a completely different database, stored in a completely different form, for their own parts. They would want KiCad connected to that database.
You need to create a corporate symbol library containing those parts that exist in your corporate parts database. While creating this private library you can add whatever fields are necessary to link to your database. The KiCad roadmap includes work to make this easier, as well as easier Python connectivity which will make it easier to link your private symbol and footprint libraries to your corporate parts database.
I’ve worked with companies ranging in size from 4 people to massive multinational corporations. Each has its own workflow. The larger corporations usually have parts “librarians” whose job it is to qualify parts and vendors, and verify the symbols and footprints used in their designs. These librarians are the people who would be responsible for deciding how KiCad ties in with their corporate databases, and decide what fields need to be added to the KiCad symbols and footprints their engineers use.
Thanks for this. It’s too easy to get discouraged in these discussions because you always run into people who slowly start attacking the OP rather than to engage in critical thinking.
What I am proposing is quite simple. And the focus is in that out of the box experience, not on you or me. I think I can say that the vast majority of KiCad users likely never had to build a board with several 1100 pin FPGAs and a thousand components.
If we take it down to basics. What do you need to build a board? Part number and manufacturer is it. The footprint and everything else comes from those to bits of data. For technical reasons, you also need to explicitly record a footprint so you can transfer the design to layout. So, three mandatory fields:
Part number
Manufacturer
Footprint
That’s it.
To this we add two more, mostly for convenience:
Value
Link (datasheet, vendor page, local PDF repository link, even a database link, whatever)
KiCad designers explicitly chose to not include fields for a part number and manufacturer. Precisely the information you cannot do without in order to make a board. This, to me, is hard to comprehend.
Instead, there’s this semantic mess that sometimes uses the value field for a value and other times for a part number. Yet, none of the part numbers in the stock libraries can be ordered because these are not, generally speaking, real orderable part numbers likely for most parts. LM324 produces 88 parts on Mouser:
So, not only is it a semantic mess (the overloading of “value”) but you can’t order parts from it.
Part number and manufacturer fields are nothing less than essential. Sure, house part numbers codify these two into on designator. However, the greater point is that, at a fundamental level --which is where a newbie or engineering student will exist-- you need those two fields. One way or the other you have no choice but to eventually produce that information.
The out of the box experience has to be sufficient for the newcomer to be able to get from a fresh install to ordering parts and making a board. And yet, yes, you make a valid point…
How do you get from a 2.67 k resistor on the analog filter schematic I posted in another comment to actually ordering a part? Mouser says you have 642 to choose from:
The answer is: You need to nail down a manufacturer and part number. And that information, at that basic level, needs to be extractable from your KiCad schematic out of the box. No coding. No adding fields. No plugins. No creation of an external Excel file to record these decisions.
And you cannot do this with KiCad out of the box.
To answer your question about the complexities of doing this, maintaining libraries and how to deal with the perplexed newbie, my approach would be very simple:
Be a mentor.
And you do this by providing guidance.
And you do this by making a decision: The software has to provide all essential elements out of the box.
This means you add a part number and manufacturer field to every component of every library you ship. And they are, by default, blank. No need to make that decision for anyone.
You also make part numbers and manufacturer fields first class citizens in the code. They have to be, you can’t make a board without this information.
You definitely unlink the value field from the symbol name. I haven’t dug deep into that one yet but I browsed through a thread that made me take pause.
And then you teach people about the basic process. Which, really, isn’t all that difficult. You provide the initial framework that enables full specification of components and give people the ten step (or whatever) process to making a board.
If you do this, in short order YouTube channels would be teaching how to use those two magical fields. Hobbyists and engineering students alike would quickly learn how to use them. BOM’s would be produced without pain or coding that would include this information. You would go from the current status quo, which is that you cannot make a board without jumping through hoops to capture this data, to a clean and basic process.
Professional users who require internal part numbers and other methodology can and have always done it their way. This isn’t about them. This is about a clean and usable out of the box experience with sensible guidance. I think that is currently lacking.
You cannot order anything with KiCad out of the box because there’s no place to store the part number and manufacturer.
Add fields by hand?
Did that. I added the fields in schematic using Tools/Edit Symbol Fields and populated all of them.
They don’t come out in the BOM.
Oh, modify the python scripts that generate the BOM?
I’ve been mucking around with them for an hour. Turns out the script I started with (which is shipped with KiCad) had a bug. Fixed. Now the BOM has that data.
OK, so this is the minimal out of the box experience if you actually want to be able to make a board.
Not great at all.
Now, compare it to this:
You install KiCad. Pick some parts out of the library and wire-up your schematic. As you do, you select actual part numbers, manufacturers and footprints and enter that data into the provided fields. When you are done, you generate a BOM that contains all of that data. You order the parts, and, while they are on the way, you finish your layout. Done.
I just described an out of the box process in one short paragraph that anyone can understand. The explanation for what you have to do today doesn’t even approximate this. And if someone doesn’t know their way around python, forget it.
That’s what a newbie or student should experience out of the box, not the current reality.
A bug in the bom scripts is something to be fixed but If I want a generic resistor then I really do not care from which of the 20 manufactures it comes and having to wade through a list of manufacturers and their part numbers is a complication I really do not want.
And even if I have some manufacturer part numbers there is a quite big chance that the shop where I buy my parts does not even sells parts from that manufacturer and I have to go searching for a replacement part anyway.
I once wanted to order some simple 1k 5% THT resistors at Mouser and I could not find a decent way to narrow it down to less than a 1000 or so different part numbers.
So please get out of your won box and stop pretending that your preferred workflow is “the only right way” and that the rest of the world has to be educated.
Personal attacks are not conducive to useful conversations.
The process you are describing is just fine. I have done that a million times when hacking stuff together. However, this is not what you do if you are in the business of designing and delivering reliable products. It just isn’t. That’s the distinction here. In professional electronics, if you have to make more than a few boards that you have to ship to customers with an expectation of reliability, etc., you don’t pull components out of a drawer and you don’t just go with whatever you can find.
I am in the middle of a run of 2000 boards right now. High power devices with microcontrollers and all sorts of components. They have to have a practical lifetime of probably ten to fifteen years in industrial environments. The process for making such products does not include pulling random components out of drawers.
Many years ago I worked at an aerospace company where we had somewhere between 300 and 600 seats of Altium Designer (can’t remember exactly). Guess what the process looked like there.
It’s OK if you don’t understand this reality because it isn’t yours. No problem at all. Just don’t descend into attacking me because of it. Please.
If KiCad is a hobby tool and that’s all it wants to be, then none of what I am saying is relevant or important. If KiCad wants to grow up to be a professional tool on par with what people like me are using today and have been using for decades, then changes are very much necessary. And, frankly, these changes would make things easier for hobbyists and students.
This isn’t about imposing a workflow. There’s a critically important fault in KiCad that prevents a clean out of the box workflow that leads to making a board. I am calling it a fault in semantic meaning because the value field is being misused. The problem is easy to fix and it would make that out of the box experience vastly better. I am not one of the developers, so I can’t make that decision. All I can do is state my case and hope they understand.
Sure I do understand, but “hobbyists” have no use for those part numbers, and having to choose between 20 different manufacturers just to put a simple resistor in a schematic is not going to improve the “out of the box” experience for them. A lot of the schematics I make are not even intended for manufacturing. Some are only for simulation, others are just to post on a forum or to explain a principle or to test if some idea I have may work.
Beginners, students, experienced people who do 10.000.000 pieces production runs have vastly different needs.
If there is one thing that I do not understand, then it’s why you think that adding manufacturer part numbers are going to improve an “out of the box experience” for people who have no use for those partnumbers. I just want to add a resistor on a schematic and enter a value without any further complications.
It is not a fault at all in KiCad, and certainly not a “critically important fault”.
Those part numbers you keep hammering about belong in the database driven workflow and not in the basic KiCad libraries. Those are two completely different approaches.
KiCad does not have the database driven approach yet, but it’s being worked on as you already know.
Also, Keeping the default KiCad libraries basic and simple can help with the database driven approach and avoid confusion with data mismatches between the “KiCad Library” and the “database back end”
Which user would want KiCad to already have specified an exact part number for their 10K 1% 0603 resistor? A part number that most likely isn’t available at their favourite distributor or assembly house anyway?
A hobbyist, or a professional building a prototype, will most likely have this in his drawer already. A professional ordering hundreds or thousands of boards would want to specify the part number himself.
Also, for simple parts like in this example you’re exaggerating the need for a part number. Most assembly house would prefer being able to use the 10K 1% 0603 resistor of their choice. Possibly by sending their suggested BOM for you to sign off on before manufacturing.
At the risk of reviving old flame wars, search the forum for “atomic parts” to see many of the previous discussions on this topic to give yourself an understanding of the history and discussions of the concept.
Not necessarily. Within the Schematic Editor there is in the Preferences this tab:
Here you can define for your own workflow the names of all additional fields that you need. You will need to manually fill them in when placing parts in the schematic, but at least you won’t have to remember what you call the field for your own workflow, and avoid accidentally using misspellings. AFAIK this is a one-time preferences edit that should apply to all subsequent sessions of KiCad on the computer where you customized this preferences tab.
You don’t have to do this all at once. This can be done piecemeal as you use parts in your designs, saving the new
There is a very good (IMHO) reason why the KiCad provided libraries don’t include ordering information in the supplied libraries. Different people will use different ordering avenues to get their parts. Not everyone uses (or wants to use) OctoPart. Not everyone uses (or can use) Johny’s Electrical Supply down the road. Therefor no specific vendor or manufacturer should be preferred in the KiCad provided libraries, especially the schematic libraries. Footprints often do need to be vendor and part-number specific for things like connectors, switches, heatsinks, etc. But even in those cases there are often drop-in replacement knock-offs (or 2nd sources) available and it isn’t up to KiCad to direct new users to any particular manufacturer or vendor.
As mentioned before (I forget if above or in another thread), this is mainly due to historical reasons and changing this will break more things that it will fix.
I just remembered (and verified in v6.0.4, just downloaded 6.0.5 and haven’t installed it yet) a reason for the pre-baked “Datasheet” field. If you right click on a selected component in the schematic editor, one of the options is “Show Datasheet”. This is a useful link to quickly find and display the datasheet for the part of interest if the datasheet field is populated.
Because it is a hard-coded menu item, it follows that it must be a hardcoded field name.
Ok, after a few of my comments that appeared to be arguing against you it seems that you got down in writing my feeling about the part number and manufacturing fields. On this point, I can argue with you to include these two fields. If one wants to specify multiple manufacturers or change them frequently, maybe a database is the way to go, but at least having manufacturer and part number as default fields provides a framework to build upon (or ignore). But maybe choosing a different name for the “manufacturer” field would be better, maybe “part source” or something similar. That could be manufacturer, it could be vendor, it could be drawer on the wall behind you.
I do understand the developer’s stance that they shouldn’t be hardcoding in every field that anyone could possibly want. They have to draw the line in the sand somewhere. But I think that I agree with you that the importance and usability of just these two more fields should meet the requirements for inclusion in KiCad. Until then, maybe we can convince the makers of the tutorials and YouTube videos to include setting up the Field Name Templates as part of the “install and setup” portions of their lessons.
And to others saying that KiCad shouldn’t be specifying which 10K resistor someone should use from the KiCad Libraries, part of what I quoted above from robomartin is “And they are, by default, blank. No need to make that decision for anyone.”. The argument here is inclusion of the basic framework, not the details.
I think the way forward, instead of a crusade thread, is to actually develop software for enhancing the installation with the desired fields and databases, and then make it public. If packaged well, it could be as simple as install these prequisites, then run this migration script to add the fields and modify the libraries. The existing framework is flexible enough to be enhanced this way.
Include the darn fields. Leave them blank. Provide a proper semantic path for fully specifying a design. If people don’t want to use them or have other ideas, so be it.
I have never, in this entire thread, suggested KiCad needs to make part number decisions anywhere. So if @paulvdh has no use whatsoever for part numbers, just ignore the fields. If, on the other hand, someone actually needs to make a board, there’s an official place to insert this information. And, heck, if someone actually needs to use an internal part number, put it there and ignore the manufacturer field. No issues at all.
This has huge repercussions for newbies and engineering students. It could also improve BOM output, tools, etc. It doesn’t have to take down the entire KiCad culture or historical record. This is just about officially adding two fields that are truly critical and are not there. Leave them blank. Yet have the software understand what they mean, the semantics.
First of all, not a crusade thread. If you read my first post, I explicitly say I want feedback before posting an official feature request. And boy did I get that.
No, you can’t do this with a plugin. The problem is that these two fields need to be first class citizens within KiCad. They are important. And so there are a number of things you likely want to do with them that you will not be able to get done unless the semantic importance receives some thought and treatment in KiCad internals.
That said, we are doing some of this because it is impossible to complete a real design without this information at a minimum. I am on my third design on KiCad. Before writing a bunch of code you have to have a good understanding of what you are working with and what the issues might be. Another few designs and I might get there.
Just adding some fields to the KiCad libraries does not change much, nor is it very useful.
The feature you want (and which is useful) is the database backend which has those part numbers and can do something with them.
Just adding some fields to the default KiCad libraries is the wrong way to go. You first have to implement the database part, or at least the specification of how it works must be finished.
I have nothing against you, nor against the database backend, but starting the implementation by just adding some fields to KiCad Symbols is not the right way to go forward.
