Creating a footprint with drilled holes

the best would be that someone whos missing that feature, would file the request as bug / whishlist at


to let the k developers that this is required by e.g. OSHpark
probably OSHpark people just treat NPTH as PTH, and they do not plate the drill in case of no annular

I’ve read that copper going over the edge or over drill holes will get them plated for the hard-to-communicate-with chinese fabs (*).
This naturally implies that the CAM system processes both the gerber and drill file together at some point.

*) found my source: http://electronics.stackexchange.com/questions/78094/how-to-specify-castellations-in-gerber-files

… most board fabs will plate any copper that is over or directly touches
the edge of a hole or routed feature. So a ‘standard’ way of defining
this is just to have copper over the edges of your castellations. This
is how vias and plated through holes work - and conversely, this is how
non-plated holes work as well (you just pull back the copper a little
bit from the hole).

So to distinguish between PTH and NPTH in a single NC drill file the CAM system needs the copper layers.

Has someone filed this prob to launchpad bug?
There is still little time after RC2 has been rolled out, to include that feature before the stable will be released…

I just keep using BZR6097 and maybe the boardhouse I use can handle PTH/NPTH in separate files in the future when I upgrade :slight_smile:
But yeah, if you open a wish for that I’ll vote in favor of getting this feature back in there. Although I can see the point in staying with the specification and not working around stuff.

I did not, because I don’t feel like I understand the whole issue. I can’t believe someone would deliberately remove the option to merge both drill files, since every board fab I used requires one drill file, not two, and merging them manually is not obvious. Basically, this move would make KiCad unusable for work with OSHpark, ITEAD, Seeed and probably many others.

So, there must be something I’m missing?

I filed it…
[I updated the link because I moved my comment to a new bug file, as suggested by the bug manager]

the reason is summarized as following by the author:
Revision ID:
jp.charras@wanadoo.fr-20151026074330-l735o9z79l6o4wn6
Pcbnew, dialog create drill file: remove option to merge plated holes and not plated holes:
reasons:

  • This option is called “bad practice” in gerber files format specifications and is even forbidden in gerber drill files
  • Generates problems with some board makers because these holes are not identified in a single NC file
  • No one was able to explain us how to identified them in a single NC file
  • Recent change in drill file generation is not compatible with merged holes (minor reason)

if someone wants to add a comment it would help to see if the merging could be added again :slight_smile:

Hm… I have to rethink my support stance in this matter.
Have you seen these @maui?

Seems KiCAD was missing this ‘workaround-the-specs’ feature until 2014?

Also, the gerber specification is the source of this bit:

This option is called “bad practice” in gerber files format specifications and is even forbidden in gerber drill files

https://www.ucamco.com/files/downloads/file/81/the_gerber_file_format_specification.pdf (page 141)

OSH park and any other board house is clearly in “violation of the rules” set forth by the gerber specifications and this kind of behavior is definitely frowned up on.
Now I understand ideal vs real world and in the end the finished product counts, but it’s pretty clear who is to blame here.


The version of GerbView that comes with BZR6097 doesn’t have the option of exporting gerber files though… or it’s a different program, dunno?
http://gerbv.geda-project.org/

And some more googling found this bit ( https://www.reddit.com/r/KiCad/comments/2av8bl/nonplated_through_holes_with_osh_park_and_kicad/ ):

somewhen around July 2014…
It might not be a problem much longer! We’re currently putting in a fix to automatically combine the drill files, so if that works out well then it won’t matter if you have two drill files. For the immediate future, you’d need to merge the files into a single drill file with both plated and non-plated holes. We use GerbV for this, which is pretty quick and easy. If you’d like, you can send the files over and I can help out as well.

Also keep an eye on the Drill File support pages, since I’ll be updating those to show the proper state of the server as soon as our fix goes live. Could be as soon as tomorrow!

Might be time to check up on that with OSH park and not demand work-around-the-spec features from KiCAD?


Don’t see any updates on that page though…

@Joan_Sparky

GerbV version 2.61 (the latest stable) does not support correctly oval drill, so if you merge PTH and NPTH drill files with that tool, you will have a wrong result and you will produce a bad board… and I wouldn’t trust the buggy GerbV beta version (which is not been updated since an year)

I know that kicad is acting in the right way, but at the same time I would appreciate the option to merge the files internally, only when needed to give those files to the ‘blamed’ fabs :slight_smile:

thanks to @Joan_Sparky for pointing out the OSHPark support

"We support both vias (plated holes) and unplated holes. The fab uses 
the presence of copper underneath the drill hit to determine plating. 
Copper  underneath the drill indicates a via/plated hole, no copper 
indicates an unplated hole. "

and espitall (damien-espitallier)
for let me know that

Altium Designer (15.1) default setting is to use only one file. 
It add ";TYPE=PLATED" or ";TYPE=NON_PLATED" before the tool definition list of each kind.

as @firewalker pointed out here

merging option is back :slight_smile:

Yes! Good to hear that! :smile:

Unfortunately, the Ubuntu packages haven’t caught up yet. But they did catch up with the removal of the option. So now I’m stuck and can’t order boards because of this.

I hope developers will understand that they need to be a bit more careful with arbitrary option removal now that KiCad gets used more widely.