Semantic problem with KiCad component treatment?

[robomartin]

I am thinking of raising this as an issue. Before I do that I would like some feedback.

The following is a small section of the XML file for a schematic:

   <comp ref="TP4">
      <value>TestPoint_SMD_2.0mm</value>
      <footprint>TestPoint:TestPoint_Pad_D2.0mm</footprint>
      <libsource lib="Connector" part="TestPoint_SMD_2.0mm" description="test point"/>
	  ...
    </comp>
    <comp ref="U1">
      <value>MAX17632AATE+</value>
      <footprint>Package_DFN_QFN:TQFN-16-1EP_3x3mm_P0.5mm_EP1.23x1.23mm_ThermalVias</footprint>
      <datasheet>https://datasheets.maximintegrated.com/en/ds/MAX17632.pdf</datasheet>
      <libsource lib="Regulator_Switching" part="MAX17632AATE+" description="4.5V to 36V, 2A, High-Efficiency, Synchronous Step-Down DC-DC Converter"/>
	  ...
    </comp>
    <comp ref="C8">
      <value>0.1 uF</value>
      <footprint>Capacitor_SMD:C_0402_1005Metric</footprint>
      <libsource lib="Device" part="C" description="Unpolarized capacitor"/>
	  ...
    </comp>

I have removed a few lines that are not relevant to this discussion. This is indicated by "...".

The listing shows three types of components:

• A PCB test point fabricated purely by etching the board (not a real part you purchase)
• An integrated circuit (MAX17632AATE+)
• A capacitor (C8)

The question is: What part number do I order?

Well, the test point should not be ordered. This is easy to manage in the schematic by turning off inclusion in the BOM. No need to discuss ordering this part.

In the real world the integrated circuit does not have a “value”. The capacitor does. However, they are both identified by the <value> field. There is no place for a real part number in either part. The capacitor consumes the <value> appropriately. If I wanted to have an orderable part number I would have to do one of two things:

• Add a custom part_number field to every component
• Create a new library where every single part is named using the orderable part number

This is where I think there’s a semantic problem in KiCad. The <value> field is being used for <part_number>. Value does not mean part number and it confuses and complicates things when dealing with the BOM.

