How to assigning real part numbers to components?

Schematic
1

I just got done with a design and need to assign part numbers and footprints to a bunch of components before starting layout.

When I extract the BOM I get something like this (excerpt):

C10, C18,   2    2.2uF   C        Capacitor_SMD:C_0402_1005Metric
C19,        1    100n    C        Capacitor_SMD:C_0402_1005Metric
C20, C21,   2    27p     C        Capacitor_SMD:C_0402_1005Metric
R5,         1    10K     R_US     Capacitor_SMD:C_0402_1005Metric
R6, R8,     2    27      R_US_2   Capacitor_SMD:C_0402_1005Metric
R7, R9,     2    1k      R_US     Capacitor_SMD:C_0402_1005Metric

What is the KiCad approach to entering the proper part number for these and the other parts that need orderable part numbers?

As I understand it, the component name field corresponds to the symbol name. This means I would have to create a new symbol in the library with the orderable part number and substitute every instance on the schematic.

For example, RT0603FRE07130KL is a part number you can order from Digikey. It’s a Yageo thin film resistor, SMD, 1/10W, 130K ohm, 1%, 50ppm.

How do I assign a real part number to the relevant resistors in the schematic that are currently listed on the BOM as “R_US”?

Does this require adding a custom “part_number” field to every component in the schematic? I guess that also means I have to edit the BOM generation code (python) to then include this custom field?

1 Like
2

Yes, you can add an extra field on a per-project basis. For instance in one project I have a field LCSC which contains the part numbers in a PCBA job by JLCPCB. The BOM generation script for JLCPCB then reads and outputs this field. There are plugins like KiBoM that are configurable to generate BOMs in various formats wanted by the assembly houses.

In some future version hopefully 7, there will be a connection to a database where parts can be elaborated. Then BOM generation scripts can have a field (hahaha) day.

1 Like
3

So, there’s no official KiCad part number field then?

I guess the alternative is to create symbols with the correct part number rather than “R_US”.

Adding a custom “part_number” field to every component is a bit of a pain.

I am trying to understand where the component name comes from in the BOM. Looking at the relevant portion of code:

    # Fill in the component groups common data
    out.writerow([refs, len(group),
        fromNetlistText( c.getValue() ),
        fromNetlistText( c.getPartName() ),   # Where does this come from?
        fromNetlistText( c.getFootprint() ),
        fromNetlistText( c.getDescription() ),
        fromNetlistText( c.getField("Vendor") )])

When I look at the schematic file, I don’t see a PartName property:

  (symbol (lib_id "Diode:1N4148WT") (at 101.6 116.84 270) (mirror x) (unit 1)
    (in_bom yes) (on_board yes) (fields_autoplaced)
    (uuid 3343ada6-22a5-4c8a-adf2-4e12a5d6198f)
    (property "Reference" "D3" (id 0) (at 104.14 115.5699 90)
      (effects (font (size 1.27 1.27)) (justify left))
    )
    (property "Value" "1N4148WT" (id 1) (at 104.14 118.1099 90)
      (effects (font (size 1.27 1.27)) (justify left))
    )
    (property "Footprint" "Diode_SMD:D_SOD-523" (id 2) (at 97.155 116.84 0)
      (effects (font (size 1.27 1.27)) hide)
    )
    (property "Datasheet" "https://www.diodes.com/assets/Datasheets/ds30396.pdf" (id 3) (at 101.6 116.84 0)
      (effects (font (size 1.27 1.27)) hide)
    )
    (pin "1" (uuid cc6dfe6c-2682-437b-b21c-d3c16a16c093))
    (pin "2" (uuid ffa524dd-637b-43a1-bcce-8e479927d169))
  )

