Creating a pad from a DXF import gives error


The footprint editor of KiCad is quite limited. For most footprints its feature set is good enough. (Array function + user grid)
Even for simple footprints the user needs to do quite a bit of math to find out where to place a pad and what size does it need to be. Especially if the datasheet does not dimension the pads via center coordinates plus pad size.
Most datasheets do not dimension pads such that you can directly read the values you need to enter into kicad. The reason behind that is the manufacturers need to also communicate tolerances.

The support for more complex footprint is a bit lacking. Especially support for complex pad shapes. Such footprints are a lot easier created in a tool like the freecad sketcher. You can in such instances simply recreate the dimensioned drawing given in the datasheet. (Example the x2son-4 footprint in the official lib and its freecad source file)

Some manufacturers supply a dxf (or step) file containing the suggested outline of the footprints pads. To reduce human error it might be good to have a way to convert this dxf directly into a footprint. As this topics discussion revealed it is not easily possible to import a dxf drawing into kicad and convert it into pads. (dxf import seems to mainly aim for getting the body outline into the footprint editor.)
With kicad stepup you can import the dxf into freecad and create a valid footprint that way.

parametric vs direct cad is not a clear this is better than that question. Both have their benefits and are used for different use cases.

I am just used to the parametric way of doing things. I like to see the dimensions entered in the sketch tool. (And the fact that i can change the dimensions later on is a bonus)

Now lets see what others think:


I have very little experience with general CAD tools or the concepts, but I think about it this way:

Take almost any land pattern example from any part’s datasheet. If you would design an editor from scratch wíth which you could create a footprint file with as little work as possible, how would that editor work? Certainly not like the KiCad editor. Instead, it would have WYSIWYG dimensions in the view and you would be able to edit pads and locations without opening any property dialogs and especially without calculating anything, not a single number. Basically it would be almost 1:1 view with the datasheet view to which you could insert values.


The focus here is about the difference between ECAD and MCAD.
KiCAd is an ECAD sw, FreeCAD is a MCAD sw. You should get the best from each environment.

KiCAD as @Rene_Poschl already stated, has limited support for footprint and pcb edge designing…
Unless you are willing to improve the KiCAD footprint editor, adding your code to kicad repo, or you can convince developers to do it for you, this is what we have ATM.
Some related topics here:

Moreover you are lucky that you get most footprints already done by the great KiCAD Librarian team!
And there is also a nice kicad python wizard for many footprint types…

At the same time there is not a fully mechanical kernel implemented in KiCAD, so the choice is or to implement it inside (a lot of work and a long lasting path) or just embrace the ECAD MCAD collaboration…
Here you can find a nice document on ECAD/MCAD bidirectional collaboration:
Eagle quite recently has embraced exactly this path:

Other ECADs have their own internal mechanical kernel for measurements and designing, but this still is not the best way, in my opinion, because you will not get the full power of a mechanical sw into a pcb sw.


At least the qfn script is not really a good idea to be used. It centers the pads around the part outline. This means there is no way to independently control the heel and toe fillet. (toe is always half of pad size. heel always half of pad size minus “lead” length.)

Currently the wizards are part of the kicad source repo. Sadly i noticed the above to late otherwise i would have asked to transfer the footprint wizards over to github to us librarians who are more experienced in checking if a footprint makes sense. (For footprint wizards it is not really important that the source code looks nice or that the git history looks well as long as the footprint created by it is good. The devs however seem to have their priorities the other way round.)

So if you want scripted footprints head over to


I prefer drawing footprints in what I call “parametric” CAD. In these tools, you don’t draw on a grid, but instead you say “this line starts at the origin, is exactly 34.6mm long and is 12 degrees from the x axis”. You can then create other lines and shapes as a function of the original object (a 1mm circle centred on the end of the line, etc)

Each of these dimensions or variables are parameters to your drawing. If you find later on that your line should be 35mm instead, updating that length will cause everything that depends on the line to also be updated.

There are lots of interesting constraints that allow you to draw things very precisely, for example: force two circles to be concentric, repeat an object around another object in a circle, force two lines to be colinear or perpendicular or equal in length, etc.

