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

A gerber output oddness #4171

Closed
vanepp opened this issue Sep 17, 2024 · 3 comments
Closed

A gerber output oddness #4171

vanepp opened this issue Sep 17, 2024 · 3 comments

Comments

@vanepp
Copy link
Contributor

vanepp commented Sep 17, 2024

Current Behaviour

This isn't a bug directly as it works, but I don't know why it works (or if it is just a gerbv oddness.) While modifying a header pin I copied a 1 pin header (which I expected to be identical except perhaps with a larger silkscreen) in Fritzing the exported it as gerbers and displayed it in gerbv like this. Here J1 is my modified (actually python generated) single pin header, next to it is a generic header from core parts and after that a parts editor edited and exported fzpz file of a single pin header. In Fritzing they all look identical (and they look identical in the svg files in Inkscape) but the gerber output is very different (and different than the svgs!) My pin works as expected, the silkscreen is shown as lines with a blank space on the corners where the lines don't overlap. On my header that is what occurs in the gerbers to, but on the two core header pins the silkscreen has been changed to a rectangle with curved corners (which is very desirable if I can figure out how to do it!)

capture1

the gerbv output zoomed out a bit so the difference is more obvious:

capture2

This is the silkscreen gerber output displayed in gerbv: Note my header has the same edges seen in Fritzing, but the two core parts headers have a smoothed rectangle. How do I get the curved rectangle?

capture

Here are two (mine and the exported core part) pcb svgs which look pretty much identical to me.

first mine (where the stroke is already black, I tried changing it to white but nothing changes so it doesn't appear to be the color that is changing things.)

capture3

These two are the core part. This one is how the actual part is with the stroke set to white

capture4

here I changed the color to black so the lines are visible

capture5

Build:
Version 1.0.3
(bCD-1995-0-a7811ba0 2024-05-30) 64 [Qt 6.5.3]

Operating System:
Windows 10

Steps to reproduce:

see ## Current Behaviour

Expected Behaviour

All three should be the same as the input svgs appear to be the same.

@KjellMorgenstern
Copy link
Member

The ones from the core part have positions that are integers, while the first one shows coordinate values like
95.000008 .

Fritzing has some code that tries to simplify gerber files, for example if a polygon has four edges, it checks if they form a rectangle. This check tolerates some tiny rounding errors (epsilon), but 0.000008 might already be to big.
There are more such trick in place.
To check, it would make sense to compare the gerber codes generated, and the source code of the svg for each of the two connector variants.

@vanepp
Copy link
Contributor Author

vanepp commented Sep 19, 2024

The ones from the core part have positions that are integers, while the first one shows coordinate values like
95.000008 .

Fritzing has some code that tries to simplify gerber files, for example if a polygon has four edges, it checks if they form a rectangle.

Thanks! That is the clue I needed. I am changing the lines to a rectangle and have already rounded the numbers to 2 digits after the decimal to avoid that exact issue (95.000008 instead of 95) but must have re edited the svg with Inkscape after that which likes to put those things back in. I may try reducing Inkscape to 2 or 3 digits after the decimal to see if that works (without breaking anything) as well. I'll leave this open for now while I try this out in case I hit more problems.

@vanepp
Copy link
Contributor Author

vanepp commented Sep 19, 2024

Indeed changing to the rectangle fixes all my problems (at least so far.) So I will close this. This is a 6x7 header at 0.2in pitch. The pads and holes scale with the selected pitch which by and large appears to match the header specs (although I don't think there are 0.2in headers!) I can't find any specs for 0.5mm headers (although they are available, just no specs) but 1mm, 1.27mm, 2mm, and 0.1in appear correct. Thanks for the help!

capture

@vanepp vanepp closed this as completed Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants