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
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