Why is this useful for footprints? Because aside from the simple footprints like 0805, every manufacturer seems to show the measurements of a part in some funny way. One of my pet hates is when manufacturers list the spacing between some pads from the centres and then some from edges, often randomly mixing the two in the same drawing. With parametric sketching tools you can just set any one point to be a fixed distance from another point, and it solves for all of the interim dimensions. No more cascading errors from doing the maths in your head!


@maui, @Rene_Poschl, @jer thank you all for answering. I have read your posts once, but suppose to have read it and linked info several times till I understand fully (now I see the global idea only). I put link to this thread into my “must read soon”.

In 2004 when we start to design according EMC I took our PCB designing from someone else as I am the only one here who feels EMC. We never used footprints designed by someone else. When I took PCB design most footprints we use were defined. So with each new project I had may be one new footprint to define and no more. As in Protel we worked with mils (I don’t know why but that was old decision and I never thought to question it) each footprint defined typically in mm I had to convert to mils. Since more that 10 years I have in my calculator memory the value 0.0254 written and don’t use its memory for anything else :slight_smile: Calculating pad centres and others never horrified me. I think because of it I don’t feel the problem with footprint design as being so big as it looks from some discussions here (I understand the people whos task is to make KiCad libraries).
Thinking of using KiCad I first looked about how to get the PCB printed documentation we need (as in Protel it was time consuming process, and needed to be carefull not to have to do everything once more - I didn’t like it). I didn’t considered to use for it the other graphic program. I wonted to get it directly from KiCad (and not using Python - I don’t know it). I think I found the way (not sure - haven’t done one yet) but to do it I have to have the footprints defined differently then in KiCad libraries. I didn’t see in that any problem. I will have some more work at the beginning but after few PCBs I think I will be back at the state that new design - one, two new footprints.
When I had some basic footprints as I wont them I found here that I probably could get what I wont using KiCad footprints and going through gerber view (I didn’t thought about it previously). Now I don’t know what will be my way of using KiCad. I wait for V5 with my final decisions.
I also don’t like the symbol library so I have my own :slight_smile:


Why don’t you?
All footprints in the KiCAD libraries are very accurate and follows strictly KLC rules…
KiCad Library Convention
There are very little footprints needed to be done from scratch, most on not frequently used parts or connectors…
I think that the KiCAD libraries are a great resource! Thx a lot to the Librarian Teamwork! :smiley:


Most of our footprints are indeed quite good. But if the user wants to reflow solder them it might still be required to make some minor adjustments.

This is true for every library. Reflow soldering requires adaptation for the specific manufacturer and process used. (At least if you want to optimize your yield and therefore reduce your costs)

This is very noticeable for footprints with a large exposed pad in the center and thermal vias within it. There it highly depends on your manufacturing capabilities what you do to avoid solder wicking. (top or bottom tenting, filling the via with copper or plastic, via in pad, …)

And of course the pcb manufacturing capabilities influence pad sizes as well. As the manufacturing tolerances and placement tolerances play a role when calculating the correct pad sizes.

If you handsolder your boards or are not really concerned with optimizing your yield you will most likely be able to use the footprints provided in the oficial lib.
Rule of thumb: If you normally simply create the footprint after the suggestion of the datasheet you can use the official footprints. (You should still check them for correctness as they could have a mistake in them. But this is also true for footprints in your personal lib. Never ever simply trust anything you have not personally checked.)

For symbol libs this is less of an issue. But here there is at least the question if you want some pins stacked or if you want all of them visible. (I have seen very heated arguments between people with strong opinions for either workflow. Please don’t start one here.)
Maybe you want to include some ordering information.

In short: The official lib can never replace the creation of your own personalized libs. But we can make the work for you easier by providing high quality symbols, footprints and 3d models that you can take as a starting point.
If you don’t have special requirements for yield or long therm reliability you should be ok with using the footprints as they are.


Custom pads are definitely supported by DRC. If you do find any issues with this, please let us know!

