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.
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
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).
3 Likes
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
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)
2 Likes
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
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
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
Pad connection none means “make no connection to pads unless the pad it self overwrites this setting”
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:
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
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
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.
2 Likes
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 connectionset toNonestill 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 connectionset toSolid(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
Because it’s confusing if you don’t know or remember it. Nothing else.
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.
1 Like
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
Hehehe — fair point!
Yes, that’s the important bit you missed.
Zones check traces/vias/pads, but not intersects with other zones, as that is very calculation intensive.
Zones also automatically discard unconnected / floating copper, and that can give the appearance of ‘nothing happened’, if the connection check to traces/vias/pads finds nothing.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.