DRC does not test clearance between segments/vias of the same net

[Guillaume Simard]

While routing a track, I found it was possible to place two consecutive vias under the required clearance.

At first, I thought this was a via to via issue, but this is not so, because if the vias do not belong to the same net, it is impossible to place them under the said clearance.

The same is true for track segments: you can create a track that passes by itself very closely (as in a coil loop), without triggering DRC errors.

Attached is a simple board illustrating what I think should trigger at least 3 DRC errors, even if it's the same net:

- Via to Via
- Via to segment
- segment to segment

All of this is due to these lines, saying basically that no DRC errors can be triggered by same net objects:

drc_clearance_test_functions.cpp L345

        // No problem if segments have the same net code:
        if( net_code_ref == track->GetNet() )
            continue;

I understand that these lines alleviate the need for testing connectivity at the same time as DRC (two segments physically linked together do not violate DRC, but I think two segments of the same net, when linked physically through a third segment, should be tested for DRC).

In other words, the fact that two segments/vias share the same net does not guaranty this cannot lead to fabrication problems.

Guillaume

Application: Pcbnew
Version: (2011-12-16 BZR 3308)-testing
Build: wxWidgets 2.8.11 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.4.4,wx containers,compatible with 2.4,compatible with 2.6)
Platform: Linux 2.6.32-131.12.1.el6.x86_64 x86_64, 64 bit, Little endian, wxGTK
Options: USE_PNG_BITMAPS=ON
         KICAD_GOST=OFF
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         USE_BOOST_POLYGON_LIBRARY

[Dick Hollenbeck (dickelbeck)]

I agree with you about via to via.

I would suggest we try and separate the discussion into 2 categories:

1) Maybe we can all agree that via to via is a bug?

2) Find a way to gather more opinion on :

a) via to track of same net.
b) track to track of same net.

By more opinion, I mean more people's opinions.

[Dick Hollenbeck (dickelbeck)]

I agree with you about via to via.

I would suggest we try and separate the discussion into 3 categories

1) agree that via to via is a bug?

get more opinions and ideas (from more people) on :

2a) via to track of same net.

2b) track to track of same net.

[Guillaume Simard (gsimard)]

1) Via-to-Via: Agreed, I'm working on it, I have fixed the offline DRC now I'm trying to add the online DRC for a new via while routing.

2a) and 2b) I agree we need more people commenting on this, but I think it's a fab issue, so it should trigger a DRC error, perhaps of a different kind (saying it's the same net).

[Brian Bidulock (bidulock)]

Dick,

On Fri, 16 Dec 2011, Dick Hollenbeck wrote:

> I agree with you about via to via.
>
> I would suggest we try and separate the discussion into 3 categories
>
> 1) agree that via to via is a bug?
>
> get more opinions and ideas (from more people) on :
>
> 2a) via to track of same net.
>
> 2b) track to track of same net.
>

Add pads and zone into there as well. There are design
rules for same-net copper to copper clearances: kicad just
doesn't have any of them.

--brian

--
Brian F. G. Bidulock � The reasonable man adapts himself to the �
<email address hidden> � world; the unreasonable one persists in �
http://www.openss7.org/ � trying to adapt the world to himself. �
                        � Therefore all progress depends on the �
                        � unreasonable man. -- George Bernard Shaw �

[Guillaume Simard (gsimard)]

This is a patch for proposition #1, ie.: DRC testing for same net via-to-via spacing.

Two things have been done:

- DRC testing is no longer skipped for same net objects IF the two objects are vias.
- Online DRC now also checks against the track being currently routed (it was testing for all board tracks, excluding the track being routed).

Because the DRC still skips same net objects (except for via-via), testing DRC against the currently routed track does not change behaviour of the online DRC, apart from solving the problem of being able to place two successive vias very closely while routing.

Guillaume

[Eldar Khayrullin (eldar)]

What it actual status?

[Novak Tamas (novak-7)]

