Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keepout Detection (DRC) Dodgy #2676

Open
davidperrenoud opened this issue Aug 26, 2014 · 5 comments
Open

Keepout Detection (DRC) Dodgy #2676

davidperrenoud opened this issue Aug 26, 2014 · 5 comments
Labels

Comments

@davidperrenoud
Copy link
Contributor

From bitsybof...@gmail.com on July 24, 2013 22:10:09

See the attached images (and fzz), you will see

The grid size is set to 0.1mm
The keepout is set to 0.3048mm (12mil)
The DRC passed
The bottom center pin, and the trace running above it, appear based on the grid to be about 0.25mm apart (~10mil), less than the keepout and the keepout, by eye, should have failed them.

Attachment: keepout2.png keepout3.png keepout1.png transistor-test-jig-mini.fzz

Original issue: http://code.google.com/p/fritzing/issues/detail?id=2678

@KjellMorgenstern
Copy link
Member

DRC does not complain, although the distance seems 0.3mm, and I have set the keepout to 0.31 mm
keepout.fzz.zip

image

@KjellMorgenstern
Copy link
Member

In the above keepout.fzz.zip, DRC complains when keepout is set to 0.3375mm but does not complain for 0.3370mm .From the image, I think it should already complain at 0.3mm

@KjellMorgenstern
Copy link
Member

Note: This error means about 1 dot at 800 DPI. To fix it, the DRC either needs to calculate with vector graphics, or use a much higher DPI (eg. 2000 dpi)

@failiz
Copy link
Contributor

failiz commented Dec 13, 2021

Could it be that increasing the DPI helps also to fix #3902 and #3639? Not sure if it is computationally expensive...

@KjellMorgenstern
Copy link
Member

I don't think they are related. The DRC works on raster graphics, and such effects are inevitable (of course increasing the resolution would mitigate this. Not sure if there is any machining that precise that it is a problem already right now)

However, parts placement like in the other issues is a vector thing, and i hope it can be solved by just being more careful with numerics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants