Jean, I thought about this, and I agree with your first point. This patch has shortcomings in the fact that things like wire stubs and unwanted lone tracks will also have there net-codes updated and in turn might not be caught by drc.
I'll look into connecting the vias directly to a zone instead. Dick, There are a few bug reports related to this, specifically https://bugs.launchpad.net/kicad/+bug/593923 and https://bugs.launchpad.net/kicad/+bug/612133 (im not sure if this is the same thing or not) -Dan C On Fri, Apr 20, 2012 at 1:44 PM, jean-pierre charras <[email protected]>wrote: > Le 20/04/2012 16:05, Dick Hollenbeck a écrit : > > On 04/20/2012 05:57 AM, jean-pierre charras wrote: >> >>> Le 20/04/2012 10:24, Dick Hollenbeck a écrit : >>> >>>> With this patch, DRC recognizes that the vias are connected, and >>>>> doesn't complain at all >>>>> about them. >>>>> >>>> >>>> Dan& Tom, >>>> >>>> Please re-test the revised patch, which has a better chance of being >>>> committed if it still >>>> works. >>>> >>>> And Dan, if you are interested in learning about what was changed, you >>>> might apply this to >>>> a pristine testing checkout, then compare that branch to the other one >>>> you have now. >>>> >>>> >>>> Thanks, >>>> >>>> Dick >>>> >>> About this patch, if it fixes an issue, it creates some important others. >>> This is not only a matter of coding, this is the approach that creates >>> issues: >>> >>> 1 - Keep netcode when a track is not connected to a pad (or a track >>> connected to a pad) >>> can create not connected copper areas (floating copper zones). >>> This is the main drawback. >>> Note this could be fixed by a better code, but this is not fixed by the >>> patch. >>> The initial patch had this issue, and this is the main reason I did not >>> accept it. >>> ( Pcbnew removes all floating copper areas, and to do that, checks for >>> each copper area if >>> there is at least one track end inside the area, assuming all tracks are >>> connected to something ) >>> 2 - tracks that are *really* not connected keep also a netcode. I am >>> pretty sure this is bad. >>> 3 - If a zone has its net changed, the net of stitching vias are not >>> updated. >>> this is also an issue, because a board is usually modified and edited >>> during its life time. >>> >>> An alternate way could be: >>> when a track/via is created starting to a zone, it is linked to the >>> corresponding zone (the time stamp could be a good link) >>> If the full track is connected to a pad/track it is no linked to the >>> zone. >>> Therefore, when a zone is deleted, moved... the linked tracks can be >>> also updated, and keep their net. >>> And these tracks could be ignored by test functions which test floating >>> copper areas. >>> >>> >>> However because it is so easy to connect stitching tracks/vias to a pad, >>> I am not volunteer to write this code, just to spare 1 second of working >>> time of some users.. >>> >> >> >> Jean-Pierre, >> >> Thanks for looking at the patch. I did not commit it because I was not >> 100% sure it was >> conceptually solid, nor did I have enough time to delve deeper. >> >> But to be honest, normally I cannot even read C++ code that does not >> conform to our coding >> standards, since it sends my head into a fourth dimension. >> >> So that was simply a starting point, to make it readable. >> >> It is apparent that your time is valuable Jean-Pierre, and we appreciate >> you taking the >> time to look at it. >> >> Dan, is there a bug report for this, flagged as wishlist? >> >> I will add it to the bottom of my todo list. Being at the bottom could >> be temporary, >> because if I get bit by this, then it would elevate in a hurry. >> >> In the mean time, you can also contemplate a better solution, this time >> hopefully one that >> meets with the coding standards. I promise not to look at the next patch >> if it does not. >> >> I promise to fix this myself if it ever bothers me enough. This is >> where it stands from >> my perspective. >> >> At least we got a look at it from Jean-Pierre, who in shortest period of >> time was able to >> assess pitfalls. >> >> >> Dick >> > > I'll look at this patch. > I see an other solution, but I am not sure this is a better solution. > I have some ideas to fix issues that could be created by this solution. > > > -- > Jean-Pierre CHARRAS > > > > ______________________________**_________________ > Mailing list: > https://launchpad.net/~kicad-**developers<https://launchpad.net/%7Ekicad-developers> > Post to : > kicad-developers@lists.**launchpad.net<[email protected]> > Unsubscribe : > https://launchpad.net/~kicad-**developers<https://launchpad.net/%7Ekicad-developers> > More help : > https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