The XML file section looks like this:

    <comp ref="D3">
      <value>1N4148WT</value>
      <footprint>Diode_SMD:D_SOD-523</footprint>
      <datasheet>https://www.diodes.com/assets/Datasheets/ds30396.pdf</datasheet>
      <libsource lib="Diode" part="1N4148WT" description="75V 0.15A Fast switching Diode, SOD-523"/>
      <property name="Sheetname" value="Power"/>
      <property name="Sheetfile" value="Processor Power.kicad_sch"/>
      <sheetpath names="/Power/" tstamps="/02ab9e83-b6ac-4ce5-9d19-df0ae2667345/"/>
      <tstamps>3343ada6-22a5-4c8a-adf2-4e12a5d6198f</tstamps>
    </comp>

I am guessing it is getting it from this line:

      <libsource lib="Diode" part="1N4148WT" description="75V 0.15A Fast switching Diode, SOD-523"/>

In the case of resistors and other similar components, I guess there’s no way to modify this other than to actually create a symbol with the desired part number in a library.

How do I do this with an existing schematic? It sound like I have to go create every single part and replace them.

4

No it shouldn’t be KiCad’s responsibility to maintain part numbers. There are so many formats. Have a standard field for it, yes.

Just assume there will be a field called part_number and if it is officially something else do a global replace.

Just add a field in the setup and edit the symbols, no need to redo the schematic.

BTW there are other BOM generation scripts in the examples (I think, not at computer now) folder which are not installed by default which might be closer to what you want.

5

Sorry, I didn’t do a good job there. I didn’t mean that KiCad should provide libraries with every conceivable part number.

What I meant is that I should create libraries with part numbers for the symbol names rather than using generic “R_US” symbols.

Years ago I wrote custom software to do this kind of thing for our Altium Designer libraries. For example, we have a library that contains every single Panasonic 1% SMT resistor. The library contains one symbol that all resistors reference. It also contains all the relevant footprints (it’s an integrated library). When you use that library you search based on the values you need and then select a part. It goes on the schematic as a unique part number, ready to order right from the BOM.

The equivalent KiCad approach would require two separate libraries, one for the symbols and a separate one for the footprints. The symbol library would have one symbol per part number and use a common reference to a generic “R” symbol for all of them.

If I had these libraries the schematics would instantly produce orderable BOMs without any additional fields.

So, the question is: Add a “part_number” field to every single part or take a detour to create more useful libraries.

Adding a “part_number” field manually for every single design from here on isn’t sustainable. Lots of room for pain and suffering.

I read somewhere that database-driven libraries might be in the works for 7.0. I think this would be a good thing.

Of course, this is the perspective of professional users. I don’t think there’s anything wrong with KiCad for hobby/educational use. That user base doesn’t have the same rules and constraints one is guided by in production environments.

I am trying to leave Altium Designer behind. I’m just sick of it after a couple of decades of use. Just trying to understand what the best path might be with KiCad.

1 Like
6

There’s no need to replace the R_US field, you can have as many fields you like and they will be available for transformation. R_US actually refers to the graphic symbol so it should be left alone. The output is XML so the schema can flex. The things missing are: a standard name for the part number field, the connection to a database (agnostic of course), the UI to populate this field, and the user maintained database contents.

Also you add the part number to designs, not to the library so you don’t have to do all your parts in one go.

7

Well, I guess my point is that the only way I can have orderable part numbers in the schematic is to manually add a “part_number” field to every single component. In this case it’s about 120 of them. I might be able to write a python program to at least add the field. Not sure.

When you have a library where every single part you pull in is named with the part number, there is no need for an additional field.

In the long run, manually adding a “part_number” field to every part you place simply isn’t sustainable. I would not want to do this with some of our boards that might have over 800 components. The data has to come from the library, one way or the other.

You can have a library with 1000 resistors that all share the one and only resistor graphic. Each one of them is named with the part number you can actually order. That, I think, from my current perspective, is the better long-term sustainable path. A library like that can be generated with code. I did exactly did for Altium over a decade ago.

8

I totally agree with you. The way we’re doing it is by only using our own custom libraries and setting the Value field in the symbol to our internal House Part Number. Our HPN is defined in a way that we can easily see what value a passive component has if it points to a passive component. Therefore we don’t bother with adding a real value (i.e. “100nF”) to the symbol.

