Footprint associations; update PCB from schematic

[BobZ]

The issue behind my earlier suspected bug (Correction on November 7: I think this dialog box (update pcb from schematic, image shown below) is probably not the source of the issue.)

PCB indicates netlist does not connect, even though schematic looks correct....

seems that my schematic footprint assignments seemed to be getting over-written by the footprint assignments in my symbol library. When the symbol library did not specify a footprint (I did that for resistors and capacitors for example) that may have caused the disconnection.

Tools>Update PCB from schematic gives me this dialog box with the upper 3 tick boxes:

If the bottom tick box is unchecked, does that change the footprint assignments as listed in the schematic symbol properties?

Has there been ANY change in the default behavior of these three tick boxes for my version, particularly the bottom one related to footprint assignments?

As for the second question, there would seem to be a number of possibilities, including:

1. No memory whatsoever between cycles of “Update PCB from Schematic”.
2. Memory of the settings within a KiCad session.
3. Memory for a project.
4. Memory for an installation of a given KiCad version.
5. I suspect there could be others.

I could probably spend a lot of time with experimentation in an effort to figure the above, but this may not give me all of the answers. I assume that someone knows??

Thanks.

Application: KiCad x64 on x64

Version: 8.0.6, release build

Libraries:
wxWidgets 3.2.6
FreeType 2.13.2
HarfBuzz 9.0.0
FontConfig 2.14.2
libcurl/8.8.0-DEV Schannel zlib/1.3.1

Platform: Windows 11 (build 22631), 64-bit edition, 64 bit, Little endian, wxMSW
OpenGL: Intel, Intel(R) Iris(R) Xe Graphics, 4.6.0 - Build 31.0.101.5186

Build Info:
Date: Oct 14 2024 01:02:33
wxWidgets: 3.2.6 (wchar_t,wx containers)
Boost: 1.85.0
OCC: 7.8.1
Curl: 8.8.0-DEV
ngspice: 43
Compiler: Visual C++ 1939 without C++ ABI

Build settings:

[eelik]

@BobZ

The issue behind my earlier suspected bug:

The whole thing is a big mess, I’m not even trying to understand it. I’ll comment only on the specific detail with a specific answer.

@BobZ

If the bottom tick box is unchecked, does that change the footprint assignments as listed in the schematic symbol properties?

Yes, if the Update process is creating a connection between an existing footprint and a symbol, or keeping an existing connection, and the footprint library link (“library:footprint”) is different in the symbol Footprint field and in the PCB.

Whether you update using references or UUIDs, it’s possible that an already existing footprint in the PCB is linked to a symbol but the footprint, i.e. its library link, is different than in the symbol’s Footprint field. You may have changed the footprint in the PCB; then the old UUID is kept. Or you may have used reference designator for updating and that third checkbox unchecked; the UUID is created even if there’s mismatch between the library links.

That checkbox selects whether the footprints which have different library link than in the schematic symbols will be changed in the PCB so that the new footprints are chosen according to the schematic.

It should not affect any other footprints, namely those whose library links are already matched between the schematic and the PCB.

If you have used only the basic workflow, without the “Re-link” option, and so that after adding a footprint to the PCB you haven’t changed the symbol’s Footprint field, the third option should have no effect at all. It doesn’t update or change anything if there’s nothing to change. It doesn’t check, for example, if the symbols or footprints in libraries have been changed.

[eelik]

@BobZ

As for the second question, there would seem to be a number of possibilities

I don’t understand. You speak about possible “memory”. There’s no memory involved, only three or four things which I already mentioned:

• Symbol’s Footprint field in the schematic, the footprint “library link” in form of “library:footprint”.
• Reference designator.
• UUID which is invisible for the user but exists in the schematic symbol and in the PCB footprint as the primary link between the symbol and the footprint in the design. (Not in the library symbol or library footprint; they don’t have UUIDs.)
• Footprint’s library link in the PCB.

These are the only things which are “remembered” in this process.

[BobZ]

Thank you very much. I appreciate your effort to dig into these details

@eelik

There’s no memory involved

