KiCad 7 footprints link to KiCad 6 path

[Heath_Raftery]

After months of happy v7 use, I was hit by this bug today:

KiCad 7 3D models of a KICad 6 imported file

I don’t know if I’m missing something so I post it here. When you have a KiCad v6 PCB file all standard footprints has 3D models pointing to ${KICAD6_3DMODEL_DIR}… When this file is imported by KiCad v7 the 3D models paths are left unchanged. If you now try to use the 3D View no model is visible. This is because all of them uses KICAD6_3DMODEL_DIR, which isn’t defined by v7. If you now update all the footprints from the standard libs the models still point to KICAD6_3DMODEL_DIR, and this var…

The resolution is quite simple, but confused me for a bit, so I thought I’d share.

• KiCad 7’s footprints do point to v6 models. Specifically, they are referenced with respect to ${KICAD6_3DMODEL_DIR}. See, for example, R_0805_2012Metric.kicad_mod. I speculate that this is at least true of all footprints that existed in v6.
• When I installed v7, I already had v6 installed and moved it aside first. My paths got set to:
  • KICAD6_3DMODEL_DIR : /Applications/KiCad 6/KiCad 6.app/Contents/SharedSupport/3dmodels/
  • KICAD7_3DMODEL_DIR : /Applications/KiCad/KiCad.app/Contents/SharedSupport/3dmodels/
• Everything hummed along nicely and I was none the wiser. Then, because everything was going so well, I did a little spring cleaning and deleted some old versions of KiCad…
• Yep, you guessed it, broken footprints!

So obviously the resolution is to either:

1. Restore KiCad 6 and keep it around.
2. Update KICAD6_3DMODEL_DIR to point to the same location as KICAD7_3DMODEL_DIR.

I’m going to try #2 to see if I can break free from v6, but am happy to keep #1 in my back pocket just in case.

---

So I guess the conclusion is that KiCad is a bit clever during install to try to make upgrading seamless? Perhaps the v7 library uses the v6 path so nothing gets broken when upgrading. Then maybe there’s a check during install, and if the v6 path doesn’t exist, it gets set to v7. All seems magic until you decide, wow, v7 is so good already I don’t need v6 around any more…

Have I got it all wrong, or missed where this was already discussed?

[retiredfeline]

The problem stems from the fact that the 3D model path is stored in the footprint rather than being associated by name or some similar method. This makes it a bit inflexible to release library updates. I don’t know what the long term plan is. But for now, if v7 models are a superset of the v6 models, then just make KICAD6_3DMODEL_DIR the same value as KICAD7_3DMODEL_DIR like you suggest in (2).

[gkeeth]

This is non-intuitive, but in v7 the ${KICAD6_3DMODEL_DIR} variable is automagically pointed to the same thing as ${KICAD7_3DMODEL_DIR}, as long as you don’t have a ${KICAD6_3DMODEL_DIR} variable manually defined. This happens during runtime, not install. This is buried in the documentation here: KiCad | 7.0 | English | Documentation | KiCad

One reason for this scheme is that v7 has a “footprint in design doesn’t match footprint in library” DRC warning, so updating all of the library footprints with KICAD7 variables would have caused anyone opening a legacy design in v7 to suddenly have a bunch of not-helpful DRC warnings until they updated all of the footprints in the design. Rinse and repeat for every other legacy design. V7 doesn’t have a “diff footprint between library and board” so the difference would not have been obvious. V8 has a fancy diff tool for library-vs-design so hopefully this type of discrepancy will be easier to resolve. (That said, I don’t know what the plans for V7-to-V8 library upgrades are).

So your possible solutions are

1. make sure you delete any V6 variables, and things should Just Work ™
2. add a ${KICAD6_3DMODEL_DIR} variable and set it to the same thing as ${KICAD7_3DMODEL_DIR}, but this is essentially what KiCad does under the hood anyway