Gerber/Drill file inch/mm defaults

Hi all, I’ve just been generating CAM files for my first design with KiCad 6.0.11 and I noticed that the default output format for the Gerber files is mm, but then when I moved on to the drill files it was inches. Would there be a good reason for this inconsistency, or is it just another minor thing that may get fixed?

I think it’s due to the disparate origins of the standards for Gerbers and Excellons. IIRC the drill file states the unit used. In any case I’ve never had problems using the defaults, blissful ignorance.

Just set the inch/mm units in the Drill(gerber) popup panel… duh!

The whole communication system between the designer and the manufacturer through files is flawed IMO. We know that Gerber files are standardized but they are not used according to the standard. And even beyond the explicit standard Ucamco, the guardian of the standard, feels need to give recommendations which of course aren’t obeyed. The current gerber standard includes non-excellon drill file in “native” gerber format – you can choose it in KiCad and then you don’t need to set the units – but try to guess if anybody uses it.

This wildly non-standardly used standard has lead to situation where the manufacturer always needs to spend their time manually checking the drill file against the gerber layers. Even if they ask for certain settings (origin, units) for the drill file, they silently edit it as needed without further questions to make it good for their process. Or has anybody received a board with totally wrong drilling?

I just created a new project in KiCad, put a resistor on the schematic, assigned a footprint, put it on the PCB and then PCB Editor / File / Plot / Generate Drill Files and the default was set to mm for me.

Application: KiCad PCB Editor

Version: 6.0.10-86aedd382b~118~ubuntu20.04.1, release build

	wxWidgets 3.0.4
	libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3

Platform: Linux 5.15.0-58-generic x86_64, 64 bit, Little endian, wxGTK, xfce, x11

Build Info:
	Date: Dec 18 2022 19:39:35
	wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
	Boost: 1.71.0
	OCC: 7.5.2
	Curl: 7.86.0
	ngspice: 36
	Compiler: GCC 9.4.0 with C++ ABI 1013

Build settings:

You missed the point. I wasn’t asking how to do it.

Ah, is this a sticky setting? Maybe I should check in a fresh installation. Thanks for doing this. Maybe I had touched it before and just forgotten: I did tinker with KiCad 5 but I wasn’t aware 6 might import settings.

Creating a dummy project just to test this is 5 minutes of work.

I also had a look into KiCad’s configuration directory and I found (In ~/.config/kicad/6.0/pcbnew.json) an “unit_drill_is_inch”. I have not verified whether that truly relates to the drill file though it seems logical.

“gen_drill”: {
“drill_file_type”: 0,
“map_file_type”: 4,
“merge_pth_npth”: false,
“minimal_header”: false,
“mirror”: false,
“unit_drill_is_inch”: false,
“use_route_for_oval_holes”: true,
“zeros_format”: 0

Also, if you rename the whole configuration directory, then KiCad assumes it runs from the first time and it creates a new configuration directory with defaults. You have a backup then, and you can use a program like meldmerge to compare differences between those two directories. Both hare nice when you start manually editing those files.

And yes, I do think KiCad migrates settings from older versions during an upgrade. I had the old color scheme persist in KiCad V6 for a while.

I doubt if the fabs are correcting thousands of jobs per day manually. I think there is coordination between the Gerbers and Excellons re the origin. When the origin is changed in the layout, the drill files will change too. It’s easy to test this but I’m not at my computer for the near future.

I assumed ‘the point’ because you didn’t ask what you infer you asked.

That is the only question you asked.

You mentioned only changing the units in the main Gerber panel as if not knowing about the Drill Gerber popup. I leave this topic here…

Fabricators do. If they would blindly produce what CAD sends them most jobs would come out unusable.

The registration process is typically automated. Automatically checking whether the drill file matches the copper is usually pretty straightforward. Most design data is nowadays correct in this respect, about 10% has registration errors. A vast improvement over 10-20 years ago, when over 2/3 had wrong registrations. The CAD to CAM dataflow does improve. Slowly, slowly.

Of course, sometimes the automatic registration goes wrong, typically on very symmetric boards where the flipped image seems to fit better. This error happens rarely, but it does happen. Do not worry about it. Just blame the fabricator if this happen. They will supply a corrected board free of charge, maybe pay compensation for the delay, grovel over the floor and humbly apologize for their stupid mistake.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.