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
