Database, what to use in symbol Value field, and how to migrate

In my database experiments, I’ve been using the IPN (Internal Part Number) in the symbol value field:

However, all my existing designs have something like the MPN in the value field for a IC or something like “0603_125mW_1%_8.06k” for a resistor.

I like using the IPN for symbol value because if I change part vendors or something in the database, the IPN/Value can stay the same, while the MPN, etc is whatever is in the database.

Does this make sense, or how are others doing this?

I need to migrate all my old designs to the new library format, so I need to replace the Value in the schematic symbols with the IPN. The IPN information is typically already in the old symbol libs, so it seems like this can be automated with a script. Has anyone tackled this problem?

I use a short descriptive text for Value, what it is depends on the type of part. For a resistor, I would use “10k” just like any non-database resistor. For an IC, I would use its family name, not including any packaging suffixes (for example, TPS54336A).

The reason is that I find these to be the most important things to see at a glance when looking at a PDF of a schematic. Like you say, I also don’t want the Value to change when changing/adding manufacturers, which also works for my scheme.

I include a bunch of other data (including IPN) as fields, but all of these fields are hidden and only show up in BOM exports.

Thanks for the input.

Thus far, I have been doing things a bit differently and never display the value in the schematic, but rather a set of fields depending on what type of part:

  • Resistor: Resistance, Tolerance, Power
  • Capacitor: Capacitance, Tolerance, Voltage, Material
  • most ICs: MPN
  • Inductors: Inductance, etc.

The key is to put each part type in a different table with sane defaults for what fields are displayed.

(See kicad_dbl file)

It has been working fairly well:

Some don’t like all the attributes on the R’s and C’s, but I prefer to spread things out a bit and be verbose – more chance errors will be found in reviews.

The description field is populated with text that makes it easy to see what the part is at a glance in the symbol chooser.

So, overall, it seems very usable to me.

I hesitate to assign another unique shortcode to value, as then I have to invent another unique ID and make sure I don’t have any conflicts – say between 0603 10K resistor and 0805 10K resistor. We did this in the past because we pretty much had to before we had the database functionality.

Assume the “Update Smbols from Library” works off the Library link: <library>:<value>. Or is the table key used in the case of a database?

Probably splitting hairs here, but nice to get things right when setting up libs so it does not have to be redone. The thing I really want to avoid is manually selecting and replacing every part in the schematic if I change the value scheme.

It appears the Symbol Value is not the link to the database. I made the following change:

This populates value with Resistance, Capacitance, and Inductance for those parts, and then MPN for everything else.

The result is:

Does the “key” field in the library definition define the linkage to the database?

Assigning value to passive values should work better for Spice simulation, as I think passive components use the value field by default.

Is it possible to assign the Simulation Model from the database?

Yes, using internal part number (IPN) field would be the preferred way to key the database I think, as that is the only field in the entire database which is pretty much guaranteed to be unique throughout. The ‘Value’ field is reserved (that is, it’s always there by default) and seems to be used for passive component parameters such as resistance, capacitance, inductance, etc. For integrated circuits or other active components it could be used for the item’s trade name, like ‘1N4006’, ‘74LVC1G08’, etc., to give an idea of the active component’s identity.

1 Like

Yes, you can define database linkage however you want using the key field. Quoting the relevant sections from the docs:

In a database library, there are one or more tables that generally represent a single type of part (such as Resistors or Capacitors). Each table can have an independent schema, meaning that different types of parts can have different properties that are translated into symbol fields in KiCad. Each table must have a unique ID column which is used as the identifier for a symbol placed from that table. This unique ID will typically be a part number (either a manufacturer’s part number, or an internal organization part number).

And

key: The column name containing a unique key that will be used to identify parts from the table.

From Schematic Editor | 8.0 | English | Documentation | KiCad

As for spice models, yes, you can assign those with the database, although external model files will still be external model files, so you need to make sure those are available with the correct paths anywhere you deploy your library. KiCad uses regular symbol fields (with particular names) to contain the spice properties for a symbol (including, but not limited to, the model assignment). And you can define arbitrary fields for a symbol in the database, so you have everything you need :slight_smile:

