Zone filling algorithm doesn't include pads

[Manveru]

I have a board design almost finished, and I am fighting against zone filling - I think is a bug it at least one of two different areas of the program, depending I am right or not.

My board has connectors with through pads and there is a GND zone underneath at ground layer. However lot of GND pads does not receive thermals in the filling process. Examples on attached board: P8.6, P8.8, P6.3, P11.6, P10.8, P10.6; while the following pads are connected through thermals: P12.1, P7.1, P6.1, P1.1 (these are square pads).

I see following possibilities:
- Because these pads may be connected to the GND through another track, they are excluded WITHOUT WARNING from zone filling.
- Because of my settings these shapes cannot be connected by thermals in zone filling, but I HAVEN'T BEEN WARNED something is wrong.
- Zone filling has a bug, and these pads are not connected accidentally. DRC did not complain about anything unconnected, but from other bugs I know that I cannot trust that in case of zone filling (am I wrong?)

However, regardless of suspicions expressed above, I need these thermals for ALL GND PADS irrespective of fact they're connected through track or not.

[Alain Portal (alain-portal-univ-montp2)]

I don't think this is a zone filling problem.
The problem is that pads are defined only on 2 layers, "front" and "back", and not on "ground" and "power"

[Manveru (manveru)]

@Alain: If your statament is true, it does not explain why some pads HAVE thermals? They are pads created same way as others. Almost all these connectors on the board are designed by me according to manufacturers' specifications.

[jimepa (jimepa)]

I found some problems with zone filling using components creates in previous versions of kicad. I solve this problem loading the component in the current library editor and then saving againg. Could you try it?
Regards

[Japie Greeff (japieg)]

I responded in the kicad-users group as well. This does seem to be a bug of some description, as the "Ground" layer
seems to be associated with the "Mask-back" layer in the pad stack. The workaround is to just edit the pad you want
to connect to the ground layer and enable the "Mask-back" layer for the pad by selecting the tick box, but that is
obviously not a solution to the problem - just a workaround. I am attaching the modified board for reference.

Regards

[Alain Portal (alain-portal-univ-montp2)]

Le mardi 19 juillet 2011 10:32:31, vous avez écrit :
> @Alain: If your statament is true, it does not explain why some pads
> HAVE thermals?

You're right, I don't understand the difference.

> They are pads created same way as others. Almost all
> these connectors on the board are designed by me according to
> manufacturers' specifications.

Are you sure you draw all these connectors?
--
La version française des pages de manuel Linux
http://manpagesfr.free.fr

[Manveru (manveru)]

I take my hat off to Japie Greff. Independently from the original problem he solved another problem with my boards (and footprint I designed). More appreciations in the e-mail on the mail-list.

I am little bit puzzled with that, because my Ground layer is the second layer, and through hole have pads on both sides - I do not understand why mask layers present over front and bottom layers matters for the zone filling.

The problem that behavior for zone filling is not explained in documentation. At least not mentioned in chapter about zone filling. No other warnings during zone filling process or zone filling configuration or DRC.

[jean-pierre charras (jp-charras)]

There is no bug, just broken footprints:
As Alain Porta wrote:
The problem is these pads are defined only on 2 layers, "front" and "back", and not on "ground" and "power"
(In other words, they aredefined not on internal layers, so they cannot have thermal.
These connectors are broken, because with Pcbew you cannot define a pad that is only on both external copper layers, and not on internal layers.
These footprints seem imported from a broken library and not designed with Pcbnew.
All broken pads of these footprints must be edited by Pcbnew to correct layers definition.
(When you click on broken pads, layers definition displayed on bottom of screen is "Back,front" and should be "Back,front & int".

[Jerry Jacobs (jerkejacobs-deactivatedaccount)]

These are possibly converted from EAGLE with the ULP script, or designed with the online php footprint wizard.

[Manveru (manveru)]

@Jean-Pierre: I do not remember "Internal" option, however it is not important at the moment. I would like to see an explanation why enabling bottom mask on pads during board design fixes the situation? Does the process of pads editing silently enable the "internal" layer of theses pads???

In such case I think some warnings about such parts shall be added. The warning shall become active when "bad" pads are added to the library or from DRC when they are used in the board and zones on internal layers are in force.

I try to imagine through hole pads not needing internal layer, and I can only imagine mounting holes at this moment. Some parts on my board come from eagle converted libraries, but I am trying to apply some corrections to them - it seems that not everything is properly propagated.

Do you thing is it possible?

[Dick Hollenbeck (dickelbeck)]

On 07/20/2011 03:38 PM, Manveru wrote:
> @Jean-Pierre: I do not remember "Internal" option, however it is not
> important at the moment. I would like to see an explanation why enabling
> bottom mask on pads during board design fixes the situation? Does the
> process of pads editing silently enable the "internal" layer of theses
> pads???

There is a layer mask associated with pads in the Kicad data file format. That
layer mask is set to a few variations only. The layer mask UI is not fully
general, it is limited. It does not give you all options for every internal
layer, in the sense of a full padstack, like you might find on other software.

I don't know how else to say it. The conversion program simply needs to be
updated to set all bits in the layer mask when appropriate, since Kicad does not
support all bit combinations in the layer mask.

For copper layers, IIRC, you can have

1) top only.
2) bottom only
3) top & bottom and all internal bits (layer mask bits) on.

I don't believe any other choices are supported for copper layers in Kicad at
this time.

The specctra import and export code holds all this knowledge, and it is embedded
in other Kicad code elsewhere too. I don't claim to be fully accurate here from
mental data only. So trust, but verify.

Kicad does not expect to have bad layer masks, since it has no indication that
anybody other than itself was ever going to edit the files.

Dick

[jacobeluz (jacobeluz-gmail)]

The problem is with the component
when you create the component you mus define pin clearence (i use 5 mil ) so when the comonent is loaded to the board
it comes with the clearence
then you need to define in the area editing a good values for clearnce (i used 50 mils) width (50mils)
antipad 120mil and spoke 200mil
please look at P8

[Manveru (manveru)]

@jacobeluz: The problem has nothing to clearance of the component itself which inherits pads clearances from constraints of the board. If you read posting above carefully you would know that the problem is with pad stack definition for the component and the fact that KiCad does not warn users about potential problems in that area.

[Nick Østergaard (nickoe)]

This is clearly an old bug report that is invald and has always been.