Can kicad DRC flag the following poorly constructed trace?

[julian1]

The likely cause is user error - inconsistent routing grids, followed by a cleanup tracks that removed a track segment at the bend. 

[ataradov]

I don't think it can. It can only mark a completely broken connection. The minimum trace width is detected based on the specified track width, not based on how those tracks interact.

[Doctorandus_P]

I don't know when ataradov checked this last but KiCad can do this. I think it was introduced in KiCad V7, but I am not sure.
The setting is in: PCB Editor / File / Board Setup / Design Rules / Constraints / Minimum connection width

And in DRC it looks like:

[ataradov]

I checked on V8, but the project I tried had minimum connection with set to 0. I guess it got left at 0 after the version upgrades and I never adjusted it.

[Doctorandus_P]

For me it was also set to zero. This probably disables it. I set it to 0.15mm to be able to verify it works and to make the screenshot.

I am not sure about the details. Maybe it's always set to zero by default. 

[ataradov]

It looks like the clean default project has all widths set to 0. I use a template project that I made a long time ago, which has all the settings configured as I like. But this option did not exist when I first created the template, so this width was set to 0, which migrated to all the projects created based on that template.

[julian1]

Thanks a lot. I am using v6. I just tried v7, and this has the extra 'minimum track connection' property as well as 'minimum track width'.
Using 'minimum connection width' with a non-default value the mistake gets picked up. (DRC also identified another marginal case which is nice).
So the solution may be to upgrade.

[ahbushnell]

Looks like a fuse to me.   
 

[johansen]

Am i the one who thought the OP was you know who?

[ataradov]

I was just working on a new board and had this check enabled. It is very annoying in practice. It detects connection width between islands on the planes created by vias and other routing. And even just a BGA IC sitting on a plane would create narrow connections because of the limited resolution of the plane hole generator. All those narrow bridges are marked, even though they don't matter at all.

Ideally this needs to be much smarter and only flag if the narrow bridge is the only connection between the elements.

[Doctorandus_P]

So first you are telling KiCad to check for narrow connections, and then you complain KiCad flags these narrow connections. 

I can see at least 4 different ways to fix this.

• Reduce the clearance for that (presumably) GND zone by a tiny bit.
• Reduce the diameater of those pads by a tiny bit (Either will create enough room for the zone to fit normally between those pads.
• Reduce the minimum connection width to a value that is narrower then the actual copper connection.
• It probably can be done with custom rules too (In various ways).

[ataradov]

No, I'm complaining that it checks individual connections, not the narrowest connection point of the same net. I guess there are a couple of reasons for those checks and strictly speaking KiCad is correct. But from a practical point of view, I'm only interested in narrow bridges that can lead to the loss of functionality if broken. 

Also, those narrow bridges are KiCad's fault too. The actual gap between the pads is wide enough, but KiCad's polygon generator narrows down the bridges.

Here is another example of this "bad" behavior.  It flags all the small dummy lands of plane formed by the traces. In this case, if the connection is broken, functionality is not going to be affected at all.

I may be asking too much, of course.

[julian1]

I noticed issues for fills and bga packages also.
Probably the reason the check is not enabled by default.
Having the option to treat the two cases - connected copper fill (where one expects some slivers) versus ordinary traces independently - might be a way to improve the test.
There is a slightly similar issue - with flood filling power/gnd bga pins where one doesn't want thermal reliefs while for other larger packages they are desirable, but there is no way to disambiguate the handling.

It is still a useful test to enable and run once, as part of a final checklist, followed by a visually scan.

[Kurets]

Likely the good solution is to require that trace end points overlap like the Altium design rule "complete connections" (I think it is called like that). This rule require that trace ends touch aend that a trace must end in the centre of a pad to be considered connected.

Not always desirable, but I have used that rule to find similar errors in reviews.

[MustardMan]

Having "put up with" that functionality in Altium (before I switched to KiCad) I must say I despise it.
The way KiCad allows you to route a track to anywhere within a pad is marvellous! Consider a largish SMD square pad, with a small track entering. Sometimes I want the track to just skim into the top (for example - you might like the side...)