This would be no different if we also decided to encode no-place into the value field by appending something like “NP” to the value rather than having a dedicated --and semantically correct-- field, as seen in the schematic file source code:

  (symbol (lib_id "Connector:TestPoint_SMD_2.0mm") (at 93.98 104.14 0) (unit 1)
    (in_bom yes) (on_board yes)

Here in_bom clearly conveys the semantics and does not misuse the value field.

In short, I think KiCad needs a semantically correct part number field. This is, and perhaps a GUID could be used to link to a future database-driven approach to libraries.

[retiredfeline]

Value field should be left alone. If you change the semantics of that you mess up all those PCBs where the component value is on the silk screen.

What so difficult about adding a part number field? When I wanted to try PCBA by JLCPCB I added a field LCSC in the project settings, then used the Field Editor to to populate this field for the components I wanted placed and soldered. Then I used a JLCPCB specific converter script to copy the field contents into the BOM.

No need to edit any symbol library. I would have to make my own copy for a writable library.

In future you could imagine a UI that would let you do a parametric search to add the part number based on what’s suitable and available in the database you use.

[robomartin]

@retiredfeline

What so difficult about adding a part number field?

For one board with a few dozen components. No big deal.

As a plan going forward. Manually adding a new field to every single part is a bad idea. The parts need to make it onto the schematic ready to go. Adding fields by hand at the schematic level is a formula for disaster. To be consistent one would have to add this field to every single part.

BTW, the value field can stay just that. A semantically correct part_number field would be an easy path for a future upgrade (7.0). Old designs should not break if done correctly.

The point is simple value != part_number. Overloading value isn’t a good idea.

Right now I am looking at a simple board that is a mess because the BOM has no useful (orderable) data for dozens of components. Yes, to expedite completion of the board I will go in and manually add a part_number field. If I have to do this for boards with hundreds of components multiple times per year, well, as much as I might hate to do so, I might as well go back to Altium Designer.

This data must be contained in and managed by the libraries, not at the schematic level. Hobby electronics. Sure. Anything goes. That’s not my use case at all.

[retiredfeline]

@robomartin

The point is simple value != part_number. Overloading value isn’t a good idea.

Neither is taking it over for another purpose (officially). You may of course like some people have done and put a HPN in there. But why the parsimony? It isn’t a big deal to have more fields as long as they don’t encode redundant information.

@robomartin

This data must be contained in and managed by the libraries, not at the schematic level.

No developer working on KiCad has the time to maintain an ID space for parts. It’s busy enough looking over library contributions. This rightly belongs in the database, not the library. Adding it in the schematic is a workaround for now that demonstrates that an extra part number field can be used to access other attributes of parts.

If you are simply saying that the symbol could be augmented with an optional part number field, just as some symbols have default footprints, that’s not impossible, it may be already in the plan (I don’t develop so I don’t follow any discussions). But users/organisations should populate this with whatever ID scheme they use. There’s no need to take over another field for this. You should argue from a position of abundance, not scarcity.

[robomartin]

@retiredfeline

Neither is taking it over for another purpose

Not suggesting that at all. If you think about it, parts that require a real value field (resistors, etc.) need a place for a real part number. That would be covered by a semantically correct part_number field.

Components that have no need for a value field can continue to use value for the part number and also populate the part_number field. Yes, this would duplicate that data, but it isn’t a big deal.

@retiredfeline

This rightly belongs in the database, not the library

I have been using “library” and “database” interchangeably. They are both databases, of course. I prefer the kind that is based on a real database engine managing it all.

@retiredfeline

But why the parsimony? It isn’t a big deal to have more fields as long as they don’t encode reduncant information.

Don’t get me wrong. I need over a dozen fields on every part. No issues there at all. This isn’t about skimping. This is about semantics. For example, nobody would ever think of storing the number of parts you have in inventory in the “value” field. Let’s say we are talking about an IC. Don’t need the value field. Let’s use it for inventory count. Well, that would be a terrible idea because meaning, semantics, is important. There should be an quantity_in_stock or inventory_count field. This carries and conveys the proper meaning. Just like part_number does and value does not.

[retiredfeline]

@robomartin

I have been using “library” and “database” interchangeably.

In KiCad discussions library has a specific meaning, namely the symbol, footprint and 3D model libraries which are supplied by the KiCad packages, and read-only. User can create their own libraries of course.

@robomartin

If you think about it, parts that require a real value field (resistors, etc.) need a place for a real part number. That would be covered by a semantically correct part_number field.

Not just resistors, but also components like ICs. A logic inverter symbol could have many implementations in many technologies. It could be any of a number of chip models. To replace that with a part number loses information for the reader of the schematic. So leave the value field alone, and create a new part number field.

[robomartin]

Not necessarily. The part number is very important. For example, an LM324F-GE2 has a slew rate of 300 mV/µs, whereas the LM324LVIDR slews at 1500 mV/µs. You can’t just show “LM324” on your schematic and end-up with a working circuit. Even worse, you might have a need for both types on the same schematic!

If you look at something like an LM324 op amp. This is the symbol name and the value. Yet, you can’t order an LM324. A quick Mouser search reveals 88 LM324-type op-amps:

https://www.mouser.com/c/semiconductors/amplifier-ics/operational-amplifiers-op-amps/?q=lm324

The part number you might have selected and need to order might be “LM324F-GE2”.

OK, where do we put this? Do we now add a “part_number” field to the LM324 part and populate it with “LM324F-GE2”. So the value --and the schematic-- read “LM324” and the part_number is “LM324FVJ-E2”. That’s not good. Formula for disaster.

What you want is a fresh new cloned part with both a value and part_number set to “LM324F-GE2”. That’s what you order.

This is mostly about issues with things like passives. We don’t usually like to see something like “LLL152D70J105ME01D” on a schematic next to a capacitor. This makes no sense. The part number makes no sense. We want to see the value. This could be something like “1 µF” or, if more detail is useful, “1 µF, 6.3 V”. If a tight tolerance component is important, we might need to add a percentage value to this. From a database normalization perspective each of these parameters should be in a separate field (capacitance, voltage, tolerance, etc.). Well, nobody does that. Or, at least, few people do this. Value is it.

And yet, you can’t order a “1 µF, 6.3 V, 20%” capacitor. Most non-hobby projects rely on tested/selected/qualified components. One can’t pick them at random. When I work on designs for aerospace applications, every single component that goes on the board has been through one or more levels of qualification. The schematic might say “1 µF, 6.3 V, 20%”, but I can’t pick any random part I want. So, the part number, “LLL152D70J105ME01D” must be in a field, visible or not, and in the schematic.

Furthermore, I need my libraries to only have parts I can order rather than generic “LM324” type parts that are great to throw together a quick schematic or a hobby project, but are rarely useful in professional applications.

Semantics is about meaning and it is important. “Value” does not convey the meaning we are after, at all. The fact that the KiCad libraries throw part numbers into the “value” field makes it pretty messy.

Not sure why this was a design decision other than to think that in the early days of this project none of this was important at all (which I fully understand). Now with professionals wanting to use KiCad some of these questions will be raised by many and from different perspectives.

The job KiCad developers have done and continue to do is nothing less than amazing. I offer my commentary and thoughts constructively. I want to see KiCad go very far. We intend to contribute to the effort both financially and with development when the time comes.

[retiredfeline]

But LM324 may be sufficient for a certain level of understanding of the circuit. It all depends on the audience. It’s not different from passives. Even passives could have a lot of detail. Maybe you need a 5W resistor in that position. Do you really want to encode wire-wound, etc. in the value?

As I said, there’s no need to get rid of the value field. Having both a value field and a part number field gives you more flexibility. You can always choose to not display one or the other.

The issue here is who does the work. When and if support for an optional part number as a standard field for symbols has been coded you can have your own copies of the library (the standard KiCad meaning) and put your part numbers in there. However part numbers are more volatile than symbols so they are more suitable to being in a database which the user can populate.

There are other workflows which some users could use. Perhaps I want to just put the value into the field (4k7 or 2N3906), and the footprint (0603 or TO-92) and do a search through the database or the supplier’s database to fill in the part number field. Perhaps I know the part number by heart because I’ve used it so often and I want the other fields to be auto-populated from the DB. Perhaps I get a partial match and want to select from a list. Don’t close off other workflows by changing the meaning of the value field.

[jmk]

“Value” is a bit of a misnomer.
That field should really be “Name”.
10K is really a shorthand version of “Ten thousand ohm resistor”, but “Name” would be confusing as industry calls resistors and capacitors by an abbreviation.

Maybe “Value/Name” to keep 10K, 100n & LM324 all happy???

[retiredfeline]

I’ve done things like put “Gain > 20” for the Value of a generic transistor. No name for this field will satisfy everybody.

[robomartin]

@retiredfeline

no need to get rid of the value field

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.

[retiredfeline]

@robomartin

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.

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.

[robomartin]

@retiredfeline

I’ve done things like put “Gain > 20” for the Value of a generic transistor. No name for this field will satisfy everybody.

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.

Values are not part numbers.

[retiredfeline]

@robomartin

Values are not part numbers.

Of course not, but you muddied the waters by bringing in the value field. You want a part_number field, plain and simple. No argument about that.

One could even be more pedantic and note that it’s not necessarily a number. It should really be called part_id or something like that.

[Tojan]

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

[jmk]

[albin]

@robomartin

This is where I think there’s a semantic problem in KiCad. The <value> field is being used for <part_number>. Value does not mean part number and it confuses and complicates things when dealing with the BOM.

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.

[paulvdh]

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

KiCad: The case for Database driven design

For this I neither like the idea of baking in a single user (writer) interface from the start, nor committing to a particular database format. This database driven design is mostly for bigger companies, and it’s quite likely they already have some other PCB design suite and an elaborate database with their preferred parts in place. So I agree wit retiredfeline to define an agnostic interface combined with some reference implementation. Also, as an Open Source project, there are already a lot …

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.

[retiredfeline]

@albin

However, I want the symbol Name to be our House Part Number. That way the symbols are indexed “correctly”.

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.

[der.ule]

The way @jmk depicted here

Semantic problem with KiCad component treatment?

[ksnip_20220503-181730]

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)

KiCad BOM Management Part 1 - Detailed Components