I think this is intended. It enables the creation of very complicated pad shapes by overlaying multiple pads with the same pin number. (yes i know you have two different components here but i fear this is a necessary side-effect to enable what i mentioned here.)
In this case you should use the courtyard layers. But at this moment courtyard violations are not checked automatically. (but the human brain is quite good at seeing stuff like that.)
Information on how kicad works behind the curtains (how does drc work):
However, I do not see the connection between complex pad shapes, fill zones and pad to pad clearance. I assume you mean component pad shapes and I think it should be possible to draw them as polygons in the footprint editor. It is showstopper for me for doing more complex boards if I have to do a manual DRC for same net pads.
And regarding the thread you linked to. I have been using Mentor PADS for 10+ years now and this $$$ program is just as riddled with quirks and workarounds as KiCad is at the moment. We do however the have the possibility to get things fixed with KiCad. The canvas switching is faster than PADS for instance where you have to switch programs for different tasks and that is not even considered an issue but for KiCad it is just a transition phase.
I have just started using KiCad and I am very pleased so far.
Not supported by kicad. (at least not at this moment. maybe someone will add this later.)
The connection is that kicads drc does not care if stuff that has the same net overlaps. (it does not know to which component the pad belongs)
So if you want to enable the complex pad shapes, you need to live with this.
By the way: component overlap should be checked with the courtyard. (having pads only as far apart as the minimum clearance means you can not assemble the board.)
So what is really needed? In my opinion an automatic courtyard overlap check.
I would rather see courtyard checking implemented.
Having a nice way to design complicated pads would also be nice.
Another thing is via stitching (currently only possible with workarounds.) But i have read on the mailing list that this should be possible in version 5. (I think i also read somewhere that a prerelease can be expected early this year.)
If I select a pad and rightklick I can select “Associate” and select the copper shape. This shape will now be treated as a regular component pad and have to obey same net pad clearance.
EDIT: This is a screencapture of the footprint editor.
From a users perspective you are right.
From a programmers perspective: It depends on how the data structures within the back-end work. (I fear kicad’s data structure does not support something like that at the moment.)
Seconded, several times I have placed components too close, although this is sometimes due to the courtyard being wrong. It looks like much more care has been taken with the pads than the silkscreen and courtyard layers
I have come across footprints in the standard KiCAD libraries with silkscreen placed on top of bare copper. Some board fabricators will put a job on hold when they find this; others build it “as specified” (GIGO); and some tolerate it but remove all cases of silk-on-copper, leaving behind illegible or ratty-looking outlines and designators.
Across the whole industry, all the layout programs I have seen gave a lot more care and attention to the connection pads in their standard library parts rather than silkscreen, and courtyards were a distant third. (If standard libraries included them at all. They ARE affected by the type of automatic placement machinery being used.)
I had a look in the source and found out that the drc deliberately skips the test if pads are of the same net.
in drc.cpp
// The pad must be in a net (i.e pt_pad->GetNet() != 0 ),
// But no problem if pads have the same netcode (same net)
if( pad->GetNetCode() && ( aRefPad->GetNetCode() == pad->GetNetCode() ) )
continue;
I have tested commenting out these lines in both stable and master branch and it works. Same net pads triggers the same clearance errors as different net pads.
The code can be found in drc.cpp line 937 in 4.0 and line 959 in master branch if anyone think it is worth compiling to enable this clearance test.
Invoking that DRC test will probably generate many nuisance squawks in situations where a pad is composed from several (deliberately) overlapping pads, as mentioned earlier by @Rene_Poschl:
I prefer getting “false” errors that i can choose to ignore over hiding all violations, including overlapping components. I wish there were an option to choose either way.
A typical example is a ic with exposed pad for thermal conduction or for better gnd connection (EMC).
Example chip: TI bq76PL536 (http://www.ti.com/lit/ds/slusa08a/slusa08a.pdf page 58)
There the best way is to define the smd pad with negative mask clearance + separate overlapping pins for the holes.
The 3-pin TO-220 (and other power packages) often have an internal electrical connection from the thermal tab, to the center pin. I typically extend the pad for the center pin into the pad for the thermal tab, making them a single pad as far as KiCAD is concerned. While I’m at it, I may add a bunch of thru-hole pads inside the thermal-tab pad, for connecting to a back-side copper pour serving as a heatsink.
(You may need to remove your shoes to count all the instances of “Pad 2” on this footprint. Click on the image to see the whole thing:
From experience I know debating design practice is a minefield and I want to point out that I am absolutely not trying to put my way of doing things above others, we just have developed different ways of doing things. And please keep in mind that I am not a native English speaker so if the way I express myself can be interpreted as rude or arrogant it is completely unintentional.
With that out of the way…
Neither of these examples would be an issue to me because I would not design the footprints like that. I hope by saying that I can make my case for making same net clearance check optional. I think it is unfortunate that KiCad have this unnecessary limitation while having such powerful tools as push and shove, diff.pair and length matching.
I have very high hopes for KiCad and crossing my thumbs that the design rule options will evolve and be as great as the current features. Advanced design rules is a very powerful and sought after feature that other CAD tool vendors reserve for their high end products or as silly expensive addons.
