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