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.
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.
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.
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.
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.
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.
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
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.
“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.
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.
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
@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.
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:
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.