My workflow for this would be to set up the spice properties for a symbol in the GUI and make sure it simulates correctly, see what fields get added to the symbol, then add corresponding columns to the database that contain the right data for each of those fields, then edit the database lib definition file to map those new columns to symbol fields as appropriate. It would be the same as any other arbitrary fields, you just need to make sure you match what KiCad expects.

1 Like

Thanks for the clarification! Look forward to starting to populate my lib with spice models :slight_smile:

“Update Symbols from Library” links to the name of the symbol in a particular library. Ironically the name of the symbol does NOT appear in any field option. I have been adding a “Symbol Name” field to my parts so that if there is an issue with any part when reviewing the BOM I can immediately use the symbol editor to go right to the part in question.

With the GitPLM PN scheme and library organization, it is super easy to find the part in the lib.

Say it is DIO-000-0001.

“DIO” tells me it is in the g-dio lib if it is a custom symbol.

But, in KiCad, it is even easier to search on the part in the schematic, double click, and select edit library part.

You can also look in the original dio.csv file – it has symbol and footprint columns.

That’s true, but rather than groking through the schematic to find the offending part I found it much easier to simply identify it in the BOM. From the symbol name I can immediately see which library it is in so with a single invocation of the symbol editor I can handle multiple edits to multiple parts much more quickly.

@Cliff_Brake I noticed from the screenshot that you are naming your DB columns “Symbol” and “Footprint”.

Just FYI, I think the keys are named symbols and footprints (plural) in the .dbl because they are intended to support multiple symbols/footprints specified in the field (I think this is already supported for footprints and will eventually be supported for symbols too). I ended up naming these columns “symbols” and “footprints” (plural) in my database to make it more future-proof for when I start adding multiple.

I’ve been doing the same thing so each placed symbol has both symbol & footprint values:

@cdwilson thanks for the tip, will make this change! Since we are generating the DB from the CSV files, I think this is just changing the column headings in the CSV.

@fomJeffs will be glad to hear we can support specifying multiple footprints – he was just asking about this earlier today.

I checked the link above. It looks like the support for multiple footprints in the dbl file has been worked out but not released yet. Maybe it’s in the V8 nightly builds? I don’t have that installed here.

@fomJeffs I just tested this out in the 8.0.0 release and it looks like it’s already working for footprints:

(the test files I used are the ones from qa/data/dblib · master · KiCad / KiCad Source Code / kicad · GitLab since I don’t yet have multiple footprints in my own libraries)

Interesting. Doesn’t show how to specify multiple footprints for a given part in the database. We create ours from CSV files. A footprint is specified by a library:footprint_name couplet. So for multiple footprints for a part I tried specifying them like this: lib:footprint1;lib:footprint2 but it only shows the first resistor in the chooser window. So I tried replacing the ‘;’ with a space, that generated an error. Then I tried quoting the field value and use a comma instead of the space and that also generated an error. So if multiple footprints are working in 8.0.0 then we need to know how to specify them in the database.

As a general rule for database design (not specifically KiCad part database), multiple values should be represented as another table, referenced from the main table. Or something like that – it’s been years since I had something to do with databases. The main point is separating “lines” with a special character isn’t a good way to deal with multiple lines in a database.

In any case KiCad doesn’t have “multiple footprints for a symbol”. I guess you mean footprint filters. In the documentation I can see

footprint_filters: Reserved for future expansion.

@fomJeffs this is the correct format. If you look at the example database in the KiCad source “Resistors” table you’ll see that multiple footprints can be specified for a symbol separated by ;, e.g.

Resistor_SMD:R_0603_1608Metric;Resistor_SMD:R_0402_1005Metric

This only works starting in v8 (doesn’t work in v7 and previous). What version are you running?

1 Like

I don’t know the motivation behind using the ; separator, but I think it may be because it was a simple solution that can work for a lot of different use cases.

e.g. for people like @fomJeffs who are using a CSV to create the database, they can easily keep everything in a single CSV.

Or in other cases where somebody is using a 3rd party PLM system, it may not be easy to implement an arbitrary number of individual footprint fields, but having all the footprints contained in a single text string is doable:

2 Likes

Running V8.0.0 and it actually works. I had a typo in the footprint name, pesky “_” missing. Yes, Cliff, those are annoying. This is huge as I use alternate footprints all the time in CADSTAR. Thanks! Also note that if you get a typo in that field it fails silently so probably best to use the database browser and check all the entries carefully.

2 Likes

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