Our schematic only show the reference and our HPN. When the design is done, we export a BOM with the references and HPNs, and upload it into a database system we’ve developed ourselves. Here the HPN has a description one or more Manufacturer Part Numbers and one or more datasheets or other documents tied to it. Only from the database system can a full BOM be exported to the manufacturer of the pcb.

One huge benefit with having HPN instead of MPN is that we can change to a different MPN without editing all our schematics.

You can of course use the Value field as intended (setting it to i.e. “100n”) and add your own field for a MPN or have your HPN in a custom field. One of the benefits with having the HPN in the Value field is that the symbols are always sorted by the Value field when adding new symbols to the schematic or when editing symbols in the editor. For me it’s much easier to find the correct symbol by the HPN than by a value such as 100n.

As I said, we have our own database system, but there are several alternatives here. I haven’t tried any of them, but I’ve heard of:
GitPLM
PartKeepr with KC2PK to help with KiCad integration.
InvenTree with Ki-nTree to help with KiCad integration.

You are correct in your assumptions here. It should also be worth mentioning that in the Symbol Library the Name and Value is always the same. After the symbol is added to the schematic, the Value can be changed but the Name is always a reference to the Name in the library.
Here is a long discussion on this matter.

When you’ve created your personal libraries with the HPN or MPN in a field of your choice, you can update your schematics by right clicking on a symbol and choosing “Change Symbol…”. In this dialog you can (if you want) change all symbols with a specific Value to a new symbol of your choice. Just select “Change symbols matching value”. That way you don’t have to do it for every single symbol, but “only” for every single unique value."

image
image641×674 18.7 KB

9

Agreed on all points.

Encoding values into the HPN can be tricky though. I wonder, how far do you go? For example:

100K, 1%, 0.1 W, 50ppm
or
1 µF, 6.3 V, 20%, X7T

Many decades ago I learned in database management class that complex encoding of what should be separate fields into a key field is a really bad idea. While this is something I violated many times over the decades that followed, it has always remained in the back of my mind. It always comes to the forefront when I am contemplating a large DBMS project.

The last thing you want to do is come up with a brilliantly complex encoded identifier and, a few years later, discover it wasn’t enough.

As a side joke: I always say this is the reason German component manufacturers have some of the most horrific part numbers in existence. They seem to want to encode everything into the part number, which, 64 characters later, becomes impossible do decode by a mere human.

How are you future-proofing your HPN’s?

10

I agree. One should not fall into the trap of trying to add every single parameter to the HPN.

In our case we have a letter for type (R for resistor, C for capacitor and so on), then we have a 3 digit “series ID”. R001 essentially means a resistor in a 0603 package with 1% tolerance and otherwise standard parameters. Last but not least we have a value which could be 4k7. End result is R001/4k7. One quickly learns the “series IDs” of the most usual series, such as 0603 and 0402 resistors and capacitors. In case the component doesn’t really have a value (an IC circuit, transistor or such) we simply put in “1”. This can be followed by “2” if another transistor fits into the same series. This is not specified that hard and we’re not always that anal about it. So a transistor can be called T001/1 and that doesn’t really say anything.

I understand if this makes very little sense to people but for us it’s a reasonable compromise between having some information in the HPN and not having to long HPNs. I believe that it’s sort of the same question as to “How much information to put in the schematic?”. Do you only set the value to 100nF or do you want the schematic to include 0603, 1%, 16V, X7R as well?

Having the “value” of resistors, capacitors and inductors (also color of LEDs) in the HPN has the benefit of not having to specify the Value in a separate field. I want the HPN to be clearly shown on the schematic (I know many want’s to hide it). That way it’s much easier to find the component information when someone at repairs looks at the schematics and want to know what component they’re looking at. Otherwise they would have to look up the Reference in the BOM.

