Hello every one! Thanks for help me.
I have don a board with a custom outline
I have followed a tutorial to make it with inkscape (https://www.youtube.com/watch?v=ydcOzbCJltg and it looks all is ok, but when I export the gerber … the outline cutting layer is bad… like this (
I’ll appreciate very much your help.
Thanks
Welcome to the forum.
We will probably have to see the actual svg file created for the board outline, to have much chance at helping out.
I have not encounter it myself, but have seem multiple reports here that in some cases Fritzing does not handle transforms correctly in svg files. Those shifted position cutouts make me think that is a likely cause. The totally missing pieces could be that same, if the glitch caused them to be moved totally out of view. That looks like each cutout got progressively moved further from where it belongs. Like maybe it is being positioned relative to the previous cutout, instead of to the start. Screen shots of the bad output, without access to the file that caused it are not much help.
Also, what version of Fritzing are you using, what OS, and which program is being used to view the gerber output?
Thanks for answer.
I attach two files: one, the finally (named) plain svg and the other (named) ink that is wich I made all, with the layers board and silkscreen…
I did both, with Fritzing and Inkscape for Windows and For Mac OS, the latest versions (I downloaded like one month ago…), and obtained the same bad result, maybe the Windows version, a little bit better…
To see the gerber I used web versions and Altium, for example.
In this file
Other question. In the gerber files only one, the “contour.gm1” is bad… is it possible to edit this single file in order to get it right , and then replace the previous, and with the other files (in the gerber export) send to the pcb company? (I don’t know if I explained well)?
Thanks
@celestinoG The gerber files are plain text. Any or all of them could be modified manually, or with some other tool. I am not current with what the exact contents of each or the files looks like. A quick scan shows (only) a few things that look like labels. As long as you follow the rules for the specific file, and do not change anything that is referenced by one of the other files, there should be no problems.
I got the gerber export to work 
Though the steps to get there are not trivial, and I do not know what it would take to get Inkscape, or another SVG editor to do what I found to be needed. Or at least what worked, though since I did multiple things, not all of them may have been actually required to get it to work. Mostly, I was editing the svg file with a text editor. It is just an xml text file, that I can read (and modify) directly. At least when changing one element at a time.
To start, I ungrouped the elements in Inkscape a couple of times, to get rid of the transform wrappers. That also deleted the board and silkscreen layers, so I recreated those. The plain svg result of that, I feed through the FritzingCheckPart tool, which (among other tweaks) converted the style attributes that Inkscape used to individual formatting attributes. That still did not work. Next I moved the silkscreen layer/group to before the board layer. Not enough yet. Not working after manual removal of (more) unneeded meta data and attributes from the svg.
Finally I looked closely at the board path element that defines the shape and cutouts. I noticed a pattern to what was being shown by the gerber viewer, and the way the cutouts were defined. An svg path element (which is what the board is) can have either and both absolute coordinates and relative coordinates. Each cutout is created by a closed block of elements (a shape) following a move (“m” or “M”) command. All of the cutouts after an absolute move (M) showed up in the gerber view. Cutouts that were started with a relative move (m) worked correctly ONLY IF the preceding cutout used an absolute move. Some of the rest (m following another m) were on the gerber view, but in the wrong locations. I have not (yet) confirmed this, but I strongly suspect that what is happening, is that every relative move cutout is being positioned offset from whereever the previous absolute move was specified, instead of continuing from where the immediately preceding relative move left off. Many of the relative move commands had exactly the same offset. That resulted in them being in exactly the same location on the gerber. I also suspect that gerber acts like svg in this regard. A cutout on top of a cutout cancels the first cutout. So (especially) the rectangular cutouts only showed up at all when there were an odd number of them after an absolute move.
@vanepp. I strongly suspect a bug in the gerber export code for (at least) the custom board file. A work around is to never use more than one “m” command in a path after an absolute “M”. Other relative coordinates seem to work fine. All of the elements in a cutout block (after an m or M command) used (and still use) relative coordinates. With no problems seen. I need to create a simpler test case to verify assumptions from the symptoms seen. This indicates that a single cutout should work fine. More than that only work if absolute coordinates happen to be used, or the preceding cutout used absolute coordinates. 2 relative moves in a row fails, or puts the cutout in the wrong spot.
While manipulating the svg file, I encountered another gerber export bug we saw before. An svg close (z) command draws a straight line from the current active point to the latest move reference point. However, the gerber export is not inserting that final line segment, leaving an open shape instead of a cutout. Last time this was seen, I think it was just silkscreen, not cutout. Likely a general problem with the way the gerber export code handles (does not handle) a z command in a path.
Here is the svg file used to create a test gerber export, which looks like the image in the pdf below. I included the gerber file too. Both gerber and pdf renamed to append .fzz to the name, to keep the forum software happy. Download and rename to remove the .fzz to use them.
Untitled Sketch 5_contour.gm1.fzz (256.8 KB)
test gerber view.pdf.fzz (22.8 KB)
This should work, but I do not know how to describe the detailed steps needed to get there. I do now know how to tell any SVG editor to use absolute coordinates for move commands in a path. The manual fix was to collect the 6 cutouts (2 curved brackets and 4 rectangular dashes) needed to create one group, convert the move commands to absolute, adjusting the actual coordinates to match, then cloning the cleaned up block 4 times, and adjusting the absolute coordinates for the start of each individual cutout. In the process, the rectangular cutouts where changed to use straight line edges, instead of almost straight curve segments.
EDIT: bugs reported.
Gerber export missing and moving some custom pcb cutouts
gerber export does not include final segment of shape created by “z” command in svg path element
The missing and misplaced cutouts are a known problem, that has already been fixed in the development version.
The missing segment on cutout close still exists in the dev version.
I appreciate very much your help, indeed. Thanks
I understand all you say and I think it is complicated for me to do all you say… but I see the files you uploaded and I noticed that the .gm1 is ok, like I need… so if I change it in my project gerber exported files it should work, didn’t it? Because I don’t know if I would do it properly.
So, if I understand… you report this issue to Fritzing because it is a Fritzing problem and maybe they will fix it and next exportings with severals “holes cutouts” will be ok? because like this is a prototype… maybe I would need to change it… and I don’t know if I am going to be able to do what you have done… uf!
Anyway, thank you very much, again!
I believe the gm1 file is the complete export, not just the board itself. You would need to merge that with your project, not just replace it. You should be able to create your own exports properly, by importing the svg I uploaded. For that particular board layout. Any other board layout svg would need to be adjusted much the same way. The way the bug works, a boar with a single cutout should work. More than that will depend on exactly how the path element gets created.
The problem is already fixed in the Fritzing code. It works in the current 0.9.5 development version, so whenever that becomes generally available, the problem will go away.
