I have a use case where a large inventory of existing parts consists of several instances where components have identical pinouts and footprints and are distinguished on schematics by using different part names. For example, many op-amps have the same pinout and package/footprint.
Using derived symbols works in this scenario, but only partly. The issue is that it does not link the footprint field. It does not even copy the footprint field when creating the derived part.
From a library management perspective, derived symbols inherit the graphical characteristics and pin definitions of the parent part and those properties are immutable. This makes sense because that seems to be the primary purpose for derived symbols, that you create a main symbol once, and not have to re-create it over and over again for parts that are physically identical.
Since KiCad does not support attaching multiple footprints to a part, where the specific footprint can be selected from a list, the implication is that the footprint for a symbol is not normally changed once it is defined. Therefore, it would make sense to include this field as a linked field to be inherited by any derived parts, saving the extra and possibly error prone step of having to manually copy the footprint field for every derived part that is created.
This is a huge effort for situations where symbols are referenced in libraries by part numbers, and identical parts, like resistors and capacitors, number in the hundreds.
I think the primary purpose of derived symbols is to make library files smaller.
It is not to save you work with re-creating it over and over again as no one would do it that way. Anyone needing a copy of symbol would just copy it - no need to re-create.
So if elements with different cases (footprints) can have the same symbol (like OpAms in DIL8, So8, Tssop8, SOT23-8, and may be more) they all should be derived from one symbol to have its graphic and pin definitions once saved in library and not a separate copy for each footprint.
Footprint identification takes so small amount of data that it is better to place it in each derived symbol than have it once in base symbol forcing user to re-create the whole symbol for another footprint. It would take more file space than adding footprint identification to each derived symbol.
When you have an existing inventory of parts with abstract part numbers that is the source of your library for schematic design, then footprints are inherently tied to symbol names. Those same part names drive other things, like BOM’s, which cross-reference component average costs, and are part of the analyses that engineers perform when doing design work for something new.
So, in real-world situations, where you are dealing with hundreds or thousands of different parts, anything that can help to reduce errors in the design process are greatly appreciated. Having the ability to tie the footprint of a derived part to it’s parent part is one such function that does have a good use case. It isn’t a hypothetical, and in my case it applies to an inventory that has over 13,000 unique parts, many of which are both physically and symbolically identical.
For example, the naming convention for integrated circuits is IC-NNN. An LM358 in a DIP package is an IC-271. An LM358 in an SOIC package is an IC-547. Of course, there are numerous other dual op-amps with the same pinouts various packages all having IC-NNN designations. In the symbol library, parts are stored using the IC-NNN name. Other parts use other naming conventions, but you get the idea. If I want an LM358, I can use an internal tool that searches the inventory system using parameters I specify to find the name of the part I want, then plug that name into the library filter and get the part to place on the schematic.
Having all parts pre-defined in the symbol library in this manner eliminates the need for having to remember to fill in fields like the footprint, or the datasheet (which is another field that is not inherited), during schematic entry. This can be quite time-consuming on larger projects, and it can be error-prone when there are a number of footprints that are very similar, especially with surface mount resistors and capacitors.
Hopefully this clarifies why it would be helpful to be able to have checkboxes, for example, next to the fields to ‘inherit’ when creating a derived symbol.
I use only my libraries and all my symbols in symbol library have assigned footprint. All I have to remember is to never ever edit anything in symbol after placing it at schematic.
When I want to change 1k resistor to 1k2 resistor I delete one and insert second one, or there is a function to replace one with the second.
My naming convention is different:
In past we were using:
HVD72D = SN65HVD72D
Because in 2021 ordered terms became year or longer I have added (still orderable):
HVD72DGK = SN65HVD72DGK
HVD72DRB = SN65HVD72DRB
And when problems became bigger and bigger I have added:
HVD72 = SN65HVD72D or SN65HVD72DRB (two footprints made as one allowing to assemble one or second IC).
Once you start working with bigger libraries then the database driven libraries as ML9104 already mentioned are the way to go. With a database driven library you can combine the graphics of a symbol, with a footprint and other data such as resistor values and ordering information and create fully specified unique parts from that. I only use KiCad on a hobby level myself and have no experience with this part of KiCad.
Just looked at the database library information, and this looks like it is likely the best way to go for my particular case. Parts inventory items are already available from the ERP system in an ODBC source, and can be linked to a separate ODBC source that serves as the KiCAD database library.
This approach is not needed for every single part. But for the items that use the same symbol and footprint, and in in some cases, even the same datasheet (think resistors or capacitors that have one datasheet for entire series or even multiple series), it saves a ton of time and reduces errors being able to boilerplate this part of the library.
KiCad already helps with this process by allowing us to add fields to symbols, where I can enter the ERP part number which is used to reference the actual part that is being placed on the schematic. That drives later reporting, like cost analysis, which pulls data out of the ERP system to get the average cost for each part on a given PCB. But after reading on the database library feature, it looks like this should do the job quite nicely, while still ensuring that there is one, and only one graphical version of a symbol.
To me this is more of an object-oriented coding sort of thing, where I want to define a base class, and then add some different levels of inheritance. The ideal is that you never have to define something more than once and if something that impacts multiple symbols needs to be updated, then you can update it in one place and it will apply to all instances that use whatever that thing is. In this situation, the symbol should only need to be updated once if it needs to be changed, and if I need to change a common field value, like a footprint shared by a few hundred resistors, I can just run an update query in a database to do that.
I will definitely give this a go and see how it works.