Zone stitching vias don't have nets updated in v6

[Seth Hillbrand]

Importing an Eagle project from [1], version 5.1.x does well. There are no unconnected nets and the netnames are properly assigned to all items on import.

In version 6, there are 4 vias that stitch together two zones (no tracks connected). These keep an original net name from Eagle instead of being updated. The vias are then unconnected as are the two zones.

Additionally (not sure if it is related), performing an "Update PCB from Schematic" changes more items on the board.

I am attaching the KiCad projects that resulted from importing v5 as well as v6

[1] https://github.com/beagleboard/beaglebone-blue

[Jon Evans (craftyjon)]

Looks like this issue is in the PcbNew netlist importer; the two netlists generated by Eeschema in V5 and V6 are functionally identical. If I Use PcbNew V6 (master) and import the netlist generated by V5 I also get the disconnected vias.

[Seth Hillbrand (sethh)]

Thanks for checking that Jon! Sorry that I've been conflating the connectivity changes and maybe synchronous messaging? I'll have to spend the time on a bisect.

[Jon Evans (craftyjon)]

4d10183e may be relevant (I haven't checked yet)

[Jon Evans (craftyjon)]

I can't actually repro this, now that I finally got around to trying. I downloaded the board and manually reset all the relevant objects to be N$62 in the board, then ran the netlist import and it successfully updated to the new net name, including those 4 vias.

Seth, let me know if you have reproducible steps to make this happen and want help tracking it down.

[Seth Hillbrand (sethh)]

Hi Jon- I'll check later tonight. But the reproduction steps would be:

1) Clone the repo for BB Blue
2) Import the Eagle project
3) Fill zones in the pcb

This has left the 4 N$62 vias previously.

[Jon Evans (craftyjon)]

Ah, I see. It happens at import time and from then on you can't fix it by running the sch->pcb updater because we don't actually try to reconnect free vias.

[Jon Evans (craftyjon)]

OK, I have to stop looking at this for the night, but where I've gotten so far is that some of the pads do not seem to get valid nets from eeschema during the "remap nets" portion of Eagle import (building the info to pass to fixEagleNets). So, before the two calls to FetchNetlistFromSchematic, the relevant pads have net "N$62", and after the calls, they have no net (!)

So, that net never gets included in the map to fixEagleNets and doesn't get propagated to the zones/tracks/vias.

But, if you then run the update from schematic command manually, the associated pads *do* get updated with proper net names. Of course, at that point it's too late for us to be able to know that we should go and update the N$62 vias.

I'm not sure why the pads are not getting nets during those update calls, but that's the smoking gun to look in to.

[KiCad Janitor (kicad-janitor)]

Fixed in revision 10b0b18d8029fa480daec02ab176d8aa68194cd4
https://git.launchpad.net/kicad/patch/?id=10b0b18d8029fa480daec02ab176d8aa68194cd4

[Seth Hillbrand (sethh)]

Bisecting didn't help as it ran back to intersect with a different bug (null updater). So I just fixed it where I think it should happen.

[Jon Evans (craftyjon)]

I like your fix, this will also help in a few other edge cases where the netlist updater didn't work right previously.