PCBNew PCB References differ to schematic

[ADJohnson]

I’m in the middle of laying out a PCB and somehow the footprint references in PCBNew have changed from the references in the Schematic. E.g. in PCBNew I have footprint U8; in the Schematic it is U15. If I click on U8 in PCBNew, it highlights U15 in the schematic; if I click on U15 in the Schematic nothing happens (not sure if it should.) The netlist Path shown at the bottom of the PCBNew window matches the Unique Id of the component in the Schematic.

In PCBNew if I edit the footprint and change its reference from U8 to U15 it no longer highlights the part in the schematic when I click on it but the Netlist Path/Unique Id are still the same.

If I regenerate the netlist file and check it in an editor, it is defining the part with reference U8 and not U15.

I have lots of parts on my PCB that are affected. The references in the schematic should be the right ones, i.e. the part should be U15. Why it is referencing it internally as U8 I can’t figure out.

Basically, there is a mismatch somewhere and I don’t know where or how to fix it. Does anyone have any ideas?

[paulvdh]

First, making a netlist is pretty much deprecated in KiCad for several years now. The functionality is maintained for “unusual” workflows such as working with external scripts (such as SKiDL). The normal way these day’s is with Eeschema / Tools / Update PCB from Schematic [F8].

The RefDes (references) are not the normal way that the synchronization between Eeschema and Pcbnew is remembered. Each component has a “timestamp” (in KiCad V5.99 changed to UUID) and this is the normal way for synchronisation.

During updating of the PCB you can choose whether to use this default way, or to use the references to update the PCB, and you select this with the "Match Method during the update process.

Also:
Scan through the text in “Changes to be Applied” for, indeed, “the changes to be applied”

And if you have any doubt about what you’re doing, then make a backup first. When I’m working on a project and make significant changes, I usually make backups at least daily. It’s much easier to delete some backups then to go back if you do not have backups.

[ADJohnson]

Ok, I didn’t know that - I guess the ‘learning’ videos I watched where a little out of date.

Nonetheless, I have tried that dialog but it doesn’t affect anything on the PCB so it isn’t a route to fixing anything unfortunately. I edited the properties of the part in the Schematic and changed the reference field from “U15” to “U15” (yes, the same value), went into PCBNew and used that dialog - it does want to change the footprint reference from U8 to U15. So that’s one avenue I suppose: manually edit the hundred parts or so on my schematic to set their reference to the existing value.

If I look in the schematic file in a text editor then I can see this for a different part:

$Comp
L CustomSymbolLibrary:OPA4192 U3
U 1 1 601C9CEE
P 8800 3700
AR Path="/601C9CEE" Ref="U3"  Part="1" 
AR Path="/6011D101/601C9CEE" Ref="U10"  Part="1" 
F 0 "U10" H 8800 3950 50  0000 C CNN
F 1 "OPA4192" H 8800 4050 50  0000 C CNN
F 2 "Package_SO:SOIC-14_3.9x8.7mm_P1.27mm" H 8850 3400 50  0001 C CNN
F 3 "https://www.ti.com/lit/ds/symlink/opa4192.pdf?&ts=1589815702512" H 9050 3850 50  0001 C CNN
F 4 "3117605" H 8800 3700 50  0001 C CNN "Farnell Code"
F 5 "Texas Instruments" H 8800 3700 50  0001 C CNN "MFR"
F 6 "OPA4192ID" H 8800 3700 50  0001 C CNN "MFR Code"
	1    8800 3700
	-1   0    0    1   
$EndComp

Note the two AR Path statements which have a different reference: in my schematic, the part is U10; on the PCB it is U3.

For the part I manually changed to U15 (from U15) it looks like:

AR Path="/601CA0BC" Ref="U15"  Part="1" 
AR Path="/6011D101/601CA0BC" Ref="U15"  Part="1" 

So the two references are now in sync.

And now I have an idea about what might have happened. I started with a project with one sheet; then I changed it to have two hierarchical sheets and copied parts of the original sheet into one hierarchy and the remaining parts into another hierarchy then deleted the originals. The first AR path probably refers to the part as originally created and the second refers to it in the sheet (/6011D101 is the unique id of the hierarchical sheet.) There has been a re-annotation since I copied.

I don’t know which reference in the schematic is correct - should there be two entries for AR Path or just one? Is there a better way of fixing this than manually editing files/re-editing parts in the schematic?

[paulvdh]

You’ve bumped into one of the weak spots of KiCad.
In the current stable version (V5.1.x and older) cutting & pasting support is quite limited, and it looses both the reference and the timestamp value, and you have to manually repair the connection by setting the Reference (Refdes) in Eeschema and then use Math Method / (*) Re-associate footprints by reference during the update of the PCB.

In KiCad-nightly V5.99, soon (hopefully) to become V6, there is a “Paste Special” method that preserves this information.

[ADJohnson]

I’d need to make some change for the match method to work - nothing happens if I try it now because according to how that process works, there is no difference! With part U15, all references in the schematic file are U15:

$Comp
L Memory_EEPROM:CAT24M01W U15
*SNIP*
AR Path="/601CA0BC" Ref="U15"  Part="1" 
AR Path="/6011D101/601CA0BC" Ref="U15"  Part="1" 
F 0 "U15" H 13150 6500 50  0000 C CNN
...

In this case, your suggestion will change U8 on the PCB to U15. Other parts won’t be changed.

I think the AR Path entry is created when I did the copy and paste because the project had the same component in it elsewhere - however, on the re-annotation, it obviously didn’t change ALL references (Or something, I wouldn’t want to judge anything.) You can see the difference with part U3/U10 for the OpAmp component.

At a guess, I could remove all AR Path entries and ensure that the any reference Id matched on the L and F lines; alternatively I could manually edit each component in the schematic to its existing reference. Either way, that’s tedious and error prone.

I don’t suppose you know of a non-tedious way of achieving the same goal do you?

[ADJohnson]

In case anyone comes along later with a similar problem. In the end I took a backup of the schematic file and then opened it in a text editor. For every entry bounded by $comp and $EndComp:

• Removed the AR Path lines. NOTE: I don’t have any other similar parts elsewhere in my project so this is safe for me to do! Your mileage may vary: take a backup!
• Ensured that the reference designator in the line that starts L matches the one in the line starting F. I did not change the reference in the line starting F to match that in line starting L.
• Followed Paul’s advise above to refresh the PCB from the schematic. This then adjusted all the references on the PCB to match the schematic.

I’m still not sure exactly how this happened but it does seem to be related copying elements from a “top” sheet into a hierarchical sheet then deleting the components from the “top” sheet; I also re-annotated everything at some point.