I have defined a LQFP footprint with pitch=0.5mm and pads width of 0.3mm. It makes a distance between copper pads of 0.2mm so a Clearance Board Setup Setting of 0.2mm should be enough to pass the DRC successfully.
Indeed, there is no problem in this scenario. However if I rotate the footprint 45 degrees the DRC fails showing violations on these separations between pads. Tweaking the Clearance to 0.199mm fixes the problem but I think this is not a very nifty solution.
Could anybody confirm this?
Version: 5.1.5-52549c5~86~ubuntu16.04.1, release build
libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-133-generic x86_64, 64 bit, Little endian, wxGTK
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
OpenCASCADE Community Edition: 6.8.0
Compiler: GCC 5.4.0 with C++ ABI 1009
You are making this an issue because you’re too stubborn to give KiCad a micrometer of tolerance to work with?
Do you realize what the size of a um is?
I think KiCad works at nano meter resolution. My guess is that it will even work if you tweak the clearance to 0.19999mm, but if you’re giving KiCad no tolerances whatsoever to work it, you’re just mean to the software.
Nothing in this analog world is exact, but bits in computers are, so there will always be rounding errors.
To me it’s the other way around. I commend KiCad for keeping on the safe side and catching DRC errors for such small overlaps. The clearance values you give to KiCad are minimum values and KiCad even catching the small rounding errors is a good thing.
This is a bug in my opinion, not because the user is “too stubborn to give KiCad a micrometer of tolerance to work with” but because there are two different behavior for the same action and this will catch the user by surprise. No, it is not critical/high priority bug, but still a bug worth reporting. (most developer are happy to hear when the user find issues with their software … not happy to be pressured, asked for deadlines or being set priorities by somebody else )
I would die of shock if there is a board maker out there that rejects an uploaded job because their design rule is 0.2mm and you submit a Gerber file with 0.19999mm tracks.
Handling rounding errors to please everybody is complicated
I will not “downvote” but am to stubborn to die of shock.
@davidsrsb 10nm was just a suggestion, With the example on Gitlab all DRC errors were gone by allowing for a 2nm tolerance. An equal argument could be made that KiCad should not be fussy about a 2nm tolerance violation.
I already amended a post on gitlab. In short:
The case of the rotated part is moot. especially because it just happens to interfere with the default design rules which should be changed for such parts anyway. It’s just a bad example.
The other case, where a slanted track is near a rounded corner is another case altogether. I assume the track is put there by KiCad, which implies KiCad stumbles over it’s own rules during DRC. This is a bug, and as I see it can only be fixed by using some kind of tolerance.
Gosh: In a real nightmare scenario, KiCad would put all the 45 degree corners near rounded pad corners and then generate DRC errors over them. So you move the corners and the Interactive router keeps pushing the corners back to the pad and your DRC errors are back, unless you lock all those corners.
Shivers down my spine.