With the three binary tick mark variables, there are 2^3=8 possible combinations for the state of those tick boxes. I did not knowingly check or uncheck any one of the three. The three boxes seemed to come up checked by default. Isn’t that one of 8 possible states of the 3 boxes remembered somehow? If it is not remembered then it would come up at random, which I doubt. If it always comes up (default) with all three checked, then at least that default state is remembered somehow in KiCad. But let’s say that I now uncheck the first box and save my project.

1. Without closing the project, a few hours later I again update the pcb from schematic. Would that first box remain unchecked?

2. What if I close the project and re-open it?

3. What if I turn off my computer after closing the project, and then re-open the project?

4. What if I close the project and open a different project?

5. What if I update to a new 8.XX version of KiCad.

There are more possible combinations…but the question is when or whether the state of those 3 tick boxes is remembered.

[BobZ]

@eelik

The whole thing is a big mess

I am not sure what is a big mess…

Right now I am dodging this issue by using only the footprints which are assigned in my symbol library and NOT changing that association in my schematic. I added symbols to my personal library in order to do this. But I would like to figure out what was going on. It is conceivable that it was all my fault, but this seems to be a new issue that I never encountered previously.

[retiredfeline]

@BobZ

The three boxes seemed to come up checked by default

Actually for me the default setting of the tick boxes is Reiink: unchecked, Delete: checked, Replace: checked.

The Relink option is only needed for certain situations, it’s too early for me in the day to remember when to use it, but if it’s checked, then you would not be able to easily renumber RefDes on symbols, which I do a lot.

[BobZ]

Thank you, retired cat…

So maybe once upon a time I checked that re-link box and it stayed checked. Maybe that was my big troublemaker. How long will it stay checked? Other than me unchecking it, are there any other operations (such as changing to a new project) which would cause it to become unchecked?

This is the reason for that question.

By the way, doesn’t a retired cat mean there must be such a thing as a cat with tires? Wheely?

[retiredfeline]

@BobZ

How long will it stay checked? Other than me unchecking it, are there any other operations (such as changing to a new project) which would cause it to become unchecked?

I did a little experiment. I toggled the Relink option, but didn’t update the layout. I exited the layout and schematic editors. Neither prompted me to save my work.

So I looked in the global KiCad preferences and the change appeared in the pcbnew.json file. This is the section that stores the options:

  "netlist": {
    "associate_by_ref_sch": false,
    "delete_extra_footprints": true,
    "delete_shorting_tracks": false,
    "report_filter": 29,
    "update_footprints": true
  },

So if you change those settings in one project, it will affect other projects you are working on.

Perhaps it’s a shortcoming that these options are not stored per-project.

[BobZ]

Thanks a lot.

Just to be sure…I think that unchecking the first box means that linking is taking place via UUID and not ref designation. I have trouble keeping straight the ramifications of that…

Is it reasonable to say that the combination of first and third tick box is a bit dangerous?

So if I have changed a bunch of footprint assignments in my schematic, and now (without due care or some other way) update PCB from schematic with all boxes checked, now I will undo all of my footprint assignments made at the schematic level.

I think this deserves at least a warning or something? Especially since I might do it unintentionally, because I did it two months ago…

@retiredfeline

Perhaps it’s a shortcoming that these options are not stored per-project.

Is there one safest combination of tick marks to which it ought to default each time? Maybe another box saying “remember this setting”

[retiredfeline]

@BobZ

I think that unchecking the first box means that linking is taking place via UUID and not ref designation.

Yes those are the two methods.

I’ll leave others to discuss the ramifications of the various settings or suggest reworking of the UI, it’s too early in the day for me to do any serious thinking, maybe even too early in the year.

[eelik]

@BobZ

If it is not remembered then it would come up at random

Ok, now I understand, you meant the checkbox states, not the state of the design. Sorry.

@BobZ

I am not sure what is a big mess…

I referenced to your bug report and earlier discussion.

[eelik]

I don’t know if you have already read this, but here is the FAQ article about the two update methods:

Update PCB from Schematic's match methods

