GerbView: Incorrect scaling of EXCELLON drill file

[Aimylios]

This might be a PEBCAK instead of a bug, but I'll report it anyway because I could not find any information about this specific issue. I can reproduce it with recent builds of KiCad on both Windows and Linux.

I do have an EXCELLON drill file that was generated with Altium Designer and has the following file header:
M48
;Layer_Color=9474304
;FILE_FORMAT=2:5
INCH,LZ
;TYPE=PLATED

I can open this file in GerbView, but the scaling is not correct. The size of the individual drills is OK, but the x and y positions are scaled by a factor of 10, i.e. if the correct position of a drill is x=0.1in y=0.1in GerbView shows it at x=1.0in y=1.0in. The corresponding GERBER files do not have this issue.

Interestingly, the format information in the upper toolbar says "fmt: in X2.4 Y2.4 no TZ" (see attached screenshot), but it should be X2.5 Y2.5 according to the file header. The GERBER files are correctly identified as "fmt: in X2.5 Y2.5 no LZ".

Unfortunately I can not share the whole file, but I have extracted a small part of it that should be sufficient to demonstrate the problem.

--------------------
Version information:

Application: kicad
Version: (5.0.0-rc2-dev-70-g2da7199a3), release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

[KiCad Janitor (kicad-janitor)]

Fixed in revision 3e033aee0cc046920637ffb545d0d94f54489b4f
https://git.launchpad.net/kicad/patch/?id=3e033aee0cc046920637ffb545d0d94f54489b4f

[Felix Pflaum (fixxl)]

The problem still exists on the latest Windows Nightly (5.0.0-rc2-dev-262-gdfd2a8fc4). If leading zeros are suppressed and the first entry's X-coordinate actually suppresses one or two leading zeros, the format is detected as 3.2 and 3.1, respectively, instead of 3.3.

I attach a file demonstrating the problem. The file is MM 3.3 but is detected as 3.2 because the first X-value is smaller than 100.000mm.

[KiCad Janitor (kicad-janitor)]

Fixed in revision a931ac436a14d32bd413e4b100581da023fe530e
https://git.launchpad.net/kicad/patch/?id=a931ac436a14d32bd413e4b100581da023fe530e

[jean-pierre charras (jp-charras)]

I set the status to new, because the fix is broken:
It works only with the sample file.
It does not work with other Altium Designer files
(some samples have ;FILE_FORMAT=4:4 setting)
It breaks files using usual format (2.4, no Leading Zero)

[Piotr Trembecki (pinolec)]

I may only add that 4.4 format is not official Excellon format.
Here is link to official Excellon format: https://web.archive.org/web/20071030075236/http://www.excellon.com/manuals/program.htm

The problem is a file set in inches recognised as 2.3 (fmt: in X2.3 Y2.3 no LZ) where specification only allows 2.4 format for imperial units.

[jean-pierre charras (jp-charras)]

Fixed in commit c2915058

[KiCad Janitor (kicad-janitor)]

Fixed in revision c291505830338e23bd7cf7a1a227f484ab15078d
https://git.launchpad.net/kicad/patch/?id=c291505830338e23bd7cf7a1a227f484ab15078d

[Andreas Fritiofson (andreas-fritiofson)]

So the Altium generated ;FILE_FORMAT=4:4 files are still not supported? Was that intentional or not? They are still 10x smaller that they should in GerbView 5.1.5.

[Maciej Suminski (orsonmmz)]

KiCad has migrated to Gitlab, this issue is available here: https://gitlab.com/kicad/code/kicad/-/issues/847