Nothing happened in 5 years:(
New 6936 still doesn't show DRC errors on proximity vias. (vias on the same net, so close that their holes touch each other: it is impossible to drill)

[PCB Wiz (1-pcb-wiz)]

> Novak Tamas (novak-7) wrote Nothing happened in 5 years:(
> New 6936 still doesn't show DRC errors on proximity vias. (vias on the same net, so close that their holes > touch each other: it is impossible to drill)

My comment would be that drill-drill certainly should be checked, and that should be possible without even NET checking - ie purely scans holes, and any holes which either Double-strike, or overlap, (or are too close - what web is actually needed during very-close drilling ?) those should flag as manufacturing issue in DRC. (Short slots, may need special exclusion ?)

Once separated by some minimum safe drilling distance, the issues changes a little.

If the Vias are stitching vias, with flood-over, then pad-pad too close does not really matter.
There are no copper acute angles, and this would be a fairly common use.

Outside of flood, then there could be a case for DFM Acid Trap sense messages, for vias (indeed any Pads) that overlap/touch.

Re the trace-trace question, that gets trickier and maybe that is also best as a DFM check, rather than a DRC-Clearance check.

There are a lot of cases where traces will approach and overlap, and the actual problem is not connection, but more of what is etch-able, and that is more a DFM issue.

In that DFM run, all copper is tested for some minimal DFM space, should that copper not overlap.
To improve speed, pour polygons could be skipped, as they should be correct-by-design.

Something like GerbView could have a similar DFM check.

What is the present PcbNew DFM roadmap ?

[xzcvczx (xzcvczx)]

As i can't see any progress from the original reporter i am changing this bug back to confirmed

[deberman (deberman)]

I recently found out that KiCad does not test component pads. I think this is similar enough to OP that it does not need a new bug report.

Line 959 and 960 in drc.cpp

if( pad->GetNetCode() && ( aRefPad->GetNetCode() == pad->GetNetCode() ) )
continue;

If we could have an option to skip this if() in the drc dialog I would be very greatful.

Thank you for all your hard work.

[deberman (deberman)]

I recently found out that KiCad does not test component pads _of the same net_.

Sorry if I missed the edit button

[Nicholas Savenlid (nicholas-z)]

This is a big problem

My pcb manufacturer complains and I feel ashamed.
I want a clean DRC to be clean.
Also DRC dont check for stubs or loose left over vias.

attaching and example of a plane that almost touches on a via of the same net.

In this case you should maintain the clearance as we dont make contact.

[Nicholas Savenlid (nicholas-z)]

also solder-mask minimum bridge width would be good to set in drc

[Scott M (nikolx)]

As comments were requested, here's my weigh-in:

1) Via-to-via:

Summary: Manufacturers expect these issues to be resolved before receiving a board file and likely will not manufacture your board with drill hits too close together. A drill-to-drill DRC check seems like a reasonable addition for KiCad DRC.

Many other CAD packages have a drill-to-drill minimum distance that can be set for DRC checking. Although this issue is technically DFM, having drill hits too close to each other can prevent the manufacturing of the board altogether.

Note that this is not talking about overlapping drill hits automatically and intentionally generated to create a slot. Manufacturers typically recognize this and their CAM will process accordingly to manufacture a slot properly.

2) For same net trace-to-via and trace-to-trace spacing:

Summary: Manufacturers don't always expect these issues to be resolved before receiving a board file, and typically will still manufacture your board even with these issues. I do not think this fits in KiCad DRC.

I see these as DFM only. These are not show-stoppers for actually manufacturing the PCB. The problem with having small clearances is that the copper may bridge the gap - but electrically this is not a problem since they are the same net. The only case where it may be an electrical issue is in rare cases of high current or signal integrity.

Other CAD packages often don't have this check either. It is typically considered DFM instead of DRC, as are acid traps, annular ring, soldermask min bridge widths, soldermask & copper slivers, etc. If KiCad gets DFM checking, I think it should be separate from DRC and considered a new feature rather than bug fix. DFM is expansive - to see the majority of PCB DFM checks: http://www.downstreamtech.com/dfmstream-advanced-checks.php

---

As an aside about drill clearances and DRC: some CAD packages also have drill-to-copper to account for drill registration issues causing either NPTH's or drills with small annular rings to hit copper on other nets and cause an electrical short, which is nice.

[Jeff Young (jeyjey)]

Drill-to-drill clearance was added to 5.1.

Of the remainder, there doesn't seem to be a consensus. Options:

1) Put DFM on the road-map; handle same-net clearance checks there
2) Make same-net clearance checks optional in DRC
3) Add same-net clearance checks to DRC but have them produce a second class of DRC markers
4) Allow DRC rules to be authored that do whatever the author wants

Of these, (2) and (3) seem like slippery slopes.

(1) is covered here: https://bugs.launchpad.net/kicad/+bug/1783093
(4) is covered here: https://bugs.launchpad.net/kicad/+bug/1783091

So I'm closing this one. Feel free to comment on the other two (or re-open if you really think (2) or (3) is the way to go).

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. Try searching for "lp:#905404" on https://gitlab.com/kicad/code/kicad/-/issues