Over some years, we have developed some in-house symbol and footprint libraries, a process which has been subject to, ahem, accumulation of incremental learning:-).
We would now like to apply a more-orderly symbol and footprint naming convention, and also add some fields to those symbols and footprints.
The question is: on existing schematics and PCBs, what Kicad (8) steps should we perform to efficiently substitute in the newly-named symbols and footprints while minimizing disruption to existing nets (in schematics) and footprint positions (in PCB)?
The newly-named symbols and footprints will not change pin numbers or names, nor symbol or footprint geometry.
(FWIW: the in-house library symbols often use Kicad-supplied footprints, and the in-house library footprints are often for Kicad-supplied symbols. Only in a minority of cases does an in-house symbol have an in-house footprint.)
[Edit: replaced alias with inherit]
One intermediate step we could perform for symbols is to change the names of existing symbols in the library to the new desired names, then add old-name symbols that inherit from newly-named symbols. Existing schematics could then simply retain the old names, and update the symbols from the library to acquire new fields.
[End edit]
However, we would really like to remove the old names from the library to avoid future erroneous use of the old names.
I’m almost thinking that we might be further ahead by renaming the symbols in the library, and then doing text search-and-replace on the existing schematic files to make the change (using python or similar, not by hand). And similar for PCBs and new-named footprints.
However this seems a little cavalier, and it would be nice to learn of an official (safe and efficient) workflow for this sort of task.
It looks like you are thinking KiCad V5. There are no aliases now. When I upgraded my V5 library to V6 all aliases were replaced by symbols derived from other symbol (I’m not 100% sure - may be it was when upgrading from V6 to V7).
Since V6 (or V7) all used symbols are saved in schematic file (in V5 they weren’t). So old schematics (being first upgraded to current version) need not to look for their (old) symbols in library.
In my opinion you should move your all libraries and projects to V7 (or V8) and then you don’t have to keep old symbols in libraries.
Since V6 or V7 there is a function at schematic to replace one symbol with another (can’t point exactly as I’m writing from Win7 PC with V5). Use it and if pins have the same numbers everything should work, I think.
In 2017 I spend few months after reading KiCad pdf’s to make my final decisions about my KiCad directory and library organization before I started to do my first KiCad V4 project.
I have described it some time ago (hope you find it interesting):
First, get your library management in order. It’s understandable and common to use ad-hoc libraries that grow organically in the beginning, and then re-organize them later, when there is enough data to both make the organization meaningful, and useful. The easiest way is to create a new empty global library (or multiple global libraries). This way the ace accessible (both read and write) from all your projects.
Use: Schematic Editor / Tools / Edit Symbol Library Links.
There is no need for this. Symbol names have a “library + symbol name” combination, so when your new symbols are in a separate library, their names will already be unique.
You could use a utility such as grep to search for the old names in schematic files. This can give a quick overview if the old names are still used in any of the projects. KiCad’s files are text based (S Expressions), so text based utilities can be used for searching and analysis (but modification in a text editor is error prone).
Ah, right. I meant inherit, and have edited by original post accordingly.
But then the old symbols can’t receive updates from the new libraries, for example fields we want to add.
Yes, when they need to be updated, existing schematics will be moved to V8 (or, in future, V9 etc). And it’s at that point that we need the process for updating existing old-name symbols to their new name, and ability to update from the new version of the symbols (mainly new fields).
Yes, it looks like in V7 the most helpful functions are:
Select symbol > right-click > Change Symbol, that I now see allows performing a change on all symbols of that type, or
Main menu > Tools > Edit Symbol Library Links, which shows a table with one row per symbol type. Sadly, not sortable (maybe it is in V8?). And it offers to update the symbol fields (good if we want to add fields) but warns that it will overwrite existing Value and Footprint – that might be desired or undesired based on case.
Still a bit more manual than I would like, but maybe it’s necessary to consider every symbol type in every such schematic separately.
Yes, I read that page previously, and found your thought process helpful.
We are beyond sold on this point… that’s why I’m here
A new library may or may not be the answer, depending on whether the process is helped by an intermediate step involving inheritance (see my edited original post). But either way, obviously the newly-named symbols have to be established in some library.
This way the ace accessible
Assume you mean “they are accessible”. And I think your point was to use global libraries rather than fiddle with per-project libraries. Which parallels my conclusion for our purposes too.
I’m leaning that way. As I continue to think this task through, once the newly-named symbol has been created, we then would have a policy something like “in each existing schematic, every time you see symbol [oldname], change it to symbol [newname], and do/don’t overwrite these existing fields”.
Using Change Symbol or Edit Symbol Library Links probably gets the job done (not sure how finely it finesses the do/don’t overwrite fields), but requires manually visiting each symbol (or at least symbol type) or each existing schematic.
So I guess it was a lot to hope for, but it would be nice to just set up the policy for each symbol in the new library, and just apply it to each existing schematic automatically.
I’m not understanding your thinking here. Changing the symbol name to a better one is one of the objectives, not some way to achieve unique id.
Yes, grep is a trusty assistant. (Well, actually FileLocator Pro, but same idea.)
I thought you thought you had to change the name to avoid name conflicts in KiCad. Now I understand you want to change the name on purpose, so humans can distinguish between the new and old symbols. As an option, you can add a “revision” field to your symbols. ( I prefer to use date strings in ISO_8601 format for this, because it is both unique, shows the order, and the revision date / age of the item). Note that KiCad “caches” used symbols inside the schematic itself (starting from version V6), and therefore schematics are independent from the symbol libraries that are used. As a result, if symbols in the libraries are revised in the library, the schematics they are used in will not update automatically, as this is a potentially dangerous operation that could break schematics.
Also, ERC can check between differences between symbols in the libraries, and symbols used in the schematic.
If you want a more elaborate symbol and footprint management, then the direction of database driven libraries may be a better option for you.
There are also plans for integrating python scripting inside the schematic editor, but this has been planned for a few years, and probably will take a few years before it gets implemented, unless of course, it is important enough for somebody to sponsor the feature with a budget for priority development at https://www.kipro-pcb.com/
As I said in my original post “We would now like to apply a more-orderly symbol and footprint naming convention, and also add some fields to those symbols and footprints.” This is not motivated by distinguishing old name from new name, though that will happen as a side effect.
Yes, I realize.
Libraries stored in a database are certainly an interest, though it seems orthogonal to the problem at hand.
I had hoped that would arrive in Kicad 7, and am somewhat disappointed that it’s not in Kicad 8. But can’t complain when we don’t have deep pockets (or talent) to meaningfully help advance that area.
