More trouble (pcbnew bug?) with filled zones

cal-linux · September 25, 2018, 8:44pm

Hi forum,

I continue to struggle with these filled zones; specifically, often enough, I draw the zone and it won’t fill. On a couple of occasions, I had to start with a smaller zone that did fill, and then make it grow (adding corners and manually editing). In the end, I brought the zones to the same area where it originally was refusing to fill, but then they were filling ok.

I brought the PCB to a “minimal” version. Here’s a screenshot:

This is the Properties dialog (after created, I select it and Edit):

With “None” or “Thermal Relief”, the zone won’t fill (when I close the dialog, it initially fills, but just like a “flash” on the screen — it disappears in like 0.2 or 0.3 seconds). With “Solid”, it fills, but it does not connect to the +3.3V pin. This is the Gerber output (using the gEDA Gerber viewer):

If this is not a bug, can someone shed some light on what I’m missing or doing wrong?

[ edit: forgot to mention — the SolderRight-pair is a footprint I created in gEDA pcb, and I imported it to KiCAD. It looks weird and all, but it does seem to work ok — not sure whether that may have to do with the filled-zone trouble ]

If it helps, this is the .kicad_pcb file (copy-n-pasted from the text editor):


  (general
    (thickness 1.6)
    (drawings 4)
    (tracks 0)
    (zones 0)
    (modules 2)
    (nets 5)
  )

  (page A4)
  (layers
    (0 F.Cu signal)
    (31 B.Cu signal)
    (32 B.Adhes user)
    (33 F.Adhes user)
    (34 B.Paste user)
    (35 F.Paste user)
    (36 B.SilkS user)
    (37 F.SilkS user)
    (38 B.Mask user)
    (39 F.Mask user)
    (40 Dwgs.User user)
    (41 Cmts.User user)
    (42 Eco1.User user)
    (43 Eco2.User user)
    (44 Edge.Cuts user)
    (45 Margin user)
    (46 B.CrtYd user)
    (47 F.CrtYd user)
    (48 B.Fab user)
    (49 F.Fab user hide)
  )

  (setup
    (last_trace_width 0.25)
    (user_trace_width 0.16)
    (user_trace_width 0.2)
    (user_trace_width 0.25)
    (trace_clearance 0.2)
    (zone_clearance 0.1)
    (zone_45_only yes)
    (trace_min 0.16)
    (segment_width 0.2)
    (edge_width 0.15)
    (via_size 0.635)
    (via_drill 0.4)
    (via_min_size 0.635)
    (via_min_drill 0.3)
    (uvia_size 0.3)
    (uvia_drill 0.1)
    (uvias_allowed no)
    (uvia_min_size 0.2)
    (uvia_min_drill 0.1)
    (pcb_text_width 0.3)
    (pcb_text_size 1.5 1.5)
    (mod_edge_width 0.15)
    (mod_text_size 1 1)
    (mod_text_width 0.15)
    (pad_size 4.4 4.4)
    (pad_drill 3.2)
    (pad_to_mask_clearance 0.2)
    (aux_axis_origin 0 0)
    (visible_elements FFFFFF7F)
    (pcbplotparams
      (layerselection 0x00038_ffffffff)
      (usegerberextensions false)
      (usegerberattributes false)
      (usegerberadvancedattributes false)
      (creategerberjobfile false)
      (excludeedgelayer true)
      (linewidth 0.100000)
      (plotframeref false)
      (viasonmask false)
      (mode 1)
      (useauxorigin false)
      (hpglpennumber 1)
      (hpglpenspeed 20)
      (hpglpendiameter 15.000000)
      (psnegative false)
      (psa4output false)
      (plotreference true)
      (plotvalue true)
      (plotinvisibletext false)
      (padsonsilk false)
      (subtractmaskfromsilk false)
      (outputformat 1)
      (mirror false)
      (drillshape 0)
      (scaleselection 1)
      (outputdirectory "/home/carlos/tmp/"))
  )

  (net 0 "")
  (net 1 GND)
  (net 2 +3V3)
  (net 3 /SCLK)
  (net 4 /SDA)

  (net_class Default "This is the default net class."
    (clearance 0.2)
    (trace_width 0.25)
    (via_dia 0.635)
    (via_drill 0.4)
    (uvia_dia 0.3)
    (uvia_drill 0.1)
    (add_net +3V3)
    (add_net /SCLK)
    (add_net /SDA)
    (add_net GND)
  )

  (module local:SolderRight-pair (layer F.Cu) (tedit 5BAA9A4B) (tstamp 5BB55473)
    (at 119.16 115.34)
    (path /5BA93102)
    (fp_text reference J2 (at -2.9 1.34) (layer F.SilkS)
      (effects (font (size 1.016 0.762) (thickness 0.127)))
    )
    (fp_text value "" (at -0.1016 2.3368) (layer F.SilkS)
      (effects (font (size 1.016 0.762) (thickness 0.127)))
    )
    (fp_line (start 5.9 -1.5) (end 5.9 4.5) (layer F.SilkS) (width 0.2))
    (fp_line (start -4 -1.5) (end -4 4.5) (layer F.SilkS) (width 0.2))
    (fp_line (start -4 4.5) (end 5.9 4.5) (layer F.SilkS) (width 0.2))
    (fp_line (start -4 -1.5) (end 5.9 -1.5) (layer F.SilkS) (width 0.2))
    (pad "" thru_hole circle (at 1.9 3) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
      (solder_mask_margin 0.0762) (clearance 0.254))
    (pad 1 thru_hole circle (at 0 3) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
      (net 4 /SDA) (solder_mask_margin 0.0762) (clearance 0.254))
    (pad "" thru_hole circle (at 1.9 0) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
      (solder_mask_margin 0.0762) (clearance 0.254))
    (pad 2 thru_hole circle (at 0 0) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
      (net 3 /SCLK) (solder_mask_margin 0.0762) (clearance 0.254))
    (pad "" smd oval (at 0.95 0) (size 3.4 1.5) (layers F.Cu F.Paste F.Mask)
      (solder_mask_margin 0.254) (clearance 0.254))
    (pad "" smd oval (at 0.95 3) (size 3.4 1.5) (layers F.Cu F.Paste F.Mask)
      (solder_mask_margin 0.254) (clearance 0.254))
  )

  (module local:SolderRight-pair (layer F.Cu) (tedit 5BAA9A52) (tstamp 5BB55465)
    (at 119.160001 109.340001)
    (path /5BA93126)
    (fp_text reference J1 (at -2.650001 1.269999) (layer F.SilkS)
      (effects (font (size 1.016 0.762) (thickness 0.127)))
    )
    (fp_text value "" (at -0.1016 2.3368) (layer F.SilkS)
      (effects (font (size 1.016 0.762) (thickness 0.127)))
    )
    (fp_line (start -4 -1.5) (end 5.9 -1.5) (layer F.SilkS) (width 0.2))
    (fp_line (start -4 4.5) (end 5.9 4.5) (layer F.SilkS) (width 0.2))
    (fp_line (start -4 -1.5) (end -4 4.5) (layer F.SilkS) (width 0.2))
    (fp_line (start 5.9 -1.5) (end 5.9 4.5) (layer F.SilkS) (width 0.2))
    (pad "" smd oval (at 0.95 3) (size 3.4 1.5) (layers F.Cu F.Paste F.Mask)
      (solder_mask_margin 0.254) (clearance 0.254))
    (pad "" smd oval (at 0.95 0) (size 3.4 1.5) (layers F.Cu F.Paste F.Mask)
      (solder_mask_margin 0.254) (clearance 0.254))
    (pad 2 thru_hole circle (at 0 0) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
      (net 1 GND) (solder_mask_margin 0.0762) (clearance 0.254))
    (pad "" thru_hole circle (at 1.9 0) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
      (solder_mask_margin 0.0762) (clearance 0.254))
    (pad 1 thru_hole circle (at 0 3) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
      (net 2 +3V3) (solder_mask_margin 0.0762) (clearance 0.254))
    (pad "" thru_hole circle (at 1.9 3) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
      (solder_mask_margin 0.0762) (clearance 0.254))
  )

  (gr_line (start 100 128) (end 100 100) (layer Edge.Cuts) (width 0.15))
  (gr_line (start 128 128) (end 100 128) (layer Edge.Cuts) (width 0.15))
  (gr_line (start 128 100) (end 128 128) (layer Edge.Cuts) (width 0.15))
  (gr_line (start 100 100) (end 128 100) (layer Edge.Cuts) (width 0.15))

  (zone (net 2) (net_name +3V3) (layer F.Cu) (tstamp 0) (hatch edge 0.508)
    (connect_pads no (clearance 0.1))
    (min_thickness 0.2)
    (fill yes (arc_segments 16) (thermal_gap 0.2) (thermal_bridge_width 0.2))
    (polygon
      (pts
        (xy 115.19 107.83) (xy 124.96 107.83) (xy 124.96 107.97) (xy 125.04 108.05) (xy 125.04 119.61)
        (xy 124.79 119.86) (xy 115.31 119.86) (xy 115.16 119.71)
      )
    )
  )
)

