I am surprised.
I place all my PCBs so I have 0,0 in the middle of it (5.1.10) and I didn’t noticed that bug. Yet 
Have you used footprints which have graphic polygons (non-pads) in copper?
From: gitlab
Seth Hillbrand 
@sethhillbrand · 21 minutes ago
I can confirm this on 5.1.10 but the issue is resolved in master.
I’ll leave this open in case we decide to release 5.1.11. We won’t be able to backport the fix from master but there might be a smaller fix that we can address
Which implies the cause if this is known, documented & committed to “master”.
Not quite. DRC was re-written from the ground up for 6.0. (Primarily for the new rules engine, but also for significantly better performance and fewer corners for bugs to hide in.)
No.
So you suggest that source of problem is graphic polygon.
I previously understood that anything close to 0,0.
No, not everything around (0, 0) gives errors, there are just a lot of errors in that neighborhood. See for exemple my post #13 above: How could the copper item error?
I also tried it on a few different projects, and some do not generate any errors at all.
The KiCad copper logo has the same effect.
Strangely two symbols do not generate the DRC error, even with one at 0,0
Keep an eye on https://gitlab.com/kicad/code/kicad/-/issues/8571, I think I found what is it (graphic polygons in footprints have some problems). But I don’t know how to fix it.
I have been experimenting on 5.1.10 and found that placing two copper symbols overlapping does not trigger a DRC error
Do they short different nets or not?
If not then why you expect triggering DRC error?
The symbols do not have Pad 1, so I cannot assign nets to them
But this does not cause a DRC error, shorting two nets with copper symbols:
So they really short different nets.
I think the reason is that KiCad ‘don’t knows’ that one copper on another is in contact with it. Even a pad touching second pad.
See Key.png I attached to my bug report:
At each key I had to connect several pads with track to make DRC be quiet.
I don’t know internal KiCad algorithms, but it looks that finding if clearance is enough big is well done, but finding that something is in touch need to be updated.
Sometimes people show here the situations when you see that track attaches pad but KiCad asks for connecting them (the track is probably ended before reaching pad center because some clearance don’t allows for it).
It looks like this is getting fixed for 6.0, but orphaned for now in 5.1 as nobody seems to know where the broken code is.
This is nasty as DRC fails to detect a copper symbol bridging two pads or nets, as the test assumes that the symbol is always at 0,0. This leads to a dead board.
I don’t know if it’s orphaned. I’m working on the selection bug for 5.99, the solution can’t be applied to 5.1 directly due to differences in codebase. That bug isn’t critical. But the DRC bug is a different bug, it’s more important and there hasn’t been developer discussion about it. Indeed DRC is the most important thing to get right, but this depends on whether 5.1.11 will be released or not amongst other things. As was said, there’s no DRC bug in 5.99.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.