fritzing / fritzing-app

Fritzing desktop application
http://fritzing.org
Other
4.04k stars 833 forks source link

A gerber output oddness #4171

Closed vanepp closed 1 month ago

vanepp commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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