Thanks,
Cal-linux

Rerouter · September 25, 2018, 8:52pm

Your footprints have an odd soldermask smd pad. I would try removing that first

The way to implement the uncovered copper in kicad would be a polygon on the soldermask layer

Joan_Sparky · September 25, 2018, 8:53pm

Can you attach the footprint file for the SolderRight-pair?
This part worries me:

Also the footprint at best should be 2 pads, max 3 pads, for what you’re doing there.

PCB_Wiz · September 25, 2018, 8:58pm

Yes, that looks rather suss…
Only one pin is 3v3 tagged, and the final fill looks a lot like it has cleared to the ‘bridge’ which I suspect thus lacks any 3v3 net tag.
ie fill has done exactly the correct thing, when given wrong information.

cal-linux · September 25, 2018, 9:45pm

Well, the SolderRight pins require a footprint like this one (well, technically, the manufacturer’s drawing only specifies the two holes; it says nothing about connecting them, one way or the other). Also, I created the footprint for a “two-positions” connector, as I have no plans to use those terminals for a single wire.

For example: https://www.digikey.ca/short/jw13t3 (not sure whether this is the same size as the footprint I have).

In any case, the footprint after importing it to KiCAD footprint editor and saving:

(module SolderRight-pair (layer F.Cu) (tedit 5BA93046)
  (fp_text reference "" (at -0.1016 1.016) (layer F.SilkS)
    (effects (font (size 1.016 0.762) (thickness 0.127)))
  )
  (fp_text value Val** (at -0.1016 2.3368) (layer F.SilkS)
    (effects (font (size 1.016 0.762) (thickness 0.127)))
  )
  (fp_line (start -4 -1.5) (end 5.9 -1.5) (layer F.SilkS) (width 0.2))
  (fp_line (start -4 4.5) (end 5.9 4.5) (layer F.SilkS) (width 0.2))
  (fp_line (start -4 -1.5) (end -4 4.5) (layer F.SilkS) (width 0.2))
  (fp_line (start 5.9 -1.5) (end 5.9 4.5) (layer F.SilkS) (width 0.2))
  (pad "" smd oval (at 0.95 3) (size 3.4 1.5) (layers F.Cu F.Paste F.Mask)
    (solder_mask_margin 0.254) (clearance 0.254))
  (pad "" smd oval (at 0.95 0) (size 3.4 1.5) (layers F.Cu F.Paste F.Mask)
    (solder_mask_margin 0.254) (clearance 0.254))
  (pad 2 thru_hole circle (at 0 0) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
    (solder_mask_margin 0.0762) (clearance 0.254))
  (pad "" thru_hole circle (at 1.9 0) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
    (solder_mask_margin 0.0762) (clearance 0.254))
  (pad 1 thru_hole circle (at 0 3) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
    (solder_mask_margin 0.0762) (clearance 0.254))
  (pad "" thru_hole circle (at 1.9 3) (size 1.905 1.905) (drill 1.0668) (layers *.Cu *.Mask F.SilkS)
    (solder_mask_margin 0.0762) (clearance 0.254))
)

