[PRE-5.1.6] Weird action during "Update PCB from Schematic"

I’ve just noticed strange thing when attempting to update one of my projects.
I do have updated my schematic, and now want to propagate my changes to the PCB.
During the update process, I do have the dialog “Changes to be applied” [1]:
kicad_update1
Then after click on Update PCB, I do have the dialog “Changes applied to PCB” [2]:
kicad_update2

In the [2], there’s a weird action “Change C637 reference to C297”.
What is this? Indeed my updated schematic brings new C297. But there was no C637 in the PCB nor in the schematic. Is it something that should make me worry about files integrity?

What is that C297? In what context?

C297 is a component just recently added to my schematic. There was no C297 before, and the C297 designator is unique. The symbol used as C297 was a copy-paste symbol (of C501 if that matters).
@eelik I’m not sure if I know what you mean by “what context” - what info would be helpful?
@Rene_Poschl what should I look for in that linked description? This C297 was not placed on the PCB before, so the match method should be irrelevant?

The link explains why this message would be normally produced. For some reason your new cap has the unique ID of that old one making kicad think you reannotated that cap in the schematic and that leads to it assuming it also needs to be reannotated in the layout.

My C297 have an unique ID 5EA30ED7 as defined by the Schematic.
Searching the PCBNEW file for this identifier yields nothing (I have copy of the PCB before update). In fact, the only file where this ID can be located using text search, is the actual schematic file.

There could of course be a bug

Can you share the project in “before” state and the exact steps to reproduce this?

I’d prefer not to disclose it, but if it could be a bug I would like to help finding it. If there’s anything I could do without sharing the project, I’ll do my best.
Otherwise I could try to “anonymize” it and send to someone that could take a closer look at it, without further disclosing to the public.

I have access to confidential bug reports in the issue database anyways (I’m part of the bug squad). If you send it me in a private message I could take a look to see if I can say if it’s a bug.

I think I found the culprit. You have probably saved a modified footprint to a footprint library from a board. Therefore the library footprint has a refdes number. It’s replaced by the refdes from the schematic when KiCad updates the board.

So, KiCad does the right thing and you should fix the library footprint.

2 Likes

Yes, you’re 100% right. It wasn’t the board, it was the footrpint that caused my confusion.
Thanks for your time.

IMO KiCad really should reset the refdes when a footprint is saved to a library from a board. This has been annoying many times to me. I think I’ll report an issue.

1 Like

I also can’t think of a workflow that would make use of inheritance of component properties to the library… at least not as default. So the default action to reset the fields to REF*** VAL*** (or whatever is KiCad’s standard of default value) would be reasonable.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.