As I mentioned in my original post, I recently had two instances in which I needed to troubleshoot KiCad library paths. Which is to say, crosscheck what the Manage Symbol Libraries (or equiv Footprints) says is supposed to happen versus what KiCad is actually doing. In both cases, it turned out that KiCad was behaving “as designed”, but it wasn’t clear that was so, or what the “design” was.
Instance 1:
I had recently updated to K7. Since I am maintaining projects that were created in K5, K6 and now K7, I need to maintain user libraries that pertain to each set of projects. So, as I usually do, I created a K7-specific UserLibs directory to hold subdirectories for user-symbols, user-footprints, user-3dmodesl and so on. To those directories I copied all files from the corresponding K6 UserLibs. I then used Manage Symbol Libraries (and same for Footprints) to register these user libraries, and migrate them to K7.
Later, when I used a symbol from a user library, it seemed to be an old version that I though had long been revised. This led to some troubleshooting as to whether this was indeed an old symbol, and why it was now appearing in K7.
It turned out the following had occurred:
- During the K5-to-K6 update, I had used the procedure described above to initiate my K6 UserLibs directories.
- In that process, I had copied K5 library files into the K6 user-libs folder.
- I had registered and migrated those files. That created new K6-format library files, while leaving the K5-format files in place. At the time I was not savvy and vigilant enough to delete those K5 files from the K6 directory.
- Now during my K6-to-K7 upgrade, I copied those K6 libraries (some updated since initiated from K5) to K7 user-symbols, along with the left-over K5 library files.
- When I then registered and migrated the newly-copied “K6” library files in K7, K7 converted the K5 files, and overwrote the K6 files, leaving me with some K7 libraries that actually came from K5, not the newer ones from K6.
OK, I am sure that in retrospect you can spot the missteps on my part. But that is not the point – the result was a mess that I needed to troubleshoot, and where I wanted 100% confidence that a particular component (symbol) was coming from a particular file.
Instance 2
In this case, I was trying to find out why the 3d models of some (but not all) PCB footprints were not showing up in the 3D viewer. This led me to pursue the link from footprint properties to 3d-model. There I discovered that these links are specified using the variable KICAD6_3DMODEL_DIR.
Well, in a K7 library, “KICAD6” appears at first glance to be a bug. It is also not defined in the Configure Paths table. So logically, the reason that the the 3d-models don’t appear is because the K7 library data is broken.
Yet other components DID appear in the 3D viewer, and also have 3d models linked by variable KICAD6_3DMODEL_DIR. How could that possibly work?
Here I could really have used confirmation of what actual files K7 was trying to use for the the footprint, and what file it was trying to fetch for the 3D model.
Turns out (as you probably know) that K7 treats KICAD6_3DMODEL_DIR specially – internally it converts this to KICAD7_3DMODEL_DIR.
And the reason that some components were not appearing in 3D was… in a previous session, I had set the viewer’s option to hide through-hole parts. Doh!
So here again I had made a misstep, but in this case the situation was clouded by the unexpected design of K7 – the hidden transformation of KICAD6_3DMODEL_DIR to KICAD7_3DMODEL_DIR.
These are the kinds of cases that make a user seek more confidence in the actual files used as the source of symbols, footprints and 3d-models