DRC reports non-existent errors when using arcs for tracks

[doragasu]

When arcs are used to make tracks, DRC reports errors that don't exist. For example in the attached image, there is a small arc connecting two lines. The clearance is 7 mils, and even though there are around 8 mils from the track to the nearest pad, a DRC error is reported. This is reported for a lot more tracks using arcs like the one in the screenshot.

[Chad Parker (parker-charles)]

I know this was reported a long time ago, but, is there any chance of the OP providing the .pcb file that generates these errors?

[doragasu (doragasu)]

You can find the PCB under the sch/rev-B directory of this GitHub repository: https://github.com/doragasu/Balsamo

Unfortunately I am not using geda anymore, and I do not know if the error is still happening with latest version.

[Chad Parker (parker-charles)]

Thanks for posting the file. I'll look into it.

[Chad Parker (parker-charles)]

It looks like there is still something funny going on with the arcs. I think it's in the geometry calculations.

[Chad Parker (parker-charles)]

This file has been very helpful, thank you for posting it!

I think the recent DRC fixes have fixed many of the issues you see with this board.

In many cases, there are traces of width 8 mil that join, but when you zoom way in, you can see that the points aren't precisely aligned (turn on thin-draw). With the "minimum copper overlap" set to 8 mils, anything other than perfect alignment is *technically* a violation.

Given the settings, I believe the DRC is now doing the right thing.

It does identify several places where there are minimum spacing violations. I've spot checked a few of these, and I can convince self that many of these cases are nearly exactly the minimum spacing. In fact, if you change it from 8.00 to 7.99 mils, the vast majority of them go away.

Ultimately this is because of the way that the detection is done (by bloating objects and checking for connectivity). pcb considers objects with 0 width between them to be touching. So, any spacing that is exactly the width of the setting will be identified as a violation.

At some point in the future, we may change the method for detecting these violations, at which time exact spacing may be considered okay, but for now, this will remain a violation.

I'm going to marking this as solved.