Changing footprints in middle of automatic assignment?

[ringo458]

Hi, I decided to change the footprint of a 16 pin header from the (UL or SNAPEDA) supplied one to the system library version. So I went into the interface and found the lib I wanted and used double click to paste it over the SAMTEC footprint. No schematic change. When I went to the PCB reconcile step it threw a bunch of errors and 2/3 of my ratlines were missing. I reassigned the pins manually and then stupidly ran the PCB update again and again it threw errors and lost my edits.
So then I thought of removing those parts from the schematic first so I removed them from the PCB and the schematic. then put the symbols back. I went to the assignment GUI and sure enough there was no assignment so I thought: well this ought to do it. I reassigned them ab initio to the desired footprints and ran the PCB update. Exactly the same outcome. I looked at all the text files to verify that contrary to the error message the desired footprint DOES have all the pads in there just like the SAMTEC footprint. Here is the place where you see it go South:

I do not understand why it changes it back, and then even after it changes it back it should not matter because both mod files have the same 16 pads. In fact, on the PCB I can see that all the graphics are appropriate for the new (desired) footprint from the big library, but as you might expect many ratlines are missing:

I used AstroGrep to look through all the files to find the string “MTLW” which pertains to the footprint that I don’t want but I can’t quite see why it wants to remember the old footprint and then does the wrong thing. I don’t think the evidence is in the files, I think that at some point it over-rides the assignment with a choice that is based on the filename because there is a file in the cache that has the same name as the part. My last attempt will be to remove that from the cache and see what happens.

[ringo458]

FYI I removed the SAMTEC footprint from the local footprint cache and it made no difference Now I will try renaming some strings.

[eelik]

Update PCB from Schematic's match methods

Updating an existing layout from its schematic requires KiCad to determine which footprint was previously connected to which symbol to avoid undoing your past work. For this reason every symbol is assigned a unique identifier (timestamp based unique ID). This ID is also tracked by the footprint instance. The alternative option is to use the reference designator assigned to your symbol either by the annotation process or by hand. Using the ID allows, changing the reference designator of a symbol…

[ringo458]

Thanks for your speedy reply. I don’t understand how it explains the fact that I removed the header from the schematic and the PCB and saved both files. At that point, since they are both just flat files, I would expect that those parts have ceased to exist in those files. Then I should have been able to add in first the symbol, as if from scratch, then make the assignment, then update the PCB. Since the libraries and footprints are presumably read-only, that means that the codes you mention must be in the pcb files and possibly the sch files. Or does this happen with the assistance of the BAK files?

Also I don’t understand why it breaks in the middle since both footprints have 16 explicitly named pads.

[ringo458]

The problem is resolved. The library footprint:

(module PinHeader_2x08_P2.54mm_Vertical (layer F.Cu) (tedit 59FED5CC)
(descr “Through hole straight pin header, 2x08, 2.54mm pitch, double rows”)
(tags “Through hole pin header THT 2x08 2.54mm double row”)

Has pads labeled with 1 digit for the first 9 pins and the SAMTEC has two digits:

(fp_line (start 4.35 19.55) (end 4.35 -1.8) (layer F.CrtYd) (width 0.05))
(fp_line (start 4.35 -1.8) (end -1.8 -1.8) (layer F.CrtYd) (width 0.05))
(pad 1 thru_hole rect (at 0 0) (size 1.7 1.7) (drill 1.0) (layers *.Cu *.Mask))
(pad 2 thru_hole oval (at 2.54 0) (size 1.7 1.7) (drill 1.0) (layers *.Cu *.Mask))
(pad 3 thru_hole oval (at 0 2.54) (size 1.7 1.7) (drill 1.0) (layers *.Cu *.Mask))

VS SAMTEC:

(module SAMTEC_MTLW-108-07-G-D-190 (layer F.Cu) (tedit 5F30391C)
(descr “”)
(fp_text reference REF** (at -7.985 -4.685 0) (layer F.SilkS)
(effects (font (size 1.0 1.0) (thickness 0.015)))
)
.
.
.
(xy 8.725 -2.11)
) (layer F.Mask) (width 0.01)
)
(pad 01 thru_hole circle (at -8.89 1.27) (size 1.52 1.52) (drill 1.02) (layers *.Cu *.Mask))
(pad 02 thru_hole circle (at -8.89 -1.27) (size 1.52 1.52) (drill 1.02) (layers *.Cu *.Mask))
(pad 03 thru_hole circle (at -6.35 1.27) (size 1.52 1.52) (drill 1.02) (layers *.Cu *.Mask))
(pad 04 thru_hole circle (at -6.35 -1.27) (size 1.52 1.52) (drill 1.02) (layers *.Cu *.Mask))
(pad 05 thru_hole circle (at -3.81 1.27) (size 1.52 1.52) (drill 1.02) (layers *.Cu *.Mask))

As soon as I put the leading zeros the problem went away.