Thanks,
Cal-linux

Joan_Sparky · September 25, 2018, 9:50pm

Ok, so 2 PTH pads will do.
One being an oval pad with a circular hole at one center (see screenshot) and another hole at the other center layed on top of it (pad #2 in the screenshot).

cal-linux · September 25, 2018, 9:52pm

I’m not sure where exactly you’re flagging a potential problem — should the pin that touches pin 1 (and simiarly for pin 2) also be labeled pin 1 in the footprint file? (it is intended to be connected — if you see the image of the terminal, you’ll notice it has two soldering points, but it is a single metallic piece – i.e., all electrically connected as one point)

In any case, hopefully the link to the terminal’s image (and documentation) and the footprint file may clarify and you can confirm whether there’s an issue with the footprint.

Thanks,
Cal-linux

Rene_Poschl · September 25, 2018, 10:08pm

This is missing at least one line. The footprint file format starts with a tag called footprint that includes the timestamp and footprint name.

Anyhow if you have overlapping pads they need to have the same pin number assigned. So both through hole pads and the smd pad need the same number.

The reason for this is this: How does KiCad know which symbol pin represents which pad of the footprint?
If two overlapping pads have differing pin numbers then they get different nets. Especially empty pad numbers always get a special net assigned that is unique to that pad. (This ensures that pads with empty pad numbers are never connected to anything)

Your tht pads have silk enabled which is a bit strange. Is this on purpose? I would also guess that you do not need paste on the smd pad.
Here my take of the FP. Note that i did not check the footprint outline and courtyard. (This privilege is reserved for contributions to the official lib )

cal_linux_fp.kicad_mod (1.3 KB)

PCB_Wiz · September 25, 2018, 10:12pm

Yes - see the nice post + images above by Joan_Sparky - the best way to join 2 holes is to make an offset-oval finger, to get 1 hole + connection, and then add another pad, round, same number, for the second hole.

A netlist import, will auto-tag all pins of the same number to the net, and it will also pass DRC

cal-linux · September 25, 2018, 10:17pm

Incidentally, it wasn’t (I mean, “yes and no”). I thought I had missed the first line when copy-n-pasted; but no, the line was there: it’s just that the triple-back-quote has to be alone in one line (I had put the (module ··· right after the three back-quotes).

I can’t really say — it wasn’t on purpose in the original gEDA footprint; I just went to KiCAD’s footprint editor, clicked the toolbar button “Import footprint” and selected the .fp gEDA file; it just came out like this. It looks weird, but I generated Gerber files and they looked ok to me, so I didn’t worry.

I guess I need to read up a bit on the conventions and guidelines for creating custom footprints.

Are there any written guidelines for importing gEDA footprints? I’ve imported a few, and they always end up with a weird look once in KiCAD; but I check the functionality and they seem (to me) fine.

Thanks,
Cal-linux

cal-linux · September 25, 2018, 10:43pm

Ok, so we sort of found the culprit in this particular case; I fixed the footprint (in any case, assigned the two TH pads and the oval SMT pad to the same pin number), and it now works only when the zone is configured with Default pad connection = Solid or THT_thermal. I guess the “plain” thermal only makes connection to SMT things, but: why won’t it work (why won’t it fill) if I set Default pad connection to “None”??

I guess I’m a bit frustrated with the detail that pcbnew does not inform the user about the reason why it won’t do something (I know this is a tricky feature to implement). But there are so many potential subtle and “hidden” reasons why it won’t do something, it makes sense that it tells the user).

This particular instance, I could bring to a “minimal” board to post the question; but I’ve had many instances where it just won’t fill the zone — sure, I know: new user working through my lack of knowledge of the little details. Still, it is very frustrating that this absolutely awesome feature (filled zones) seems to be so finicky that so far in a non-negligible fraction of the cases I’ve just given up and resorted to fill a zone with a ton of traces

Cal-linux

Rene_Poschl · September 25, 2018, 10:48pm

Pad connection none means “make no connection to pads unless the pad it self overwrites this setting”

Rene_Poschl · September 25, 2018, 11:03pm

I just did the test. KiCad tells you whats wrong. There is a tool called DRC. Run it and it will complain with your original footprint:

cal-linux · September 26, 2018, 12:05am

Ok, that’s a fair point (I actually had seen the tool — but I somewhat associate that tool with something that I would run when I complete the routing).

Cal-linux

cal-linux · September 26, 2018, 12:18am

I don’t understand this one — isn’t the fact that the zone gets filled independent of whether it connects or not to pads? The setting tells me: “How does the zone connect to the pads of its same net?” The setting solid tells me that it connects with a solid contact; none tells me that it does not connect (i.e., leave the full clearance around that pad), not that it won’t fill.

I’m guessing (inferring) that maybe an underlying principle with filled zones is that they only materialize if they’re needed (i.e., if there is contact to some element of the net associated to the zone), unless the zone is assigned “no net” (I just tried creating a “no net” zone in the middle of nowhere, and it does fill — as soon as I change the setting to one of the nets available, then the zone (the filling) disappears).

Is my guess/interpretation correct? (maybe I just need to RTMF? or possibly the other way around? )

Thanks,
Cal-linux

eelik · September 26, 2018, 6:27am

Actually not. You are right in your explanation: a zone gets filled only if it’s connected to a pad with same net. Like it or not. There have been situations when I have hoped it wasn’t so, but in the end it’s reasonable and doesn’t matter because there’s no point in adding a zone into a net unless it’s connected to the other parts of that net. So, it really shows you there’s still an unconnection problem in your board when it doesn’t fill.

cal-linux · September 26, 2018, 12:52pm

Why would one not like it? Since we have the option to set the zone to “no net” and in that case it does fill and connects to nothing else, I see no reason whatsoever to dislike the behaviour; on the other hand, it is reasonable for the software to “complain” if the user states the intent of something and that something does not happen (setting a zone to a particular net declares the intent of connecting the zone to that net).

However, I’m noticing inconsistencies in the behaviour (again, unless there are other factors I’m missing or misinterpreting):

A zone with Default pad connection set to None still connects to traces. Although this by itself is not questionable, I think the inconsistency is. (I guess the name “pad connection” suggests that the setting applies to pads and to nothing else; but I think this is inconsistent: the setting should control connection to all other things that can be part of a net, and not exclusively to pads)
A “compound inconsistency”: the zone connects to traces, but it does not connect to another zone of that net that has Default pad connection set to Solid (i.e., the zone does not fill / materialize even if it is overlapping with another zone of the same net, and that other zone is filled). Not sure whether “by definition” a zone is a pad (one with an arbitrary shape), and that explains this aspect — if that is the case, I would claim that is extremely odd from the point of view of the user.

In case I’m observing these behaviours because I’m doing something wrong, here’s a screenshot showing the behaviours:

The zone below (touching CDB13’s pins) is set to GNDD with Default pad connection set to None. The one above, touching CU13’s pins is set to GNDD with Default pad connection set to Solid (just verified them, after capturing screen and pasting here).

Also: you mention that the “None” in the zone can be overriden by a pad setting — that does not seem to work for me. In the image above, if I edit pin 2 of CDB13, under the “Local Clearance and Settings” tab, I set
Pad connection to Solid, the zone still does not fill. Is this not what you were referring to? And if so, shouldn’t it make the zone fill/materialize?

EDIT: Related to this last paragraph: if I drag the zone a bit further down so that it touches the trace connecting to pin 2 of CDB13, then the zone does fill and makes a solid connection to pin 2 of CDB13. At this point, now the pin “connection to zones” setting does have an effect.

However, this brings me to another quirk/misbehaviour (bug?): say that we have a setting S of element X that affects zone Z. If I change S in a way that causes Z to change, Z will not change until I edit the zone! (for example, in the above figure — I change the “Local clearance” settings of pin 2 of CDB13 to change its “Pad connection” to none , and the zone is still connected. If I select the zone and edit it, even if I change nothing, as soon as I close the dialog, now the zone draws correctly (or in this example, the zone “unfills”).
However, the reason why I didn’t call it a bug: the software seems to properly keep track of this; I just tried generating the Gerber files, and I immediately get a pop-up dialog asking me: “The zones are out-of-date. Refill them?”. Still, it is, at best, a quirk/misbehaviour.

Thanks,
Cal-linux

eelik · September 26, 2018, 12:54pm

Because it’s confusing if you don’t know or remember it. Nothing else.

Rene_Poschl · September 26, 2018, 12:59pm

You have a misunderstanding about the usecase for this feature. It is not really intented to replace no net zones. But its main intention is controlling which parts should be connected to the zone.

For me these usecases come to mind:

The zone is set to “pad connection None” and single footprints (or pads) overwrite it -> this is for when you only want to connect a small percentage of your footprints (or pads) to the zone.
The zone is set to “pad connection None”, You use traces to connect the pads to the zone. Use this if you are not happy with the options provided by the thermal vias or solid settings and want closer control how the pad is connected
The zone is set to thermal or solid but some footprints (or pads) are set to None -> This is when some special footprints (or pads) should not connect to the zone.

These options are there for people with special thermal or EMC requirements that can not be fulfilled by the default options provided by kicad.

cal-linux · September 26, 2018, 1:32pm

Ok, I guess I was overlooking this combination. It may also be useful to control ground loops, or to enforce particular decoupling techniques (the connections geometry). Which is precisely what I’ve been dealing with when I got puzzled by these aspects.

However, this still seems to introduce the inconsistency that I cannot do the same with traces. For example, in the figure above, I may want to force the GNDD connection of pin 2 of CDB13 to take an “isolated” route (for ground loop control, specific decoupling technique, etc.). I should be able to set the zone to solid or thermal, and then set this pad to None; however, the zone will essentially connect to the pad, since it will connect to the trace that touches the pad (especially if the zone is set to “Solid”).

I can understand the benefit of using traces to come up with one’s custom thermal relief. But then, for consistency, the traces (and vias!) should have the “Zone connection” override configurable, as pads do (i.e., I should be able to set a zone to “Solid” or “Thermal” and then set traces to “None” so that the zone does not connect to a particular trace. In fact, the default should be that the zone with Default pad connection set to None does not connect to a trace (I admit that this may come from my being used to the way copper zones work in gEDA pcb, where copper zones simply do not connect to traces; I remember even trying the hack to set a trace’s clearance to zero, and gEDA pcb would still leave a thin gap :-\ ).

Thanks,
Cal-linux