Not really sure what you mean. Maybe I’ve already answered it?

T001/1 can have multiple MPNs tied to it, and when one goes EOL we simply add another if an equivalent can be found.

11

I know people treat schematics differently. And, yes, there’s a limit to how much it makes sense to put on there. In general terms, you are trying to communicate with an engineer (or a technical user) who might have to manufacture, test, modify, repair or understand your design without the benefit of you being there to explain it. This means highlighting what’s important and leaving the rest for the BOM and documentation.

Back nearly 40 years ago, when I was getting started in electronics, every piece of equipment I dealt with came with full schematics in a service manual that often described circuit operation and repair procedures. The full BOM, with manufacture part numbers, was a part of that as well. I remember spending 18 hours repairing a 1500 W Hewlett Packard switching power supply…a monster of a design without the IC’s we have today.

Fast forward to today, when virtually nothing ships with schematics. This means their meaning an utility is limited to manufacturing, testing, design iterations and maybe, just maybe, repairs (rare in most domains). This affects what information must be visible on the schematic vs. stashed away in the BOM or elsewhere.

I guess the point is that this depends on the design and the company.

12

From a current thread (That also links to gitlab)

14

I remember spending 3 days on reverse engineering (about 1982) the schematic of wheel balancer and then 3 days trying to understand how it is working without the IC’s we have today (I got only PCB without knowing what is connected to its signal inputs, its power inputs, its controlling connections and its outputs). I had to do some assumptions - for example I assumed that here it gets 50Hz signal that is used to recreate from samples saved at capacitors the amplitude and phase of wheel vibration after wheel is stopped to show at analog indicators what weight and where to put on the wheel.

Using Protel 3 I made my way of generating BOM. We decided that each symbol value means for us specific part. I used OpenOffice spreadsheet to convert BOM obtained form Protel to real elements list (database at one tab, BOM copied to second one and automatically getting the descriptions from first tab). Database in the form of one tab at spreadsheet is simply for managing for me (we used not more than 500 different parts) - you see everything together and can edit it.
For example 1k at schematic was translated into 1k 0603 5% as we decided that 0603 is our standard. When I started to add sometimes a 0402 resistors I added that information to symbol value at schematic so 1k_4 was translated into 1k 0402 5%. When we had to use 1% resistors I added that information to its vale so it was 1k_1%. So with Protel I had all information about element in its vale at schematic. Moving in 2017 to KiCad I decided that I will select element from database not only based on its value but based on its value+footprint. I copied my spreadsheet and modified the expression used to select the element from database. Now both 1k 0603 and 1k 0402 at schematic I see as 1k. So having a printed schematic alone you don’t know the footprint but in BOM you have the right element assigned to right references. Before going to KiCad we decided to specify all (really almost all) resistors as 1% so one problem less.
With capacitors I use simple value for capacitor with lowest voltage we use. So for example 10u means 10uF 0805 10V X7R, and 10u25 is used for 10uF 1206 25V X7R. I am not writing from PC with KiCad on it and I have designed nothing since 3 months so that capacitor examples can be not exactly right, but you know what I mean.
My system works for me, but we are a small company and we only do our own designs.

15

Don’t do that.

While my main Value has the most relevant measurement (R-Resistance, C-Capacitance, L-Inductance), I have auxiliary fields for things like (RTol, RPower, CTol, CRating, CVoltage, LTol, etc.). The existence of any field above and beyond value and footprint forces the object to get pulled into its own BOM entry.

This means that a Value=10uF Foot=1206 is considered to be a different BOM entry from a Value=10uF Foot=1206 CTol=10% which is different from one that also include CRating=25V. Now, I may use the same part number for all 3 since a 10uF 1206 10% 25V smt cap is pretty generic. However, they will always appear as seperate BOM entries.

However, I also may not. A 10uF 0402 cap where you don’t care about the voltage rating is generally quite a bit cheaper (something like 10 cents vs a dollar–that’s an order of magnitude) than a 10uF 0402 25V cap.

