Gerber export failing

spassignat · August 18, 2021, 10:29am

Hello,

I’m exporting two boards with similar contour, only dimensions are different. One is exported well, the other one contour is not closed. (Fritzing 0.9.3)
These contours are produced with generated svg files, which means their code are really identical.

Can someone have a look and tell me where I’m wrong ?

3a: Failing
camdenboss-3a-screw

<svg height="50mm" version="1.2" viewBox="0 0 622.8 360" width="86.5mm" x="0" xmlns="http://www.w3.org/2000/svg" y="0">
...
<path d="M 117,63.4
		a 14.4,14.4 0 1,0 28.8,0
		a 14.4,14.4 0 1,0 -28.8,0 z
		M 477,296.6
		a 14.4,14.4 0 1,0 28.8,0
		a 14.4,14.4 0 1,0 -28.8,0 z
		M 0,0
		h622.8
		v360
		h-622.8
		Z" fill="#1F7A34" stroke-width="0"/>

6a: working
camdenboss-6a-screw

<svg height="98.7mm" version="1.2" viewBox="0 0 596.9 710.6" width="82.9mm" x="0" xmlns="http://www.w3.org/2000/svg" y="0">
...
<path d="M 104,49.3
		a 14.4,14.4 0 1,0 28.8,0
		a 14.4,14.4 0 1,0 -28.8,0 z
		M 464,661.3
		a 14.4,14.4 0 1,0 28.8,0
		a 14.4,14.4 0 1,0 -28.8,0 z
		M 0,0
		h596.9
		v710.6
		h-596.9
		Z" fill="#1F7A34" stroke-width="0"/>
	</g>

The board is basically a svg path (with holes using arcs ‘a’). To make sure it’s closed, I use a Z command to end this path, which works well on the 6a board, but not on the 3a one.

thanks

vanepp · August 18, 2021, 3:48pm

While (as usual) I can’t make either path work properly in a loadable slot svg, I think this is a 0.9.3b bug and 0.9.8 should fix it. Between 0.9.4 and 0.9.6 there were at least 5 bugs in gerber processing fixed (and one added which is corrected in 0.9.8!) This bug is I think the incorrect calculation of the start point, and can usually be fixed in 0.9.3b by replacing the Z with a
M 104,49.3 to complete the path. @microMerlin is the expert on this and I may have this wrong, as I’m not all that hot on paths. If you can upload the svg you are loading I can try it on 0.9.3b and 0.9.8 to see if the problem goes away. I tried substituting the path in to an existing svg that creates slots, but the results are not right (probably something I did!) in 0.9.8. If (as too often happens) the forum says it can’t render the svg on upload, zip the svg (the forum now looks at the file and detects the svg so you need to zip it to hide it from the forum), rename the zip file to .fzp and upload that (telling us it is a zipped svg.) I of course am assuming (as seems likely) that you are using the load image file feature in pcb view to upload the path. It may be part of the pcb svg, but the format looks wrong for that (and their isn’t enough information here to tell what the original file is!) I am assuming you are doing a load image file (circled in red here):

Peter

microMerlin · August 18, 2021, 6:16pm

It is the final rectangular block that needs closing so insert “M 0,0” before the final “Z” in the path. or “v-360” would do the same thing.

Actually, I do not see why the working one IS working. It looks like it should hit the same export bug, which does not close the path properly.

Usually, the background block is first in the path, followed by the cutouts. I have never tried this order. Also, the cutouts need to follow the opposite direction from the main background. If the path of the base is clockwise, the cutouts need to use a counter-clockwise path.

spassignat · August 18, 2021, 8:52pm

Thanks a lot @microMerlin and @vanepp. I finally add the last step in the path (small vertical move) and it’s working fine. I think I will use the M0,0 before Z. That’s smart.

That was my point. I struggled so much with that and wasted enough pcb, … then I made that tool (simple xslt) to generate rectangle (can be enriched) boards and holes at the proper location + alignment marks, … to have a readable svg file. Having several pcb working fine and one not at all, was really strange.

I’ll check this.

You’re assuming well, here are the svg in a renamed zip file. Camdenboss.fzp (1.4 KB) I hope I followed most of your past advice’s (feel like a kid returning his homework)

Have a good day and night !

vanepp · August 19, 2021, 1:49am

For me neither one works on 0.9.3b or 0.9.8. I took your new svg files and substituted the paths above in to the svg to get the original not working one

The is the Untitled Sketch_contour.gm1 displayed with gerbv with the old path present. As we see the left line is missing in the gerber output (which I believe is a bug still in 0.9.8!) The new file displays correctly in both 0.9.3b and 0.9.8:

I’ll report this as a bug on github because it looks like the Z type close code still has a problem because the svg renders correctly in Inkscape and in pcb view on Fritzing but not on the gerber output. Note however that for me both the old files react the same on both 0.9.3b and 0.9.8, this is the gerber output of camdenboss-6a-screw-old.svg (the original file with the path above) on 0.9.3b. As we see the left line is missing here too same as the 3-old svg:.

edit:

reported as issue 3868 on github.

Peter

spassignat · August 19, 2021, 6:23am

We got the case now !

If you rotate the board 90deg, the issue appear/disappear.

To compare working and non working gerber files (I don’t know this file format to read it raw) I made opened squared board. They are really different.

open-square_contour.gm1.fzp (103.6 KB)
open-square_contour-fail.gm1.fzp (303 Bytes)

here is the squared board opened-square.svg.zip.fzp (356 Bytes)

vanepp · August 19, 2021, 2:08pm

The issue doesn’t disappear for me, it just rotates 90 degrees with the rotation opened-square.svg loaded in to fritzing. exported and displayed in gerbv:

rotate the path 90 degrees (changes the xml, replaces the Z with a z) but the missing line just rotates for me:

I don’t know why it is different for the two of us though (this is on 0.9.8 rather than 0.9.3b though but I don’t think that will make a difference.) Indeed for me 0.9.3 does the same the missing line is rotated 90 degrees.

Peter