My typical workflow is to keep the PCB and schematic in sync.
Sometimes I have to edit a footprint on specific PCB in a way that I don’t really need saved in the future (i.e. changes to default silk).
When updating the PCB from the schematic there is an option to “replace footprints with those specified in schematic”. This will NOT update manually edited footprints on the PCB. Great.
I have noticed though that the footprints on some items in the schematic don’t reflect a complete footprint path. i.e. Instead of it being ‘Molex:01511’ it instead just says ‘01511’.
If you run the PCB update it will say that the footprints don’t match, and it will change them to the library version. It doesn’t, however, link them to the full library path name. So the very next time you run update, even if nothing changed, you will again be told that this footprint will be updated.
What’s interesting is that you arent allowed, at least in KiCad 7, to enter a footprint name that isn’t a full path. Which makes me think that this mismatch happened while updating from 6 to 7 maybe.
Here is a part I just had to edit. The footprint isn’t a complete path. Trying to save these properties will throw an error. However, this is what is currently saved in the design:
For KiCad V5 and earlier, the footprint links in the schematic were just the base names. I think that the library names were added in KiCad V6. It’s not a bug. KiCad Keeps the old name to maintain compatibility with old projects (so they can be upgraded without throwing errors), but if you want to change anything about the footprints, you have to fix the library names in the links first.
I wonder if the behavior during a PCB update should be to throw an error. The only reason I say that is because it seems to breaks the idea of keeping the PCB and the schematic in sync if its possible that after a PCB update there are still differences.
To me it makes more sense the way it is. Quite often older projects are opened in newer KiCad versions, and PCB’s are ordered again without any modification, and ERC or DRC complaining about this would be a nuisance for these old projects. (Assuming they were verified before, as in production).
When the decision is made for a new revision (such as updating footprints), it is a more logical moment for KiCad to start complaining about those old and incomplete footprint names. But it is a bit ambiguous and a compromise. But adding a setting to whether KiCad would complain about this is probably more trouble then it’s worth.
I didn’t mean to imply an ERC or DRC error (unless maybe I’m confused about those).
I’m saying it would be a warning or an error on the screen below. basically, something saying that the footprint name in the schematic is incompatible with the PCB. As it stands you’ll see something like:
“Updating footprint MY_LIBRARY:MY_PRINT to MY_PRINT”
This image shows what it looks like when the schematic has a partial name. Seems misleading to me because the tools isnt actually going to change the PCB footprint from LIB:NAME to NAME.
It does indeed not feel “logical” that Update PCB from Schematic [F8] would remove the library name for the footprint that is already on your PCB, but to be sure of what is happening you have to know the cause of the footprint on the PCB having a library name while the schematic does not have this.
My understanding is that it won’t actually remove the library name from the PCB’s footprint. It just says that its going to and the actual behavior is that it reverts the footprint to the library version while leaving the name the same.
Are these downloaded symbols/footprints by any chance? I’ve often seen downloaded symbols intended to be used with downloaded footprints include just the name of the footprint in the symbol, with no library name (since they can’t be sure where the footprint will be saved).
I believe Kicad used to (maybe still does?) internally search for footprints across loaded libraries when provided with just a footprint name. If that behavior is occurring in the background (to support very old legacy files), that might explain the confused schematic to PCB message?
If you are able to share a portion of your project (enough to demonstrate this behavior) on Gitlab, I suspect it will be easier for a developer to tell you whether it is “as designed” or a bug. Easiest way is KiCad > About KiCad > Report a bug. You can also share the project with just the lead developer team by marking an issue confidential.
