On 14.12.2015 14:40, Strontium wrote: > Hi Thomas, > > I considered this, but tracking zones is non trivial. > > For example, imagine the stackup: > > GND > VCC > GND > VCC > > A Through Via, from top to bottom could be connected validly connected > to either GND or VCC. > > Once the net is removed from the via by the reassignment pass, there is > no longer any information left to tell kicad which pair of zones was > connected by the via.
Indeed, in case of such a conflict retaining the via's net is IMHO the only good solution. > > The approach I suggest will fix this problem, because it just wont > change the net for those vias. It wont consider if there is a zone or > not, it just says "hey, you gave it the GND net, so i will leave it as > GND." It also seems Altium is managing via's nets this way. I would vote for merging the patch. Cheers, Tom > > > On 14/12/15 21:21, Tomasz Wlostowski wrote: >> On 12.12.2015 02:41, Strontium wrote: >>> This change should not break or modify any current behaviour, EXCEPT to >>> retain the nets of tracks/vias which Kicad is otherwise incapable of >>> determining automatically. >> Hi Steven, >> >> Thanks for the patch, it also (partially) fixes the via stitching issue >> many people have been complaining about. The origin of the problem is >> that the net propagation code does not take zones into account - so a >> via that is not connected to any pad with a chain of tracks is treated >> as disconnected. >> >> Adding zone support in the net calculation code should AFAIK fix this >> for good, but it may also require enhancing the DRC (so that it will >> report every object with no pad connection) and the 'clean tracks&vias' >> tool code. >> >> Regards, >> Tom >> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp