Gerbview - reading drill file

I’m attempting to read an Excellon drill file and Gerbview gives an error message saying “Tool not defined”.
I suspect that it isn’t able to determine which drill size to use, as all the holes show up with very small diameters when viewing the board.
Where is the Excellon drill file format defined and how does one define the “Tools” that Gerbview is looking for?
Thanks!

Would you mind posting your file? Use something like http://pastebin.com/

No problem… It was generated from Mentor PADS. It is not very big, so copied below.
Thanks!

.drl file starts here…
%
T1C.012F095S3
X010938Y006188
T2C.016F095S3
X005656Y000906
X003844Y001
X004875Y002437
X003844Y004437
X002125Y005219
X000906Y005219
X005844Y012406
X004312Y013531
X001094Y017719
X004156Y018219
X004156Y021188
X007375Y021188
X009656Y020125
X007437Y018281
X010281Y015375
X010125Y014438
X007844Y014094
X009344Y013469
X009813Y010703
X008Y009719
X009812Y009594
X010812Y009406
X010406Y009406
X006969Y008844
X008666Y007563
X009031Y006906
X00975Y006531
X009047Y006125
X006656Y004594
X010018Y004403
X007681Y003934
X007549Y003067
X010531Y001656
X011813Y002656
X012209Y003938
X013375Y004469
X011813Y004937
X011321Y007126
X011808Y007913
X012313Y00811
X011089Y008367
X011813Y009047
X012719Y009469
X013402Y009476
X012719Y009875
X011281Y010875
X013156Y011062
X012625Y011062
X013184Y011625
X012625Y011625
X013156Y012156
X012625Y012188
X011438Y012422
X013402Y013257
X01287Y013257
X011438Y013453
X011906Y013469
X011Y013469
X013063Y015084
X011406Y017875
X010906Y017906
X01587Y01907
X01587Y017788
X015031Y017563
X015839Y01632
X01587Y015476
X014652Y015101
X015152Y014663
X013688Y014515
X015714Y014491
X015777Y013382
X014375Y013094
X015058Y012976
X015058Y012538
X013719Y012156
X013719Y011625
X013719Y011062
X015828Y01075
X015828Y010313
X015156Y009906
X013406Y009875
X015828Y0095
X014188Y0095
X014594Y0095
X015063Y00811
X01587Y007976
X015839Y006601
X013813Y005656
X015839Y005132
X014875Y004469
X015839Y003695
X014969Y002687
X0135Y002687
X015839Y002257
X014219Y001219
X015819Y00077
X015906Y012
T3C.028F197S55
X01Y011688
X0105Y011688
X01Y012188
X0105Y012188
X01Y012688
X0105Y012688
X013882Y02052
X014382Y02052
X014882Y02052
X015382Y02052
X015882Y02052
X014882Y02002
X014382Y02002
X015382Y02002
X013882Y02002
X015882Y02002
T4C.037F197S55
X00225Y007
X00125Y007
X00225Y008
X00125Y008
X00225Y009
X00125Y009
X00225Y01
X00125Y01
X00225Y011
X00125Y011
X00225Y012
X00125Y012
X00225Y013
X00125Y013
X00225Y014
X00125Y014
X00225Y015
X00125Y015
X00225Y016
X00125Y016
T5C.04F139S55
X006652Y0009
X011652Y0009
T6C.093F066S55
X004362Y0115
X019906Y0115
T7C.168F035S1033
X00125Y00275
X00125Y02025
M30

Seed a search engine with “Excellon file format” and you get (at least) three web pages that seem to tell you more than what you need to know:
http://web.archive.org/web/20071030075236/http://www.excellon.com/manuals/program.htm
http://flatcam.org/fileformats
https://en.wikipedia.org/wiki/Excellon_format (Note the comments about the pervasiveness of non-compliant, so-called “Excellon” files.)

A drill file I recently generated with KiCAD starts with these lines:
M48
;DRILL file {KiCad (2016-03-13 BZR 6620, Git 44fc6cb)-product} date 14/03/2016 14:16:57
;FORMAT={-:-/ absolute / inch / decimal}
FMAT,2
INCH,TZ
T1C0.018
T2C0.032
T3C0.035
T4C0.039
T5C0.047
%
G90
G05
M72
T1
X2.164Y-5.4916
X2.623Y-5.626
. . . .
. . . .

So based on my cursory observations, and not knowing what I’m talking about, I’ll put forth the following WAG’s:
- Your file seems to be missing a header. Yeah, there’s probably something in the Excellon file spec document that says, “If the header doesn’t specify the parameters or options, the file parser may assume the following values. Or it may not. Do you want to take a chance, or do you want to include a few header lines?”.
- Your file seems to be using “Leading zeros” (LZ) sted “trailing zeros” (TZ). That shouldn’t be a problem if the file parser on the receiving end either reads the header lines, or makes a correct guess about the number format.
- The Tool Definition statements in your file specify the drill size with a decimal point ( “.” ) - e.g., T1C**.012** . . . . . The file parser seems to interpret this as a drill size of twelve-thousandths of the smallest Excellon unit. That’s gotta be getting close to the size of a molecule!

If you want to manually play with this file, try taking out the decimal points from those tool definition statements and see if the hole sizes look more reasonable in Gerbv. You can also make a guess at what the header statements should have been. Of course, you’ll back-up and archive this file before you attack it with an editor, right?

Dale

1 Like

Thanks!
I was able to decipher the Drill file and get it to import correctly into Gerbview.

I was also able to import the other layers.

However when running “Export to pcbnew”, many more vias appear than expected. The manual says that a via is generated wherever a flashed item appears in the gerber file.

Is there any way to avoid this (and have vias based on drill positions?

I checked and this is now fixed in 20 June Build (r6943) :slight_smile:
This fix also covers some issues with G85 slots.
See image below for correctly imported PHO and DRL, with slots.

1 Like

I have a user that is having a similar problem with Gerbview 7.61. We can get all layers but the drill layer (a .txt file) to import correctly. CktDesigner how did you decipher the drill file and get it to import correctly?

Hi mp77,

The drill file produced by PADS used a tool format that Gerbview didn’t
understand.

See the example .drl file I posted on Apr 18. Notice that the tool
statements seem to combine the tool name and definition:

T1C.012F095S3

X010938Y006188

Gerbview (at least the version I was using) wants the tools defined
separately (before using them). So the updated file looks more like:

M48

INCH,LZ

FMAT, 2

T1C0.012

T2C0.016

T3C0.028

T4C0.037

T5C0.040

T6C0.093

T7C0.168

%

G90

G05

M72

T1

X010938Y006188

Where some header information and Tool definitions are provided before
the list of drill points are given…

I manually edited the file…

Hope this helps!

Looking at my notes, and using a recent GerbView (mid Aug)

Attached edited PADS file loads ok, and so too does the non edited one, which is set to the same
;FORMAT={2:4/ absolute / inch / keep zeros}

I think they did fix some aspects of GerbView ?

drl001_ET_GerbViewOK.drl (2.0 KB)
drl001.drl (1.8 KB)