kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Is this malformed pad actually caused by KiCad or is it possible this
was cause by a script or manual editing?  If it was caused by KiCad then
we need to figure out how this was allowed to happen and fix it.

Wayne

On 06/23/2018 02:54 AM, jp charras wrote:
> Le 22/06/2018 à 21:54, Andrzej Wolski a écrit :
>> No, this IS an error in the board :)
>> If you open pad properties and click OK, it won't let you save it as is, you will have to enable
>> copper layers.
>> NPTH pads also HAVE TO exists on copper layers (I don't understand why, but they do).
> 
> Just because they *are* on these copper layers, regardless the hole has removed the visible copper area.
> 
> A pad is not only a copper area. It also define a clearance area, that is not necessary the hole area.
> If you say: this pad is not on this copper layer, it means you have no obstacle to draw a track.
> This is obviously false: the hole in on this layer.
> 
> If a NPTH is removed from copper layers (malformed pad), the PnS router will happily route a track
> crossing the hole, because it is the mathematical result of "this pad is not here".
> You can think: there is a bug in PnS router.
> But the Truth is the pad is broken and has incorrect layer setting, therefore incorrect routing
> constraints (and incorrect fill zone param).
> 
> Therefore regardless the GAL fix, the malformed pad (like any malformed item) need a fix when
> reading the file, because it this king of issue can create problems, even crashes.
> 
> Of course, the GAL draw issue needs also to be fixed: it must show the hole, even for malformed pads.
> 
>>
>> Also, as I already mentioned, current GAL behavior is different from 4.0 GAL and legacy, so this is
>> a regression.
>>
>> Andrzej
>>
>> W dniu 2018-06-22 o 21:44, Seth Hillbrand pisze:
>>> Ah.  This is not an error in the board.  This is just an NPTH.  If you click on it in GAL, you
>>> will see it.
>>>
>>> I think the correct patch to this should check the pad type instead of drawing one with no layers.
>>>
>>> -S
>>>
>>> Am Fr., 22. Juni 2018 um 12:33 Uhr schrieb Andrzej Wolski <awolski.kicad@xxxxxxxxx
>>> <mailto:awolski.kicad@xxxxxxxxx>>:
>>>
>>>     IIRC you have to leave (layers) to reproduce this.
>>>
>>>     This is a board where I found the issue:
>>>     https://github.com/mntmn/reform/blob/master/electronics/reform-motherboard.kicad_pcb
>>>     There are two mPCIE connectors in the center, they have NPTH alignment holes, you can see them
>>>     in legacy mode.
>>>
>>>     Andrzej
>>>
>>>     W dniu 2018-06-22 o 20:06, Seth Hillbrand pisze:
>>>>     Andrzej-
>>>>
>>>>     I just tested this, editing a file to remove the layers from a pad and KiCad automatically
>>>>     adds the pad back to all copper layers.  I see the pad in pcbnew and can edit it.
>>>>
>>>>     Can you provide a board that demonstrates the issue?  Maybe it was only the test board I used?
>>>>
>>>>     -S
>>>>
>>>>     Am Fr., 22. Juni 2018 um 10:51 Uhr schrieb Andrzej Wolski <awolski.kicad@xxxxxxxxx
>>>>     <mailto:awolski.kicad@xxxxxxxxx>>:
>>>>
>>>>         Hi Seth,
>>>>
>>>>         current behavior is that malformed pad holes are always hidden, so you can't see on the
>>>>         screen something that exists on your PCB and will be plotted in drill files. This patch
>>>>         makes those holes visible.
>>>>
>>>>         Andrzej
>>>>
>>>>         W dniu 2018-06-22 o 17:46, Seth Hillbrand pisze:
>>>>>         ​Andrzej-
>>>>>
>>>>>         Can you explain the issue that this patch addresses?  I read the commit message but it
>>>>>         looks like malformed pads (GetLayerSet().any() == 0) are no longer hidden.  This seems
>>>>>         counter-intuitive but maybe I'm just not seeing the problem.
>>>>>
>>>>>         Thanks!
>>>>>         Seth​
>>