Handcrafted Footprints for KiCAD

[WillTurner]

  Is anyone else writing their footprint files by hand? There are advantages/disadvantages of course.
  Some Con's

• you become responsible for managing your own footprint source library
• the process can be tedious in the early stages, until you build up your repertoire
• there is a new workflow required
• possibly more difficult when collaborating

Some Pro's

• complete control of your source, and a source-code history
• finer resolution in making backups from individual file, to project level
• much better reuse of bits and bobs (really, it's all code)
• better control over global parameters like your choice of resolution

A small example from my last project might help clarify what I'm talking about.

#
# Homeboard Edge Cuts for 200 x 130 4-layer board with CK7101 switch cutout and Kobiconn DIN cutout
# (C) Will Turner, 5 December 2023                     
#                                                || Change this each edit!
(module AAA_footprints:board-edge-cuts-Homeboard_32 (layer F.Cu) (tedit 62AAB011)
  (descr "Triton Homeboard")
  (tags "Triton")
  (attr virtual)
# Component identifier from schematic editor.
  (fp_text reference REF** (at 0 -26) (layer Dwgs.User) (effects (font (size 1 1) (thickness 0.05)) (justify left)))
# Component label from schematic editor.
  (fp_text value board-edge-cuts-Homeboard_32 (at 0 -24) (layer Dwgs.User) (effects (font (size 1 1) (thickness 0.05)) (justify left)))
#                                          ^^ Also change this each edit!

#
# Edge Cuts
#

#
# Edge cuts need to be carefully planned since tracks may not cross.
# Also, closed polygon :-).
#

#
# CK7101 Switch cut-out is 12.5mm wide by 21mm high.
#

# Top LH corner is x = 3, y = 51.5

# Starting at the upper left hand corner, and working anti-clockwise
(fp_arc (start 2.5 2.5) (end 0 2.5) (angle 90) (layer Edge.Cuts) (width 0.005))

# Launch point for the switch cutout x = 0, y = 51.5 - e
(fp_line (start 0 2.5) (end 0 51.49999) (layer Edge.Cuts) (width 0.005))

# Straight across to RH edge of the cut out, x = 3 + 12.5, y = 51.5 - e
(fp_line (start 0 51.49999) (end 15.5 51.49999) (layer Edge.Cuts) (width 0.005))

# Down the RH edge x = 3 + 12.5, y = 51.5 + 21
(fp_line (start 15.5 51.49999) (end 15.5 72.5) (layer Edge.Cuts) (width 0.005))

# To the left hand edge of the cutout x = 3, y = 90 + 21
(fp_line (start 15.5 72.5) (end 3 72.5) (layer Edge.Cuts) (width 0.005))

# Up to the LH corner completes the cut-out x = 3, y = 96.5
(fp_line (start 3 72.5) (end 3 51.5) (layer Edge.Cuts) (width 0.005))

# Back to the LH edge x = 0, y = 96.5
(fp_line (start 3 51.5) (end 0 51.5) (layer Edge.Cuts) (width 0.005))

# Down to the corner
(fp_line (start 0 51.5) (end 0 127.5) (layer Edge.Cuts) (width 0.005))

# Bottom left hand corner heading right
  (fp_arc (start 2.5 127.5) (end 2.5 130) (angle 90) (layer Edge.Cuts) (width 0.005))
  (fp_line (start 2.5 130) (end 397.5 130) (layer Edge.Cuts) (width 0.005))
#      Board width starts here  ^^^^^

# Bottom right hand corner heading up
  (fp_arc (start 397.5 127.5) (end 400 127.5) (angle 90) (layer Edge.Cuts) (width 0.005))
  (fp_line (start 400 127.5) (end 400 2.5) (layer Edge.Cuts) (width 0.005))

# Top right hand corner heading left
(fp_arc (start 397.5 2.5) (end 397.5 0) (angle 90) (layer Edge.Cuts) (width 0.005))
(fp_line (start 397.5 0) (end 2.5 0) (layer Edge.Cuts) (width 0.005))

# Instruction to JLCPCB staff. Text centre: x = 7 + 12.5 / 2, y = 51.5 + 21 / 2
(fp_text user "-- cut out --" (at 9.25 62.0) (layer F.SilkS) (effects (font (size 1 1) (thickness 0.153))))

#
# Kobicon DIN Connector cut out
#
# Centre is at x = 92.00, y = 33.75, radius 98.25 - 92.00 = 6.25mm
  (fp_arc (start 92.00 33.75) (end 98.25 33.75) (angle 360) (layer Edge.Cuts) (width 0.005))
  (fp_text user "-- cut out --" (at 92.00 33.75) (layer F.SilkS) (effects (font (size 1 1) (thickness 0.153))))
)
#
# end
#


At the top level of my schematic I put an "artifact" associated with this footprint. My list of "artifacts" also includes a fiducial, tooling holes, a visible "fascia" (essentially the silk layer), and a border "grid" marking the board territory.
  Deeper into the schematic, each component has a supporting source code file.

  As a starter, you can save the base code for a footprint from the footprint editor "File->Export Footprint" menu item. Edit, then bring it back into the footprint editor with "File->Import Footprint from KiCAD file".

  I am now managing all of my footprints like this. What do you think?

  A couple of notes if you try this

• you can copy the code above and give it a go, but I was in the process of making my board much bigger.
• the footprint editor will not respect your source code. It likely will delete all of your comments when you rexport code for example.
• rounding errors especially if a footprint is rotated will be much more visible
• you will want to get your fancy calculator, notebook, and pen out of the drawer.

Edit(s) : anticipated, especially if I decide to add stuff to the lists above.

[delfinom]

ಠ_ಠ

[Doctorandus_P]

I understand wanting a text based input for generating footprints, but doing it this way looks like a tremendous waste of time to me.
Writing some kind of script to generate the footprints is a much more sensible option.
With a script based approach, you add a few loops and then generate a whole library of similar footprints. For example for connectors with different amounts of pins.

KiCad already has a bunch of such scripts built in, and they also include bindings to the GUI. You can access them via: Footprint Editor / File / Create Footprint. These are 15 python scripts, and you can either fill in some parameter to generate a (start of) a footprint, or you can study the python code itself and then for example use it either as a base for your own footprints.


A lot of the footprints in KiCad's default libraries are also generated by scripts, but these are different scripts. They are not installed with KiCad, but you can find them on gitlab as part of the libraries.

[SiliconWizard]

I understand wanting a text based input for generating footprints, but doing it this way looks like a tremendous waste of time to me.
Writing some kind of script to generate the footprints is a much more sensible option.

Agreed here, footprint files are very low-level description of footprints, pretty inconvenient to edit manually, although of course to each their own.
But doing that from a script taking a slightly higher-level description of a footprint, why not.

[Karel]

If people prefer to use a text editor to create footprints, it means there's something really wrong with
the gui of the footprint editor...

[SiliconWizard]

If people prefer to use a text editor to create footprints, it means there's something really wrong with
the gui of the footprint editor...

I don't have a particular problem with the footprint editor of KiCad myself, but I wouldn't say that. There can be reasons for creating footprints from a textual description and in some cases, it can be more productive. As I said, probably not if editing the S-Expr files directly (although again we're all different), but a tool that generates them, based on your own preferences and workflow and whatnot, why not. This could be useful.

I use OpenSCAD on a regular basis for designing mechanical parts, it's a bit of the same idea. But again, this is a higher-level description of course. I wouldn't edit 3D file formats directly by hand.

[bpiphany]

If people use latex to produce documents, it means there's something really wrong with all wysisyg editors(?)

It's just about control. To handcraft exact locations, widths, hole sizes and so on. I (foolishly likely) like to stick to a set of "predefined" font sizes, hole sizes, rounded rectangle corner radii, line widths, and so on. Just because it makes my OCD a bit calmer =D More or less only double checking with the editor that the footprints "compile" correctly.

[JohanH]

I like the approach. At least that it is possible to do it this way. If you need to create a lot of similar footprints this is a good approach, especially as you could easily add your own scripting to generate generic parts. This is how stuff is done in other industry, too. I've written lots of XML code through the years for various script and build tasks.

KiCAD has lately implemented and improved various CLI commands, so there is clearly a move in this direction.

• the footprint editor will not respect your source code. It likely will delete all of your comments when you rexport code for example.

You should create a bug/feature request on https://gitlab.com/kicad/code/kicad/-/issues. Wysiwyg editors that delete scripted/manually crafted code that is otherwise correct, is not optimal. I have unpleasant memories of some editor deleting important compiler variables in some certain (now old and forgotten) script language.

[golden_labels]

If people prefer to use a text editor to create footprints, it means there's something really wrong with the gui of the footprint editor...

No. It means there exist tasks, for which GUI editors are suboptimal. In general, not KiCad’s GUI specifically.

Parametrization is one of them.

Being able to freely determine positions and dimensions in a convenient way is another example. Some things are better expressed in code. One can achieve most of it in a GUI, but then the program becomes a fully-featured geometric CAD or vector graphics editor — which would outgrow KiCad and duplicate existing tools.

[Warhawk]

My 2 cents:
- I like to have all my footprints having same look and feel. Some time ago, I wanted to change line thickness at some layer (courtyard?). I was able to use atom editor and then the "find and replace" command to do the job. Same with font size.

[Puteketeke]

The footprint editor (and pcbeditor in v5) is bad at modifying multiple objects. Sometimes I do some search and replace directly.
But writing a full footprint with primitives, never.

What I often do is
-create 'mylib' private library
-find the most approching footprint
-save  it my private lib
-tweak it

Some footprints are fun to do with a script and this is much more rapid and precise than the fpeditor.
An example

https://gitlab.com/kicad/libraries/kicad-footprint-generator/-/merge_requests/744/diffs

This one was done in one or two hours (when starting from a templates). Now (two years latter), needless to say that it is also a waste of time, no memories for fixing it;)


About remembering 'comments', Kicad is not a text editor. it reads textlines yes, to construct an internal C structure object in linked lists. They are then moved, deleted, inserted, blahblah then saved following the lists. No way (and  need) to remember the order of the initial list. So even if comments were read in some list, they would go 'sorted' in one block.

[nctnico]

If people prefer to use a text editor to create footprints, it means there's something really wrong with
the gui of the footprint editor...

No. When I create footprint (regardless the PCB package), I enter all coordinated by keyboard. Much more convenient and precise compared to using a mouse. For many complex parts, I start by converting the mechanical drawing to coordinates anyway.

[Karel]

If people prefer to use a text editor to create footprints, it means there's something really wrong with
the gui of the footprint editor...

No. When I create footprint (regardless the PCB package), I enter all coordinated by keyboard. Much more convenient and precise compared to using a mouse. For many complex parts, I start by converting the mechanical drawing to coordinates anyway.

I agree and that's what I did in Eagle V7. But with KiCad, last time I checked that wasn't possible, hence the texteditor...
Maybe it's better now in ver. 7.10?

[bson]

A lot of the footprints in KiCad's default libraries are also generated by scripts, but these are different scripts. They are not installed with KiCad, but you can find them on gitlab as part of the libraries.

Sometimes I feel like maybe they should distribute the scripts and not the footprint, just make the editor have a list of script parameters (in addition to actual non-scripted footprints).  Then if you want a 24 pin SOIC it just generates it for you, in your local project folder.  If you want something more special, like a USB connector footprint or such, it can copy it from the library to the project.  In other words, make the project copy first-class instead of a backup for recovery.  This way the projects would be (more) self-contained and simpler.