I have a project that has a bunch of custom symbols and footprints. The way I track these custom symbols and footprints is apparently quite atypical. See this forum topic for more details on how exactly.
Say now, I’d like to do something more standard. I can either tediously separate each symbol and footprint by itself, which I will likely end up doing someday, but for now, I’d just like to get something that works short-term to finish an existing project up so I don’t have to go back and change all references in an existing project.
My plan was to export both my symbols and footprints to local libraries with the File–Export–{Symbols,Footprints} to New Library–>Project. This is all fine and dandy for sharing an existing project state, but what happens when I update something in these local libraries? I’m particularly concerned on how to handle updating the PCB when I update a symbol. Since the symbols all refer to the old non-local footprint libraries, any update to the PCB with the “Replace footprints with those specified in the schematic” will revert all footprints back to the non-local ones. So, turn that off you might say. What then happens when I want to change a footprint? Should I do this only in the PCB layout, and not in the schematic, or should I remember to do both? How can I sync the information about footprints between the schematic and PCB again? I was normally updating footprint reference in the symbol on the schematic, then updating the PCB from the schematic to keep them in sync. Is there no way to maintain this workflow after this export to local libraries process?
I can change a footprint in the PCB only, and not update the reference in the symbol, but then how does BOM resolution work? Which footprint will show up in the BOM? The one referenced by the symbol in the schematic, or the one showing the PCB layout? Since the BOM generator is in the schematic side, I’d guess only the one reference in the schematic will show up, leading to errors in the BOM.
I’m happy to just suck it up and remember to update them manually in both PCB and schematic for this project, but wondered if there was a clever way to sync them after using these export procedures.
I feel you are complicating something that is not that hard mixing a bunch of things. But it would be way easier for us to understand your problem if you could share your project. Is it possible?
The footprints are synchronized in 2 ways. By the UUID of the symbol or by its Reference Designator (RefDes). The latter is easier to handle since you can edit them, manually. Tedious but easier. One of the two must be right then you can update the footprints keeping their positioning (I guess). Having both UUID and RefDes changed won’t allow you to sync the footprints (easily). Then, in this case, you will have to manually reassign each RefDes of each symbol following the existing footprints which is not hard if you have a schematic that was not changed much compared to the current state of the layout. Then you will be able to synchronize the whole thing again using the RefDes.
BOM generators will generate the BOM using symbols, only. It doesn’t double-check the board. So, you will have to sync the board yourself to make sure you have the right BOM.
but wondered if there was a clever way to sync them after using these export procedures
Not clever, but could you give the desired result: look in this thread, and follow the steps exactly (especially don’t change the order of the steps): Plugin for archiving project? - #4 by RDs
Thanks, yeah I was doing almost the same thing, but the syncing I’m hoping for here can be likely achieved with one step I left out:
The rest of the steps, were identical to what I was doing before.
Thanks for the tips @leoheck, I think @mf_ibfeew pointed me to the step I was missing to keep them in sync, but to put it in the same verbage you are using, I was using the UUID as my standard sync method. Without the sync from PCB to schematic step quoted above, I was losing the ability to do that. The other issues I mentioned would only be problematic if I were using the RefDes, which I wanted to avoid because of those potentially issues.
@mf_ibfeew I’m unfortunately getting a Segmentation fault (core dumped) error and KiCAD crashes at the end of this step:
I’m able to manually reassign footprints to the newly exported library one-by-one, but I’ve got hundreds of them on this board. Hoping this is a known issue with a workaround.
I managed to find a work around (using vim’s substitution capabilities on the kicad_pcb file. I know thats not for everyone, but if you use git on your projects, or have appropriate backups, you can use what I used:
:%s/(footprint ".*/(footprint "{YOUR_LIB_HERE}:/g
Don’t use it if you don’t know what is going on, but ChatGPT is your friend for syntax like this. In short, its the text substitution function :%s acting on the entirety of the file. It matches (footprint ".*: and replaces it with (footprint "{YOUR_LIB_HERE}: where {YOUR_LIB_HERE} is the actual name you called the local exported footprint library and /g just means it will make substitutions globally (over the whole file). e.g. :%s/(footprint ".*/(footprint "all_footprints_lib:/g
Note that if your existing footprint libraries have a colon : in the name, this substitution will fail quietly and you’ll end up with a corrupted file.
… crash at last save-step … Hoping this is a known issue with a workaround.
Sorry to hear that, but no, this is not known (and I had tried all the steps myself with a simple test-project before writing them in my answer). So in general the workflow should work.
If you are able to reliable reproduce the crash it would be good if you open a gitlab-issue and attach the original archived project (so the developers can follow the steps and also see the crash at the last save-action).
some guesses:
very long directorynames?
working on a networkvolume or a cloud-volume?
some access-restrictions to files?
as all the steps include file-handling operations this could be a OS-specific problem. I tested the description with Win10
This would be the only possibility from your list for my situation that I can see, but I won’t spend much time trying to reproduce it on this as I have a workaround and can’t share this specific project publicly. If the issue arises again on a less complicated or public project, I’d be happy to add a gitlab issue.
If you could show the file I would suggest something like this to you, since this is an easy fix to an easy to solve issue. You can also use any other text editor or command line tools like sed for achieving the same result. This is the beauty of the file being text and not an obscure binary blob.