I would consider this a bug. Therefore did a simple test in KiCad V5.1.5
Edit:
I made an error and deleted most of my post.
The “path” part indeed seems to be identical for all the parts.
1 Like
Thank you. If I understand correctly, I would like to observe that if two footprints have the same UUID that it is no longer unique? So it may be a UID but is not a UUID?
It is often the case that a person who has just learned something might do the best job of explaining it. On the premise that this MAY apply…I am thinking to offer my own explanation of this, with the hope that it might be useful somehow. I will work on it; maybe have something in 12 - 24 hours…
Gosh your ability to read hexadecimal is really something. It would take me a while to notice or figure that out…
UUID’s are a very general thing in computer world. They are used for anything where an unique identifier is needed.
If the numbers are the same, they may still be universal, but definitely not unique anymore 
Be careful. The symbol/footprint connection UID is “path” in the footprint on a board. Tstamp doesn’t matter. Copypasting creates new timestamps/UIDs for footprints, but copies the “path” UID verbatim.
EDIT: in issue 4041 I didn’t give any example files because anyone can test this, but before I wrote it I tested with 5.99.
This is the line which makes the symbol/footprint connection:
(path "/00000000-0000-0000-0000-00005e7017f9")
Oops.
Had a look at the “path” part and they do indeed stay the same.
This looks like a bug to me, but it may be intentional. I do not have enough knowledge of KiCad internals to have a stronger opinion on this.
Copy from a .kicad_pcb file:
(module Resistor_SMD:R_0805_2012Metric (layer F.Cu) (tedit 5B36C52B) (tstamp 5E696FDB)
(at -610.05 -16.09)
(descr “Resistor SMD 0805 (2012 Metric), square (rectangular) end terminal, IPC_7351 nominal, (Body size source: https://docs.google.com/spreadsheets/d/1BsfQQcO9C6DZCsRaXUlFlo91Tg2WpOkGARC1WS5S8t0/edit?usp=sharing), generated with kicad-footprint-generator”)
(tags resistor)
(path /5E66B878)
(attr smd)
(fp_text reference R3456 (at 0 -1.65) (layer F.SilkS)
(effects (font (size 1 1) (thickness 0.15)))
Edit / Addition:
I created a little array of resistors with RefDes “R2345”. After updating from the schematic, all resistors changed into “R3” and KiCad complains about
"Multiple footprints found for “R3”. When I enable “[v] Delete extra footprints” it does not delete the duplicates and still complains about "Multiple footprints found for “R3"”
This is the same bug / behavior eelik described earlier on gitlab: https://gitlab.com/kicad/code/kicad/-/issues/4012#note_302985104
Here is the array:
It seems KiCad is getting confused because of all these footprints with the same “path” / UUID, Timestamp? or whatever it’s called in V5.1.5.
This sure looks like a bug to me.
Application: Pcbnew
Version: 5.1.5-52549c5~84~ubuntu18.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 5.3.0-40-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
Boost: 1.65.1
OpenCASCADE Community Edition: 6.9.1
Curl: 7.58.0
Compiler: GCC 7.4.0 with C++ ABI 1011Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=ON
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON
In issue 4041 the developers seem to agree this is not wanted and will be changed for v6.
To give a reason to why it might be a desired behavior would be cloning a block to try laying it out in different ways, you can then just delete the one you do not like and everything remains set correctly,
Versus the behavior that causes this dis-agreement which is based on wanting layout “blocks” to easily copy-paste pieces of PCB, which is its own feature request and would help resolve the under laying desire as far as I can see.
As far as I can tell another fix would be having some means to re-link by reference, as at present if you select update by reference, my expectation would be my duplicated capacitor footprint that I changed the component reference on should have its path updated to match the netlist file. as It remains the least risk of issue out of the proposed solutions in my eyes. as I deliberately set that reference. and things like the warnings of non matching footprints or duplicate footprints would still persist.
That should still be possible, although with extra steps to update by refdes.
If the duplicate UIDs when pasting/duplicating are removed and someone feels they still need it, I suggest filing a new issue for Paste Special to allow keeping the UIDs at will. (See Paste Special in 5.99 eeschema to see what it looks like.)
By “reference” do you mean “reference designation” such as “C46”?
And what you mean by that?
Hi, Eeli. Thanks a lot. I think that your explanation from the bug report is the clearest. I hope that it may be included into the FAQ. The other additional possibility is that we could improve the wording in the dialog box?
"
Eeli Kaikkonen 
@eelik · 1 day ago
Sometimes it’s good to hide internal behavior and terminology from the user. However, I believe sometimes revealing it may be better. In this case BobZ experiences problems because the two visible texts don’t feel parallel - only one has the word “match”, and even there it’s “update to match”. But in reality these two options are:"
To clarify, above they keep saying that the UID for the part is now called a “path”, which the update from schematic uses to link up what net and properties belong to what footprint
my expectation when selecting to update via component reference would be that it sees say C95 does not have the correct “path” or UID, and update it on the footprint to align with the netlist
This in my mind leaves the most freedom in how it is implemented and then makes having the 2 options make sense, with the component reference one being “yes I went and duplicated some stuff, now make it all link up with the schematic please” it could be a checkbox option if there is any fear with that, e.g. “Update duplicated footprints to match new component reference.”
Each symbol instance in schematic has a UID. But the UID is unique only inside a file. Each file can have several instances in form of a hierarchical sheet. Therefore the symbol’s UID can’t be directly used in the footprint to indentify the connection. Instead, “path” of the symbol is used.
For example, we have
(path /5E3196E2/5E37A471)
in a footprint on a board. The first part here is the sheet ID, the second part is the symbol ID. Together they form a path which is unique.
I have tried to keep the explanations simple and therefore used path and UID as synonyms. In a simple non-hierarchical schematic they practically are the same.
The exact mechanisms involved in hierarchical sheets aren’t quite clear to me, and in v6 it may be a bit different anyways because of the new symbol/schematic file format.
What we need to understand is that each symbol instance has a unique something (be it called “path” or “UID”) which is stored in the corresponding footprint instance. That is the invisible link between the symbol instance and the footprint instance. But if that link doesn’t exist or is wrong for our needs, we can change it by manually editing the reference designators to match and then update the paths/UIDs in the PCB. After that the normal default path/UID matching mechanism works again.
Do you mean update the paths/UIDs according to reference designations in the schematic diagram? Should the footprint be changed (if necessary) to agree with the footprint specified in the schematic symbol?
As I just wrote in the bug report, footprints are changed if that option is chosen.
EDIT: yes, if the user chooses to match by refdes, path/UID of the footprint is updated so that it’s taken from the schematic symbol whose refdes is the same than the footprint’s refdes in the board.
@BobZ It seems you’re still having doubts.
The best way to overcome these is to start a dummy project in KiCad and experiment. Take a few resistors, transistors, ic’s and experiment with updating the PCB with different settings and try to understand what happens.
On the other hand, it’s difficult to experiment if it’s not know what exactly are the variables and use cases. I have played with an idea of explaining these things in a form of a tutorial with all reasonable use cases.
Hi, Paulvdh
I think it was in the bug report where I noted that did this experiment using my recent 5.99 version. I started with a simple test schematic and used it to drive a pcb layout. Then I duplicated that section of pcb, and tried to get it to synchronize with a duplicated section of schematic, both with edited reference designations which appeared to agree. I confirmed a big difference in results depending upon the two check box options. However, here I am responding to Eelik and want to understand his explanation as clearly as possible. It seems that this process is difficult to explain clearly for some reason.
I think that Eelik’s explanation is the best that I have seen so far. The other thing is that this is not all about me using KiCad. Given the mechanics of this, it is not so difficult or time consuming to simply try both methods. But if a relative software idiot like me can understand the explanation then I hope I have helped to improve KiCad.
EDIT: I should add that at the time when I performed the test, the wording of the checkbox options in 5.99 was completely confusing. “Reference” did not always refer to “reference designation” (which was my assumption) and only one of the two options said anything about “matching”; this disagreed with the explanations which were offered. I had no information about path or UID. So I think that the “air has been cleared” substantially.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.