I’m not sure where I come down on this issue. I can see the pros of encouraging best practice by including a default (and mostly blank field) in the KiCad libraries. It sounds like this is a discussion worth bringing to the attention of the developers! I’m sure something adjacent to this is being considered related to the issue of the annoying value==symbol name in libraries and the new database system for 7.0.
On the other hand, I already have to add at least 6 fields to every library I make (or edit) so it is just part of my process to load up kifields (a wonderful 3rd party plugin) and edit my libraries to have: military spec procurement number, associated manufacturer part number, engineering model manufacturer part number, engineering model manufacturer, description for flight part, description for em part… the list goes on. All of which to say, for my serious use-case, it doesn’t matter much to me that “value” is unclear semantically because all of the truly critical info appears in fields I will always have to add anyways.
The value has to be some awkward mix between searchable in symbol list and still useful as a label on the schematic, but that isn’t the end of the world for me (and hopefully will be separated from symbol name eventually!)
This is where careful design and lots of discussion and thought needs to be applied. I will insist that semantics are important in order to make this far more powerful than anyone could imagine today.
Just in case those reading my thread don’t know what I mean by “semantics”:
If I send you an email with the string “Px234Xy-66-32-ABCD-y” and provide no other information, short of a lucky Google search, it is impossible to understand what this means. If, on the other hand, I say something like: “Here’s the internal part number for this component: Px234Xy-66-32-ABCD-y” you know what it is and you likely know where to go get all of the information relevant to this component. This could be a bolt, nut, washer, spring, electronic component, PCBA or something else.
What I did there is tag (as is known in Machine Learning) the data with something that describes or provides extractable meaning or context to the data. This something provides the data with sufficient meaning to make it useful and do interesting things with it. In this case the tag can be reduced to “internal part number”.
If, on the other hand, I send an email with ten thousand such cryptic snippets, one per line, with no discernable pattern and not tagging. Well, it is impossible to derive any knowledge from such a mess. And, if it is, it will take exponential time to get there.
The overloading of a field named “value” to contain all manner of things creates such a problem. Because of this it has lost semantic meaning. I am looking at parts like resistors, capacitors and inductors placed from the stock KiCad libraries and there is, quite literally, no place to attach a semantically meaningful part number (of any kind, internal or manufacturer) to the part without adding a custom field. You cannot hand someone your BOM and order the parts. They would not know anything about the design decisions you made that are important to the design.
The value field is fine, but it should not be used to contain, well, values or parameters (resistors) in some cases and part numbers (IC’s, transistors) in other cases. This makes things complicated. As I said before, I can understand the historical nature of this design. No problem. However, going forward, I don’t think this survives unless KiCad’s mission is to remain a hobby tool.
The simple example I gave in another comment is that, when you search a distributor for “LM324” you’ll be presented with somewhere in the order of 80 different variants. You cannot just order any LM324. One of the many considerations is that some of the part numbers have five times the slew rate of others.
In a real design you need real part numbers that link to orderable components. These can be internal or house part numbers or manufacturer part numbers. When using internal part numbers you have to eventually link to a real manufacturer part number. I would not impose either one on users, but contextually, semantically, a value is not a part number and the KiCad library model and the way components seem to be handled within the program do not seem to cover this well.
If I add a custom “part_number” field to every single component it is still treated as an add-on, rather than the most critical bit of information that it represents for every component.
I think that’s the key point. If I give you a part number (manufacturer) you can get absolutely every single bit of information about that component with a simple Google search. That is all you need for anything except for cases where there might be some redundancies (same part number made by multiple manufacturers). In that case you have to provide one additional data point. That’s about it though, I can’t think of a situation where a part number and manufacturer does not fully describe a component and grant access to all relevant data, from specifications to inventory levels and pricing.
In other words, semantically, the part number is and should be a first class citizen and one that drives every single component in a design. This is why I am arguing that, while the value field is important and useful, it has been misused in the libraries to the point that you cannot order most components in them. You have to either add at least two fields (part_number and manufacturer) or roll your own libraries from scratch to include at least this information.
I can’t use stock libraries in my work. So, yes, every single component that goes into a design has to be created and vetted from scratch. The purpose of this discussion is to highlight something that I think is a problem with the way components are represented in KiCad. A new user looking at the kind of information present in a BOM created from the existing libraries could not order the parts required to build the circuit. That, I think, is a problem.
I highly recommend those interested to browse through some of Tim Berners-Lee’s writings on the development of the Web and the Semantic Web in particular. A tremendous amount of thought has been applied to this domain. Much of it translates very well to EDA. We work with information that is threaded in to graphs that have meaning in the form of a working circuit. Maintaining semantics from the component level all the way up to the schematic and PCB will unlock things we cannot possibly imagine today.
KiCad is unlikely to provide a “required” schema for additional part parameters (MPN, etc) in the official libraries. There are simply too many differing opinions on the right way to do so. We will instead be providing easier tools for people to set up their own systems that work for them (e.g. database libraries, easier ways of editing symbol fields, etc)
I think you’re writing as if adding a part_number is a controversial thing. It’s not. Overloading the value field is a hack; that’s also not in doubt; that’s historical baggage.
If you were able to create an extra field in the symbol library, with the understanding that this will have to be done in user maintained libraries, why would it be an “add-on”? It’s as good a field as any of the others. it can be used to pull in other information and generate BOMs, through post-processing (now), or through a database link (later). What is your definition of first class citizen? Be concrete, how exactly do you want KiCad to handle this field?
Not the intent. I don’t think any professional would suggest that having a part number is controversial. They could argue about such things as whether or not an internal or manufacturer part number is the way to go, however, I think in all cases the point is that a part has a 1-to-1 relationship to something you can actually order, stock, test, qualify, track, etc.
What I am suggesting here is that the standard KiCad library structure lacks this important field. Perhaps the most important of all.
Adding it manually or programmatically isn’t a problem at all. That’s not the point. The point is that it is missing by default when it should be present by default. I would add “part_number” and “manufacturer”. That would allow full specification of any component.
Those two fields can be linked to any external database or the web to find every single bit of data on any component. If “part_number” is taken to mean “internal_part_number” then “manufacturer” can be set to something like “self” or left empty. An alternative that would be better semantically might be “part_number_source” rather than “manufacturer”. In this case it could be set to something like “internal” or “Texas Instruments”. Once again, together providing a unique key used to find all necessary information on the component in question.
The current setup requires every KiCad user to roll their own solution when they realize none of the parts they put down on the schematic have an official spot to add a part number you can actually order (the value field is not that spot).
That’s the intent. I do want to hear from others before doing that. This conversation has been very useful. It is important for ideas and proposals to be challenged, and that is exactly what is happening here. This is what I wanted before wasting anyone’s time adding this as a feature request on Gitlab.
I do realize that there are varied sets of users here, from professionals to hobbyists. From trained EE’s to self-taught designers. This is great. All input is important. And, so long as everyone participates in the spirit of learning something and pushing forward ideas that will improve KiCad all discussion, disagreements and all, is good and necessary.
I’ll give it a few more days. This is also helping and forcing me to think this through some more and verbalize the request at the appropriate descriptive level. The summary post you suggested I publish to Gitlab is the result of these interactions trying to explain why this might be important.
I see the absence of a default house part number as an advantage.
It’s a clear indication that a schematic is not yet complete (for the database oriented people) and adding them in some automated way is a trivial task.
Trying the standardize the name of a “house part number” field is also never going to work in the real world. There are already lots of companies with their own names for this (or similar) field, and adding a “default name” for KiCad only adds clutter and confusion.
On top of that, there are vastly different workflows. If you already have a selection of prefered opamps, then by all means, choose one of them, but lots of people start with generic symbols, and then later refine it with more details.
This does open a window for errors to creep in. Not all opamps have the same pinouts, and more so for BJT’s etc, but being forced to choose some part instead of just typing some text where it suffices (for that moment) is a disruption of the creative process of designing a schematic. I once tried to use eagle, and I had a 0.2Ohm resistor in my hand and that *&^%$#@! program would not let me put it in a schematic, because it was not in the dropdown list.
I do see that such drop down lists can be an advantage. You first use a generic opamp during the initial draft, and when you fill in more details you select an opamp out of your companies database of preferred parts. But such a workflow should not be enforced for all users.
Then all users would either be forced to use that name for the field, or add a new field. I wouldn’t like “part_number”.
And what if a user wants to add several manufacturers/part numbers directly to the symbol? Again, they would need new fields anyway, and it’s not fair to other manufacturers to handle the first one as a special case.
At the moment KiCad has this in the Schematic Setup:
Something like this should be the solution, but it should be defined for KiCad setup, not just per project, and it may need more options for fields/values. Every symbol added to libraries should then inherit these fields (this Template seen above is a pseudo solution: it only shows the field in the project schematic symbols, not library symbols). It should also work when copying symbols from other libraries etc., not just for newly created symbols.
I agree with all your points. Your workflow isn’t very different from that of many professional EDA users. There are variants, but, as I have been saying, the part number (internal or manufacturer) is the first class citizen in all cases. As you mentioned, the end product --whether direct from schematics or after one turn of a crank through a script-- is a BOM with real world part numbers you can actually order.
I also agree that having piles of fields these days is largely unnecessary. Back 30 years ago this was deemed a good idea because local or network storage wasn’t quite unlimited and the web did not exist (it went public around 1993).
Today, so long as you have a GUID of some kind, any kind, it takes microseconds to learn anything you need to learn about that component. One could very well argue this is all you need.
If I can take a moment to drift into future-talk, I could imagine a system where the only thing that makes it into the schematic is this GUID and, perhaps a custom note or some other data that might be relevant. From there, the schematic editor would, in real time, access the component database to pull in other elements and display those you told it to surface to the visible layer. Just hovering over a component could show a bunch of information from the database on a heads-up-display of sorts or a status bar. Today we can definitely consider real time interaction with a local or network database in this manner.
Going back to reality, I think that anyone who uses KiCad for the first time should not be faced with ambiguities as to the meaning and where to place important information. Without getting into complex proprietary library or database structures, the bare minimum you need is (PK = Primary Key):
part_number (PK)
part_number_source (PK)
value (only for relevant components, blank otherwise)
footprint (a link)
3d_model (a link)
url (typically a datasheet (URL or local storage) or the manufacturer product page URL)
Strictly speaking only the first two are required. However, I am thinking about the “open box” experience for what I am going to call the unsophisticated user. This isn’t meant as a put-down, I would define it as someone who isn’t a professional or one that has never worked in a structured environment where these matters are carefully considered and managed. I’m happy to adopt a different term for this kind of user.
Anyhow, the idea would be that if all libraries shipped with KiCad contained the above parameters anyone using the software would be able to quickly go from schematic capture to PCB layout, 3D visualization, BOM generation and manufacturing with minimal friction.
Every basic element you need is there. The “part_number” and “value” fields could be treated intelligently or manually in the software. By this I mean that, if, for example, I leave “value” empty, I must mean that I want to show only the part number (as is generally the case for an IC).
There is no case where the part number is left empty. If we are talking about generic components, the part number could be something like “generic_quad_opamp” or whatever. Part numbers have to be elevated to first class status.
Right now, today, if I were to look at KiCad as an unsophisticated user, there’s a moment of confusion when you can’t get from a schematic using stock library parts to a BOM you can order and a PCB you can layout. The BOM part fails because the semantic (and GUID) concept of a part number simply does not exist in the specification.
If I can take a moment to drift into future-talk I could imagine a system where the only thing that makes it into the schematic is this GUID
I hope this dream doesn’t come true. This would be good for your described workflow, but for many others this would be a backstep/nightmare.
To be serious: up until now I have seen no convincing reason (in this discussion) for adding additionally mandatory fields. Let every user/company add the MF/MPN (these are my field numbers) as they wish - this is the current situation, it’s flexible and everyone can extend it for their own needs. But I would never force every other user to use my MF/MPN-field names. Maybe they want it written-out, maybe translated to their language.
For simple tasks and education it’s even completely unnecessary. With adding such features as mandatory the software may “step up” and compete with higher-end software (someone mentioned altium + mentor). But not every user wants I full featured cad-system (another discussion-theme).
The higher-end systems tend to be very flexible rather than having mandatory stuff, because every company wants something different and if your software can’t adapt to the company’s desires, you lose a sale.
Yup, that’s been my experience, whether it was working for a large aerospace company with 3,000 engineers or my own business. In many ways this is the most important task in any design; uniquely identifying and qualifying your parts. Once that’s out of the way you can focus on the design.
One of the neat things about the movement KiCad is becoming is that a lot of people are learning through it. Encouraging good, solid and safe workflows, is, in my opinion, very important. A lot of EE students are now going to come out of school having worked with KiCad exclusively. KiCad could encourage adoptions of good habits and workflows before they enter the workforce.
Looking even beyond that, I can see it becoming the dominant world-wide EDA tool over time. This, again, makes almost enforcing some base-level uniform workflow important. That does not necessarily mean making it so rigid that professionals could not integrate it into more advanced workflows. I think it does mean that the out-of-the-box experience has to be based on a solid approach that’s easy to learn and use by everyone, professional or not. Right now, I think it is kind of messy.
Here’s what I think our path will be:
We just started migrating to KiCad after, I don’t remember, 20 years of Altium Designer and another two decades of other stuff (including doing PCB’s with AutoCAD in the early 80’s). What we are talking about doing is sticking with a version of our database-driven parts library and writing a Python application that will extract these into KiCad symbol and footprint libraries based on the current format.
What this means is that we never want to manually edit the KiCad libraries. They should all be generated automagically from our database. We will likely use SQLite or PostgreSQL for this purpose and create a browser-based management front end with Django.
At a more advanced level we might be able to use the Django application to search for components and drive KiCad to place them from the auto-generated native libraries.
This approach would allow us to make part numbers the first class GUID they need to be and let KiCad be KiCad.
I did this kind of thing way back before Altium Designer, when we were using P-CAD. This, along with custom automated component generation tools had a huge positive effect on our productivity. I believe I can repurpose a bunch of that old code to make it play nice with KiCad today, which would be fantastic.
This is about semantic value rather than picking a specific name for the field. Everyone understands what I mean when I say “part_number”. This could be an internally made-up designator, a manufacturer part number or whatever. The point is, nobody would mistake “part_number” to mean “value”.
As for your very valid point that there might be preferences in naming fields, this isn’t intractable. I speak several languages. I can’t think of any one of them where the translation for “value” and “part_number” means something different. KiCad could easily provide an alias definition such that, if you’d rather see “my_special_code” or “identificacion_de_componente” rather than “part_number” that’s what you’ll see.
What matters here --and the entire point of my thread-- is to understand that semantics matter. What you call the tag is unimportant so long as the meaning it conveys is uniform within the category it covers.
Of course, there is such a thing as adding too much convolution and complexity. In my opinion this is where Altium Designer has gone. From some perspectives it is a real mess, to the point that every time they release hot fixes they break five new things. This is what finally got me to decide we were going to stop sending Altium money and move to KiCad (6.0 made this decision easier).
So, yes, careful about not introducing unnecessary complexity. That said, over-simplifying is a terrible idea just the same. Semantic overloading is never good.
I’m convinced you’re a serious KiCad user and I fully support your professional workflow, but assuming that any other workflow would be half arsed amateurish is short sighted.
There are plenty of companies who do not need or want an integrated database approach. There are people to select and test the parts before they are vetted. There are students who have to learn part selection. Projects get send to other companies for review and modifications. Companies go broke and projects get inherited and there are lots of other reasons why database connections can get lost or broken.
And all those “hobbyists” are a significant contributor to KiCad in lots of different ways. From small direct donations, ordering though companies such as Aisler, or even just by contributing to the forum or just using KiCad and spreading the word.
What you call a ridiculous workflow that invites expensive mistakes, I call flexibility to cater to different needs of different user cases.
I support the database approach, as apparently it’s important to the “higher end” of the market, but KiCad needs the flexibility to be approachable with a very low threshold of entry.
To take this to an exaggerated absurd level: If you had to start by creating a database of parts before you could even use KiCad, not many people would be using it.
Yeah sure, I understand.
But somebody has to draw the schematic symbols and maintain the database you are using.
So how do the parts get into your database?
Do you have people for that job or some other method?
I don’t think you are addressing me, but I fit the first portion of that description, so I’ll give you my opinion.
In another post I described how we think we are going to handle the current situation. We are going to write an application that will translate our database-driven parts into custom KiCad libraries and go from there. We will strive for never manually editing KiCad libraries at all. They will simply be a communications bridge between a database system and the EDA tool.
On the point about amateur workflows being shortsighted. Well, it’s true, pretty much by definition. I am an amateur when it comes to lots of things. I don’t know, dancing. If I was tasked with putting together a dance routine any professional would like --and rightfully-- think my workflow was shortsighted and maybe even silly. That’s with comes with being an amateur or a newbie. And that’s OK. Nothing wrong with that.
That does not mean that professionals should not make an attempt to guide newbies or engineering students towards good solid practices. It’s called learning. Everyone has to do it at some point.
I spent many years as a mentor for a local high school robotics team. Some of the kids came to the team having never drilled a hole in anything in their lives. You can either let them loose with the drill press to fend for themselves or provide some structure and guidance. The latter is the only way to help them advance to bigger and better things with minimal pain.
One of my favorite quotes by Mark Twain:
A man holding a cat by the tail learns something he can learn in no other way
Boy, have I lived that one!
What I think you are seeing here is a bunch of professional users (who do not necessarily have to agree on all points) noting that there are important issues that might benefit everyone if addressed in a sensible manner. Perfect? Never. That’s impossible. Better? Yes, that’s almost always possible.
My preference would be to provide a far more rigid scheme that would safely guide everyone through a more uniform workflow. The semantic issue with regards to the lack of part number information in the default data structures is, in my opinion, an invitation to create an absolute mess.
Of course, one should be able to turn off the out-of-the-box “Safe Mode” setting to roll your own. Lots of professionals will do just that. Lots of amateurs will do the same. There could be an “Expert Mode” that introduces interfaces to DB-based component management. And there could be an “Experimental” setting that let’s you explore within the bounds of what might be possible and wrap yourself around a post if things go wrong.
All of that would work fine.
My test would go something like this: Can I give KiCad to an engineering student who has never used it, tell them to create a minimal Arduino or RP2040 design from documentation (in other words, I actually give them a PDF of the schematic, nothing to invent) and have them walk away with a board they an manufacture and a BOM they can order immediately.
I don’t think that’s possible today. The library data structure, out of the box, only has “value” as a field that will get overloaded and muddled with stuff with different meanings. The bare minimum requirement is a part number you can actually order, the manufacturer and value when relevant. If you have these you can find everything else on the web. KiCad does not have this in the stock component definition. Just “value”.
These days this isn’t really high end at all. I mean, think about it. When you are reading and interacting with this forum you are working with a database. The user interface is what makes this simple or complex. Few of us could work with this forum if we had to type SQL statements into a console. When it comes to EDA component management “database” does not mean “complex”. In fact, it could be a lot easier.
I’ll given you and example of this that goes back to P-CAD days (before Altium Designer). We created a tool back then (early 2000’s if I remember correctly) that read an Excel file containing a list of all available resistors from a manufacturer, along with parameters, links to datasheets, vendors, etc. With one click and in a couple of seconds, this tool processed that data and created P-CAD/Altium component database entries for thousands of components, ready to use with qualified footprints, etc. After that nobody had to touch the database for anything. If you needed to add new parts all you had to do is append them to the Excel spreadsheet and re-run the tool for an update. Easy.
Imagine if amateur users could create parts in a database just by filling out a spreadsheet and then just use them after clicking a “Process” button. How is that complex?
That part isn’t hard at all. When it comes to such things as resistors, capacitors, etc, a lot of that work can be done parametrically and only once. Same with the symbols. For some applications (example: high vibration environments) you’ll have a family of modified footprints for the same parts to generate once and use multiple times. A database approach can very easily allow you to then choose from among multiple available footprint variants for the same part number.
The parts get into the database using software that provides a suitable interface to manage it all. When the KiCad team publishes the database-driven component specification lots of people will likely produce a range of interesting tools that will do just that. I would imagine KiCad will likely come with a minimally functional reference implementation as well.
If the UI is good databases are easy (and the right way to go).
Here’s a quick example of a tool we created a long time ago to create and maintain P-CAD (later to become Altium Designer) libraries from Excel source files. This, along with the Excel format specification made it so we very rarely ever touched component creation in P-CAD.
I remember the motivation for writing this. Creating the schematic symbols and footprint for a Xilinx XC2V-1000 FPGA with 456 pins was a nightmare in P-CAD. It took something like 16 hours (don’t remember). Even worse, if I decided I wanted to rearrange the banks on the symbols to better fit the schematic intent, it was hours of error prone pin dragging, copying and pasting and verification.
This tool (which took about three months to create), reduced creation of schematic symbols and footprints from hours to maybe 15 to 20 minutes, even for parts with 1100 pins.
The tool doesn’t look like anything special, but it was a game changer for us. When time permits I will likely dust off the source code and see about porting/adapting a better version of this for use with KiCad.
Here’s another app that allowed bidirectional transfer of information between P-CAD/Altium and Excel to facilitate editing an manipulation with other tools. These days I would likely favor a browser-based interface driven by Python/Django.
A possible benefit of KiCad providing a part number field as one of baked-in component fields is standardization of that field’s name. As it is, every plugin that deals with part numbers can (and often do) have their own field name. “Part No.”, “Part_number”, “PN”, etc. If this were standardized then all the plugins that deal with part numbers can access the same field.
Now, of course, while solving the non-standardization of the name may cause different problems as the afore mentioned plugins might be wanting to use the part number field for different purposes. One might want to use it for internal numbers, another might want to use it for manufacturer numbers, yet another might want to use it for DigiKey order numbers.
I guess the question is where the implementation collisions should be?
Using the term “professional” to divide users to two castes, those who know and those who don’t (how things should be done), and then implying that “professionals” do things in this way and not that way, is insulting. A professional is a person who is skilled at something and does it (usually) for money, but it doesn’t tell anything about how they should do it. A real professional may decide that he doesn’t need a database. From reading this forum I have noticed that many who consider them to be professionals are accustomed to some company workflows and only certain kinds of products (which they make) and start to think over time that everyone must do it the same way. Maybe they even think derogatorily about small companies which have other needs. I have seen even KiCad developers saying that they have never seen some feature needed by “professionals” (and I have objected). I wonder why; I would have needed a feature and I was designing some PCBs as part of my job. Maybe they just have never needed to do that kind of design.
So, either way, saying that real professionals need something, or that they don’t need something, is not very “professional”.
In real life most small companies, especially one man companies, are professional enough to know how things should ideally be done, but they can’t afford it (in time or money, usually both, and time is money). Thinking that KiCad needs certain things to be taken seriously by “professionals” or “in the industry” is just plain stupid. “Big corporate environment” is not identical to “professional”. Probably great majority of potential future users of KiCad are not in big corporations who can afford $$$$ seats for their EDA using engineers.
