kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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