Same net pad clearance settings[SOLVED]

[dBman]

@Rene_Poschl

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.

I disagree on this one. I see no reason that a pad couldn’t have any arbitrary shape and still be considered a component pad. This is how PADS work:

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.

[Rene_Poschl]

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.)

[dBman]

I found this reported on Launchpad

Bug #905404 “DRC does not test clearance between segments/vias o...” : Bugs :...

Should I post in the thread to raise the issue?

[davidsrsb]

Adding your name to those affected upvotes it https://bugs.launchpad.net/kicad/+bug/905404/+affectsmetoo

[davidsrsb]

@Rene_Poschl

I would rather see courtyard checking implemented.

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

[dchisholm]

@davidsrsb

Seconded, several times I have placed components too close . . . [/quote]
A somewhat related capability is a DRC to make sure the silkscreen graphics are not placed over, or too close to, exposed copper. I know this can be a difficult condition to test with text: the temptation is to think of each character symbol as a box circumscribing all the possible ascenders, descenders, and extensions used by any character in the alphabet. This results in imposing an excessive clearance requirement around each character.

[quote] . . . 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.)

Dale

[davidsrsb]

@dchisholm

courtyards were a distant third. (If standard libraries included them at all. They ARE affected by the type of automatic placement machinery being used.)

That is the problem, it does depends on the assembler and going for worst case means you end up with boards twice as big as you want

[dBman]

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.

[dchisholm]

@dBman

I had a look in the source and found out that the drc deliberately skips the test if pads are of the same net . . . .

. . . . 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:

@Rene_Poschl

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.)

Dale

[dBman]

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.

[dBman]

Just out of curiosity, can someone give me an example of a component that have overlapping pads?

[Rene_Poschl]

@dBman

Just out of curiosity, can someone give me an example of a component that have overlapping pads?

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.

[dchisholm]

@dBman

Just out of curiosity, can someone give me an example of a component that have overlapping pads?

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:

TO-220_Horiz_ThermalPad_Alt.kicad_mod (8.8 KB) )

Dale

[dBman]

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.

[Rene_Poschl]

Just out of curiosity: how would you make footprints like the ones we showed? (With the tools available in kicad at the moment)

[dBman]

For the TO-220, I would use four pins, separated, and for the PQFP I would go width a single thermal pad with negative soldermask clearance. Neither would have thermal vias in the footprint.
I am a new user and have just done a few footprints yet so it is possible I am missing something.

[Rene_Poschl]

So no (footprint) controlled connection to the ground plane?

Also remember kicad does not (yet) support via stitching

[dBman]

No, I want to have full control over via placement so I can modify their position at any time. The mechanic designer is inevitably going to move something on top of it in the last minute. I forgot about the via stitch issue though.

[Rene_Poschl]

I heard that version 5 might include via stitching. This might enable me to do it your way. (But until such time i need at least the option to ignore these drc errors.)

Also how should vias within pads (or near pads) be handled? (Not tended vias also have a hole in the solder mask.)
(I don’t like the eagle way that all of them are errors. This masks real errors. Having lot of false positives in one pcb leads to potentially ignoring the correctly flagged problems.)

[dBman]

If I understand you correctly you mean manually placed thermal via in pad? I think via in pad should/must be accepted in that case. In the long run though, I hope there will be options for via in pad or not. For me, ideally I would like to have the options:

Via to pad - pad to via annular ring
Via to drill - accepts annular ring overlap but no drill in pad

And be able to set up the rules per net basis, layer and so on. I know this is a lot of work reserved for the future but are the kind of features I allow myself to dream about.