kicad-developers team mailing list archive

[Dan Chianucci <trump211dev@xxxxxxxxx>]

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
<jp.charras@xxxxxxxxxx>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<kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-**developers<https://launchpad.net/%7Ekicad-developers>
> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>