To make a filled custom pad, you would either create a polygon (as you say) or fill the space with other shapes. In the OP’s case, he/she could add an anchor pad that fills the space. Of course, StepUp, works excellently for this as well! Always nice to have a couple options.


Every primitive other then polygons does not fill space. Adding an arc, circle or even a closed shape made of lines does simply convert that primitive into copper. So if you want to create a filled arc you would need to add many overlapping arc primitives.

The problem discovered in this topic was that it is not possible to convert the lines you get from a dxf import into a polygon. This means if you make a pad from them (with adding a reference pad of course) the shape created will not be filled. So the only good option is to use freecad stepup.


Hi Seth,

There are a number of issues with the kicad-only route. Firstly, the DXF objects are imported as lines with a non-zero linewidth rather than as polys, so all of the pads are swollen. In addition, it is sometimes not easy to fill an arbitrary shape, notwithstanding that this is pretty slow.

At least in diptrace, it works perfectly. The steps are:

  1. Open footprint editor, import DXF
  2. choose which layers are top pads, TH pad holes, top silk, mounting holes, etc
  3. Your footprint is now exactly the same as your DXF (in the same way that StepUp generates the footprint)


@maui, @Rene_Poschl I will reply in few days. I plan to show why and I need time to do it. 17.05 my PCB manufacturer has a promotion day (preparing costs for any prototype 5 times lower than standard) and I need to design about 6 RFID antennas for experiments and I have designed my first KiCad PCB but think first try of gerbers are not as I wont (some global settings probably not correct). These are my priorities now.


Ah, thanks for the clarification. I’ll give some thought to how we might be able to handle this case.


here a sample with primitives, but not filled
primitives-geo-test-not-filled.kicad_mod (647 Bytes)


this is the message I get when I move the lines from i.e. FSilks to F.Cu in the path to design a custom pad…

BTW if ARCS as PADS are supported by DRC, also ARC TRACKS could be allowed/supported…
Does it sound fine?


Floating graphic items on the copper layer are not yet handled by DRC. Making them into a pad places restraints (specified net, single outline, etc.) that are handled by DRC.

To make a custom pad, you don’t need to move the item to the copper layer first. Try selecting the graphic items on a different layer along with the anchor pad. This will move the graphic items to the pad layer and merge them.

Arc tracks could be allowed/supported. In fact, a really back-handed way of doing this currently is to create a footprint with two pads but only one net. One pad is a custom shape with the arc, the second is a copy of the reference pad and at the other end of the arc. Here’s an example of this for a 0.4mm track with 1mm radius curve:


(module Arcs:1mmArc (layer F.Cu) (tedit 5AFB1D38)
(fp_text reference REF** (at 0 -2) (layer F.SilkS) hide
(effects (font (size 1 1) (thickness 0.15)))
(fp_text value 1mmArc (at 0 2.5) (layer F.Fab) hide
(effects (font (size 1 1) (thickness 0.15)))
(pad 1 smd circle (at 1 -1) (size 0.4 0.4) (layers F.Cu F.Paste F.Mask))
(pad 1 smd custom (at 0 0) (size 0.4 0.4) (layers F.Cu F.Paste F.Mask)
(options (clearance outline) (anchor circle))
(gr_arc (start 1 0) (end 1 -1) (angle -90) (width 0.4))


probably you missed that conversation:

Sure, it would be awesome if someone could work on it. It’s not in the
plans for the 5.0 release, although some base code for handling arc
tracks could be already written: geometry functions that we’ll need for DRC:

  • implement a SHAPE_ARC for the geometry library, describing a non-zero
    thickness arc
  • write an arc to segment collision function (see SHAPE::Collide)
  • write an arc to arc collision function.



I tested it and the footprint posted by @Seth_h works with DRC in todays kicad nightly version.

So i would assume the discussion found by @maui was before custom pads with arc primitives where added.


no, the issue is on track size… DRCs are working on the center of the track, not on the external boundary afaik


I think i now have no idea what you mean. Could you show a case where the footprint posted violates drc but is not reported?