Hi @all,
I’m quite new to this and created my first custom PCB with inkscape.
If I export to gerber files the contour and holes doesn’t match to the layout that I see in fritzing.
In Fritzing everything is shown correctly.
I found aworkaround by copying the silk-top-file into the contour file, but I’m not sure if it works in production and it can’t be the solution.
I already tryed to switch from mac to PC, an created the PCB 6 times new, always with different results ?!
I hope you understand my issue and anyone has a solution.
There is a bug in the way the current version of Fritzing handles Gerber exports of boards with cutouts. It is fixed in the development version of the code, but you would need to build that from sources to use it (there is no download available). For some details, and possible work arounds, see this forum post.
The Summary is that relative closed shapes in an svg path element are not being handled properly, but the same path with absolutely positioned cutouts works fine. Inkscape uses a mix of absolute and relative positioning, and I do not know of any way to force it to use absolute only. My ‘fixes’ for that part (in the other post) were done outside of Inkscape. Related bug reports:
I’ll have a look at the svg you posted, to see about fixing it up. I see a lot of digits of precision in the size and coordinates. I may not be able to maintain that, but I doubt you really need things to be accurate to 10e-6 mm.
Here is a quick fix for the the SVG file uploaded in the initial post. I collapsed groups down to just the board and silkscreen groups (layers), which removed the transpose used in the outer wrapper. Instead of doing the full recalculation to use absolute coordinates, I tried something a lot simpler. After each close (z) command in the path, I added an absolute move (M) command to get the absolute and relative position synchronized. A quick test, loading the image, exporting to gerber, and viewing the result, shows that it worked. But check it again when you use it. My checking was not extensive.
I scaled the view here up to what I think are real world dimensions (for typical computer screens), but that will not affect the image downloaded. It should ‘just work’.
@vanepp The calculation of the absolute move coordinates is simple. With a script that can parse svg path element “d” attributes, it would be easy to automate this.
EDIT: streamlined steps
set absolute coordinates to 0,0
when an absolute move (M) command is seen update absolute coordinates to match move coordinates
when a relative move (m) command is seen, update absolute coordinates to current absolute plus move (delta) coordinates
when a close (z or Z) command is seen, insert an absolute move (M) command (after the close) with the current absolute coordinates
-- can be skipped if the following command is already an absolute move command
That said I would be tempted to use holes in the sketch for the holes, I think (but am not sure) that the contour layer will be milled rather than drilled and that may add cost.
Thanks for your reply,
if you take a closer look to the screenshot, you will see, that the holes do not have the correct position and there are some holes missing.
Your file has Two (of the same) problems that confuse SVG.
Two of the Holes are NOT Holes nor are they clean, usable cutouts. They are two circles combined into what looks like an oval until Zooming into them… Sharp corners (where they meet) confuse SVG. Especially if they belong to Circular path/elements going in counter-directions to each other and will be used by Fritzing. Generally not a big problem for general SVG use but, for Fritzing, well special attention must be considered. Counter-Direction paths are most often intrepreted in SVG and ‘Intrinsic subtraction’ (I’ve posted about this before).
In other-words, if drawing an outer Rectangle Clockwise and inner Rectangle CounterClockwise, then Subtraction/Differencing happens. If drawing them the same direction, they are Added.
I was certain of this being part of the problem and, to confirm it, I loaded your file into FreeCad and there they were, unwilling to be used as the other lines/paths…
Frankly, you could completely re-draw your board in 5 minutes, rather than spending time trying to solve and force-fit a solution. That’s your call…
