Not sure where you got that I am saying the value field has to go. I don’t think I said that anywhere. To be clear: This is not what I am saying.
What I am saying is very simple:
“value” does not mean “this is what you order to build this circuit”
“part_number” means “this is what you order to build this circuit”
If you use parts from the KiCad libraries as they are, you cannot order almost anything because you do not have part numbers. The value field is necessary and relevant for a great number of components. And yet, it does not give you a part number you can enter into Mouser and buy.
The semantics are wrong.
We can’t think in terms of now. We have to think in terms of the future. 5, 10, 20 years from now. Semantics is important. Imagine, if you will, someone creating an AI-based tool to interact with part libraries and databases. In this case semantics gains vital importance. Mixing-up values with part numbers and other parameters would result in a mess that might compromise what could be possible.
This is why HTML has tags. Semantics. They have meaning. You don’t use a
tag for an image. I’m sure people do in some ways, yet all they achieve is a destruction of the semantics the language enables.
We need part numbers to be first class citizens, not relegated to “you figure it out or just put it in the value field”. And, yes, we also need the value field…for values.
What are we (my company) going to do? We are creating new libraries where every single part (symbol, in KiCad terms) is named as a part number you can order, for example, “LM324F-GE2”. Every part will have a part_number field. Both the part_number and value fields will be populated with “LM324F-GE2”.
Components like capacitors will be different. There will be a “LLL152D70J105ME01D” part (symbol). The part_number will be the same. The value will reflect the component’s value, “1 µF, 6.3 V, 20%”.
Other fields will cover additional parameters of interest, for example, min and max operating temperature and inventory counts.
We want to (need to) maintain semantic meaning in the database/libraries because this enables other work that relies on reliable encoding of meaning.
This is important. I know a lot of people (most?) never studied database theory or have written machine learning applications. From this context clean classification and proper adherence to the most important database theory concepts is very important.
Fine, we are in violent agreement then. But see the other thread asking when databases will be connected. It all depends on developer effort, and this is where the scarcity is. But yours seems to be a simpler issue, i.e. argue for a standard field called say part_number, to be added to symbols. Then you can make private copies of all the standard libraries and popualte that field. That might be sufficient until that field gets connected to databases.
And that might very well work in your reality. In mine, I cannot send an RFQ to a vendor asking for price on 250,000 transistors with a gain greater than 20. That’s a specification that can go in a comment or a custom gain field for transistor types. That is not a value. And that is not a part number.
Something like that would get someone written-up or possibly fired (if they insisted on it and did it all the time).
Maybe the difference here is one of context. In my context part numbers are not optional. No design is finished, goes to purchasing, manufacturing or testing until every single part number is fully specified, verified and vetted.
I don’t think kicad needs to update the semantics here as there is a very open way to deal with components however you like. The best way to save part numbers constantly in an extra field so that they get added with adding them to the schematic is in my opinion to create custom libraries with this extra field. the custom libraries are also discussed here: Advantages of working with custom saved Symbols only
I have to disagree on this. The value field is not being used as part-number if that’s not what you put in there? You are free to put the part-number wherever you want.
Personally I don’t want the Manufacturer Part Number anywhere near the schematic. However, I want the symbol Name to be our House Part Number. That way the symbols are indexed “correctly”. I would hate getting a list of actual values when browsing for symbols. And I don’t want redundant information so I don’t want to add the HPN in both the Name and product-number field.
Unfortunately value=name in the symbol library. This however is not the case in the schematic. Personally I would like the ability to set the value to something different than the name in the symbol library. But then I would also need the ability to show the name in the schematic.
The Value field is a historic remnant from days that KiCad was simpler (KiCad is now about 30 years old) and it’s quite useful for resistors and capacitors.
It is inadequate for a database driven design, and KiCad is likely to move into that direction for KiCad V7.0
I’m not sure how to use the value field in a database driven design.
You don’t want to clutter the schematic too much with irrelevant information (Resistor 1k2 5% 0603, generic manufacturer) but for some of the parts you want to add extra information, such as precision resistors, or fusable resistors.
It’s also possible to design the UI to make that table sorted by another field or even combinations of fields. So if you want it ordered by HPN, then click on the sort arrow above the part_number field.
will change the fields of your current schematic, however if you will be needing the same information on all your schematics, it can be done with as explained in the following tutorial (it is a very old tutorial, so not everything is exactly as described, but it helps to get started)
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.