Side note: the reason why you care about the voltage rating on a capacitor is generally NOT because you’re going to put too much voltage on it (normally). Generally the issue is that a capacitor derates much more slowly vs DC bias voltage if it has a higher voltage rating. A 6V 0402 10uF cap may only be 2-3uF when it has a DC bias of 3V while a 25V 0402 10uF cap may be almost 8uF at the same DC bias.

16

You do not have to add the field itself manually to each schematic symbol.
I recently (yesterday) discovered: Schematic Editor / Preferences / Preferences / Schematic Editor / Field Name Templates

The Field names you enter there are global to all schematic symbols in all projects.

Agreed, but with the Field Name Templates this is not needed.

This is simply not supported (yet) in KiCad.
In KiCad, the core of a “part” is the schematic symbol, and this includes the graphics, and 4 historically defined fields: “Reference”, “Value”, “Footprint”, “Datasheet”

I’m guessing / hoping that the Database approach planned for KiCad is setup in a flexible way, and can for example have a list of HPN, that link to (a sub set) of schematic symbols (For example “R”, “R_Small” and “R_US”) and footprints (For example a “Medium Density” variant that’s easy to solder reliably, and a “High Density” variant with smaller pads)

KiCad currently already has separate libraries for schematic symbols and footprints. The limitation in KiCad at the moment is that it can not distinguish between a “Part” and a “Schematic Symbol”. The “Schematic Symbol” (once placed on the schematic) IS the part, and it has a link to a single footprint.

17

I think the title of this thread shows the crux of the problem. It ends with “components”.

KiCad doesn’t have component libraries. It has symbol libraries. A symbol is a graphical representation of a circuit element in a schematic, plus a few other attributes. To relate this to something that is placed on the PCB there are various strategies:

  • The PnP human picks parts out of their box
  • The hobbyist ordering from a PCBA adds fields as required by the assembly shop and enters the required data so that the shop can find the right components. The BOM generator is adjusted to output the format required by the shop. It doesn’t matter that these fields are per project as they don’t build many PCBs or change shop often. The shop’s stock may also change.
  • Small enterprises using KiCad (ab)use a field to contain an ID (e.g. HPN) which can then be related to a MPN, a V(endor) PN, or the like.
  • Something more comprehensive is needed in future

Another issue is that the stock symbol library should not contain this ID (note: ID not field but see next point). Firstly the KiCad librarians do not want to manage this ID space. Secondly everybody will have different schemes for IDs. Enterprises with databases will already have their own ID scheme.

The stock symbol library should not be user modifiable, otherwise it cannot be updated with new releases. It’s more important to beginners to have symbol libraries they can use than to have a workflow that can generate BOMs out of the box.

So that means the ID must be stored elsewhere than the standard system files. One way would be to copy or import the symbol library, and have a method to update the copy as new versions of the library are released. The small enterprises already do this; they may not even care about the stock libraries but build their own.

The part database (and this is what the augmented symbol library has become) must also have access control so that only authorised users can populate the IDs.

How to store this parts database? It could be a relation between the ID and the symbol in the library. It could be a full set of tables in an existing database. Or something in between.

Any method will have to take into account the existing workflow of KiCad. Hopefully it should require a minimum of extra capabilities in KiCad, and be a flexible solution that can be used for the other libraries in future. (Who knows someday people may want to use enterprises managed 3D models.)

The reason this ties in well with the work on connecting databases to KiCad is that databases are a standard way to store the information with standard APIs to access it. Not to mention the possibility of advanced actions by queries. And you get access control for different users. DBs are not the big scary things they were in the past. Even single desktop applications (like my media player) these days make use of an application specific DB. It’s also possible that a small KiCad DB can run in conjunction with an enterprise DB elsewhere.

18

My two-pennies-worth:

Properties
Properties801×600 22 KB

We don’t make a lot of boards, mainly short run bespoke stuff.

The above works for us

Mike

2 Likes
20

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.