Same net pad clearance settings[SOLVED]

[dBman]

Hello KiCad forum
I can’t get the DRC to catch clearance violations of component pads of the same net. Pads of different nets trigger the DRC as it should. I have tried setting net clearance in the footprint in the library part and locally. Also, can you get online DRC for component placement to prevent violations like when you use the interactive router?

Kicad version 4.0.4 stable
Windows 10
Open GL canvas.

Thanks

[davidsrsb]

Can you show an example of this. Normally pads on the same net can overlap - this is how complex pad shapes are made

[dBman]

This is two reistors placed side by side. The top pads are of the same net and the bottom different nets. The top pads does not trigger a DRC violation.

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

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

Issues related to zones and nets

It is not quite that bad. The problem is that ‘B’ is not really that smart, it just refloods. What you need is DRC, which should actually be called Design Regenerate and Rule Check, a rename I have already suggested. This should also be done, just before PLOT. Do not do just B before plot!!!. Given the Data base impacts of missing DRC before plot, it has been suggested this is the default, but the developers are strangely averse to such discipline, seemingly preferring novices learn the ha…

[dBman]

Ok, thank you for clearing that up.

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.

Thanks again

edit
KiCad is at the moment.
fixed with KiCad

[Rene_Poschl]

@dBman

component pad shapes and I think it should be possible to draw them as polygons in the footprint editor.

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.

[dBman]

Then I have to do the right thing and make a proposal then

[Rene_Poschl]

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

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