Is KiCad supposed to generate different gerbers in “inches” and “mm” modes? I see the UI is changing from metric to imperial, but .gbl files seem to always be the same, with “Abs format (unit mm)” and %MOMM*%. I am using KiCad 4.0.5. Am I doing something wrong?
In the meantime .drl does respect the inch/mm setting - METRIC,TZ turns into INCH,TZ if I ask it to.
I just sampled some Gerbers produced from KiCAD over the last 18 months, and they all specify millimeter units. That was apparently never a problem for the fab houses, and Gerber viewers, I have used over that time span.
Dale
If no dev turns up and answers (with knowledge) you’d probably have to hit the bug-tracker to get a definitive answer on that one.
https://lists.launchpad.net/kicad-developers/msg23135.html
https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg18063.html
Gerber output (except drills) from KiCad is always metric, due to problems with rounding which occur when converting to inches, particularly with filled polygons. It is believed that no one needs imperial output.
The drill file does not have the same issue, so can be output in metric or imperial.
Just to confirm, gerber output is always metric NOW? It seems like at some point in the past imperial was supported?
The reason I am asking, and I have to quote from mail archive
“it would take some extraordinarily bad software to not work with metric units”
gerbmerge is this set of Python scripts to panelize boards, pretty cool stuff with automatically finding optimal placing, kind of dead kind of alive took - there is a bunch of unrelated forks now.
I see from past discussions that gerbmerge used to definitely work with KiCad and older versions of gerbmerge were imperial-only. Newer forks have metric support but these newer forks do not have have G85 support.
Anyway, so when exactly was inches support shut down for gerber outputs? Wonder if using an older version would work for me here.
Wouldn’t it be better to get gerbmerge up to speed on things?
Joan, you are definitely right! Would you be interested to resolve the merge conflict between two forks of gerbmerge? It seems like there is no official maintainer and some German folks have made great G85 progress based on an older version.
I’m currently working on getting my personal data converter back on track (python) that is now 5 years old and scheduled to convert data for a whole year of scientific instruments like yesterday, while also juggling a RPi project that needs even more coding… so, no sorry 
Every now and then I stop by the forum (or better change browser tabs) and see if I can lend a thought or idea, but not much more possible.
If you need anything German translated, no prob… I can help you with that, unless there are others around in the Forum that are willing.
if all your gerb are coming from kicad, you may have a look here
http://projects.borg.ch/electronics/kicad/panelize.html
and for gerbmerge I see here
that they added metric support
“kicad panelize” seems to require more manual labor, you need to manually specify placement of each copy, while gerbmerge seems to have the logic to do all the placement magic by itself.
Yes you are definitely right, 1.9 gerbmerge has metric. My problem is that I use slots on my board - that’s tag G85.
https://git.phoerauf.de/VT7/gerbmerge-utils/ is the fork of gerbmerge which seems to contain G85 fixed, the problem is for some reason they’ve forked from older 1.8 gerbmerge which is imperial-only
I’ve attempted to merge 1.9 and VT7 G85 changes manually but it’s not trivial - I suspect there are merge conflicts.
Yes, Gerber output used to be selectable metric/imperial but is now metric only, I guess that happened over a year ago.
I made some small changes to gerbmerge to better work with kicad, but that didn’t involve metric. I think also the extended gerber attributes caused some problems, but those can now be turned off.
have a look at the commit to see if you can merge in some way
Coding is not my domain but I can help with translation, if needed.
Do you really need the output in inches? All I can say is good luck with that: the Gerber output has 5 decimal points in the output (so 0.1 mil) but although that’s well below actual fabrication tolerances, KiCad creates points along a path and some of these points may become indistinguishable and cause problems when CAM software performs verification. You can select the option for 6 decimal places but some older CAM software chokes on that and causes all sorts of funky things to happen, particularly with 360 degree arcs.
At any rate, due to various shortcomings of the Gerber format and the fact that mainstream CAM software doesn’t care what unit you use, mm is currently the only supported unit in the output and you would need to use a converter if you really want the output in inches.
I had to drop gerbmerge when transitioning from Eagle to KiCad because of it’s shortcomings in MM support. Even after applying the MM support patches. I considered digging into the code to correct the issues but got really quickly discouraged by the code base.
If you are interested in automated gerber file manipulation there is a new kid on the block: https://fosdem.org/2017/schedule/event/ruby_libgerbv/
This solution might allow adding of tabs and fiducials to your designs too. Tabs is something gerbmerge was never able to do as far as I remember and it was also the largest grief I had with it.
I hope this is useful in some way. 
There seem to be a number of forks of gerbmerge and the greatest motivation to fork seems to be to provide mm support. I have a feeling many others have done as you have and run away in horror after attempting to dig into the code to fix other issues.
I forgot to mention in my previous post that the inaccuracies in specifying coordinates in inches was not such a problem in the past when filled zones were represented by apertures and paths/points using a method similar to the way a child might color in a drawing. However that mode of operating has been deprecated and discouraged for quite a few years now. These days the gerbers define a polygonal area using points and if the CAD software happens to produce some indistinguishable points due to the precision in the file output then bad things happen.