Because this topic raises problems and questions perennially, here is another explanation which goes into more details. KiCad version 5.99 (later 6.0) is used for reference. In KiCad changes made in the schematic must be propagated to the layout explicitly with Tools → Update PCB from Schematic. Notably KiCad must have some way to keep the connections between symbols and the corresponding footprints. Normally it’s done using internal unique IDs. Each symbol in the schematic has an ID. This is …

The UI and the texts of the dialog are already about as clear as they can get. Enormous amount of work was once spent on fiddling the texts so that they are unambiguous and descriptive. Please read the tooltips, too.

Trying to enhance usability of the dialog is a tricky business. The last two checkboxes are most probably such that the user wants them to remain as they are once selected (for the project). But the first should not be. There’s something wrong in the workflow if someone wants to keep the checkbox checked all the time. Typically it’s used once in some certain situation (as described in the FAQ article), then switched back to the normal UUID-based update.

[BobZ]

@eelik

not the state of the design. Sorry

No apologies needed. I think that my initial description of the issue probably could have been more clear.

But…now I am confused again.

Let’s say that my personal library resistor symbol is linked to an 0805 footprint. But in the schematic diagram I change R17 to a 1206 footprint.

Is there ANY setting of those check boxes which would cause R17 to revert to an 0805? I am now thinking that it would not. This is what happened to me A LOT since I upgraded to 8.XX.

One other point: I have been changing some reference designations, but I have only been doing that in the schematic diagram before I “update PCB from schematic”. All three boxes were probably checked.

[eelik]

@BobZ

All three boxes were probably checked.

The main point of the faq article is that the first checkbox should be unchecked unless you need it temporarily for some specific reason. Changing refdes in the schematic isn’t one of those reasons.

Actually, changing references and immediately doing the update with the “Re-link” option checked can mess up the design. If you want to still spend time on this, you can try. Use a copy of an existing working project. Re-annotate the schematic with these options, and you should see messages telling what has been changed:

Now do the PCB update, the “Re-link” option checked. Here’s one design’s (fully routed, no “unconnected items” in DRC) ratsnest after that:

Many footprints deleted; new ones added; pin nets changed, etc.

[BobZ]

Ahh OK.

So I can see that with a normal schematic to pcb workflow, no reason to check that first box. But that check mark might be useful if I want to duplicate a layout on the pcb and on the schematic and manually match the ref designations.

But I am still left with my original issue:

@BobZ

Let’s say that my personal library resistor symbol is linked to an 0805 footprint. But in the schematic diagram I change R17 to a 1206 footprint.

Is there ANY setting of those check boxes which would cause R17 to revert to an 0805?

[eelik]

@BobZ

Is there ANY setting of those check boxes which would cause R17 to revert to an 0805?

I can’t think of any. However, if you can’t repeat this on purpose, it’s difficult to say if there could be some combination of actions which could do that. There are many details in the edit/update process which can interact and my logical thinking may not cover all of them, no matter how hard I try.

I recommend reading the FAQ article and trying to understand how the two options work and why. After that you should be able to notice and understand if you accidentally make some repeatable mistake. Your use cases are already covered there explicitly.

Simple Undo should be enough to fix the situation immediately if the Update has messed up something. But it can also revert the update in the PCB after a successful update, of course, and this can change the updated footprint back to the older one.

[BobZ]

Thank you again.

I did give the FAQ article a quick read but need to go back to it for a more careful read.

I did not notice immediately when these footprint changes happened. Fortunately I have been saving dated backups. After seeing that the footprint was wrong, I was able to go back and confirm that the footprint was correct a few days previous. There was a lot of design work in between. So retracing steps would not be possible…

I do wonder whether the “update pcb from schematic” dialog box ought to include a caution note regarding that first check box. But I don’t think that was the source of my problem…

[retiredfeline]

My opinion is that the three toggles should be per project and/or the first toggle should be spring-loaded to return to the UUID option. But it’s just second nature for me to watch the options every export now.

[BobZ]

@retiredfeline

spring-loaded

OH, NO!!! BOING!!!

Seriously, based on explanation from @eelik I think I agree that the first check box should probably come up unchecked, even if it was checked on the previous update of pcb from schematic.

But I am also willing to believe that the devs have beaten this question to death and maybe there is some use case to the contrary.