SolvedLibrePCB Gerber Generation : Octagons were not correctly handled by manufacturers
✔️Accepted Answer
Urban and me figured out that the hardcoded octagon Aperture Macro works in a CAM tool (we call it CAM tool A in this post), this makes me belive this bug can be found, another reason I believe it can be fixed is Gerber's Aperture Macro Primitive outline (code 4 in the specification) is a simple one, and it is widely used in Gerber files for various PCB design softwares.
Because the CAM tools used are aged and Gerber spec is always keeping evolving. So one idea is to have a look at the the outline definition in the old Gerber specification as the CAM developers must read the spec when they developed it. I googled and download a copy of version from 2001 (Part Number 414 100 014 Rev D March, 2001, 61 pages in total), there's no big differences between the old one and the pretty new one (Revision 2021.02, 203 pages in total).
In the old spec, on page 20, section "AM parameter syntax rules", it writes:
Do not begin a variable primitive modifier with a minus sign (for example,
-$1). To indicate negative, precede the variable with 0 (for example, 0-$1).
With the information above, I modified the macro definition, use 0-$1 format, it didn't work.
While in the lates spec, on page 68, it has a section "4.5.4 Macro Variables and Expressions" which is informative and gives lots of examples which is quite good for intuitive learning especially for a person who is not very familiar with Gerber format.
If the hardcoded version works, one natural debugging idea is: Maybe we can try to use the mixed version, i.e. some parameters are hardcoded, but for some of them we use variables. We replace the hardcoded value one by one, see when the macro will trigger the bug of the CAM tool (The only thing we need is just some elbow grease and be patient enough)
The test file is based on the Gerber from @dbrgn.
%FSLAX66Y66*%
%MOMM*%
G01*
G74*
%AMROTATEDOCTAGON*4,1,8,-$1/2,$2/2-$3,-0.869239,0.65,0.869239,0.65,$1/2,0.269239,1.25,-0.269239,0.869239,-0.65,-0.869239,-0.65,-1.25,-0.269239,-1.25,0.269239,$4*%
%ADD10ROTATEDOCTAGON,2.5X1.3X0.380761X0.0*%
D10*
X5606051Y5606051D03*
M02*
With the above macro, we can get this image in CAM tool A:
Now if we change $2/2-$3 to 0.65-$3 ($2/2 is 0.65), we get:
This is the shape we expected! How?!
Then I use 0.5x$2-$3 and $2x0.5-$3, it didn't helped.
Every corner is OK except the spike at top left, the coordinate of that point must come from the calculation of $2/2-$3, $2 is 1.3, $3 is 0.380761, so I measured the distance between the center of the macro and the spike, the value is around 0.8mm. How can we get 0.8 from $2/2-$3? After several times of attempts I see 1.3/(2-0.380761) = 0.80, is this a coincidence? Maybe.
When I googled the keyword "gerber macro arithmetic operator" I found the following thread and was inspired.
[Gerbv-devel] [ gerbv-Bugs-3172530 ] Operator precedence not implemented in aperture macros
It's not hard to verify this guess: just change the value of $2 then measure the coordicate of the spike again, if the distance is the same with the value from $2/(2-$3), then the guess is correct. If $2 = 2, the calculated value is about 1.23. Modify the Gerber accordingly and open it in CAM tool A.
Yes, it is 1.23!
The bug is clear, let's compose another version for this macro, read the Gerber spec and checked an example macro from KiCad, I get this one (It is a complete Gerber layer, can be saved as a filename.gbr file to test):
%FSLAX66Y66*%
%MOMM*%
G01*
G74*
%AMROTATEDOCTAGON*
0 Oblong octagon, 8 corners, with rotation*
0 The origin of the aperture is its center*
0 number of corners: always 8*
0 $1: Length*
0 $2: Width*
0 $3: Chamfer*
0 $4 Rotation angle, in degrees counterclockwise*
0 create outline with 8 corners*
$5=$1/2*
$6=$2/2*
4,1,8,
0-$5,$6-$3,
$3-$5,$6,
$5-$3,$6,
$5,$6-$3,
$5,$3-$6,
$5-$3,0-$6,
$3-$5,0-$6,
0-$5,$3-$6,
0-$5,$6-$3,
$4*
%
%ADD10ROTATEDOCTAGON,2.5X1.3X0.380761X0.0*%
D10*
X0Y0D03*
M02*
It works correctly in:
- CAM tool A
- Gerbv
- https://tracespace.io/view/
- Ucamco's reference Gerber viewer
So I think for compatiblity reason, LibrePCB can consider to modify the this aperture macro definition (note that my version is just a quick and dirty fix). This is not a problem of LibrePCB, it's just the crappy CAM tools caused these issues.
Interestingly, the version works in many Gerber readers does not work in JLCPCB.com's previewer! I've told the relevant developer at JLCPCB to check if it's a bug in their code.
Personally I had fun during this debugging process, I want to thank this bug and all you guys :)
Other Answers:
I checked how KiCad 5 and Eagle 7 export such pads. Actually I guess they don't even support octagon pads where width!=height (really?!) so I checked it with rotated oblongs and rotated regular octagons. The result quite surprises me. Kicad uses G36/G37 regions (which is not recommended by the Gerber specs) and Eagle even draws a lot of strokes to fill a pad
VERSION / OS / ENVIRONMENT
SUMMARY
Even if files seems to be correctly formatted (Ucamco reference gerber viewer says👍 ),
2 big manufacturers (PCBWay or JLCPCB) have difficulties to handle Gerber files generated by LibrePCB.
It seems that octagons are not correctly handled.
It is with octagons with difference between width and height.
Others seems to be correctly handled.
STEPS TO REPRODUCE
EXPECTED RESULTS
ACTUAL RESULTS
ADDITIONAL INFORMATION