Updates to KiPart

KiPart has been around for about a year. It takes a CSV spreadsheet file describing the pins of a part (or parts) and generates a KiCad schematic library.

I’ve added another utility to KiPart called kilib2csv. It “completes the circle” and allows KiCad libraries to be converted to CSV files that can serve as the input to KiPart. This allows you to take one or more existing KiCad libraries, convert them to a CSV file, edit all the parts in a spreadsheet, and then regenerate the library with KiPart.

I developed this primarily to use libraries of parts where they didn’t set the pin types correctly (i.e., they just made every pin an input). Making the wholesale changes was easier in a spreadsheet than laboriously clicking on every pin in the library part editor.

The only downside is that any graphics for the part symbol are discarded. (KiPart draws every part as a box.) That doesn’t matter to me since I’m moving away from designing schematics graphically and all I need is the pin data, but it might make a difference to you.

I also added the capability to set the part reference prefix for each part within the spreadsheet. (Previously, it just defaulted to “U”.)


Sounds cool.

That sounds a good idea.
You may also find useful the attached python file that generates a NET report from a PCB design, ( in PADS Ascii format - easily human scanned and version checked)

This would allow a design with multiple NET sources (any mix of SCH and/or multiple scripts), to save a PCB snapshot for verify of critical NET changes.

PcbNew_Export_PADS_NET.py (20.6 KB)

Have you seen QEDA ? Just saw this mentioned in another forum…

It uses YAML ascii files, to describe both SCH and PCB symbols, in Text files.

leads to the ASCII file part descriptors


This would allow you to use any mix of Graphical and Text-File flows, for NET sources and Library sources, right up until the PCB layout itself.

1 Like

Thanks for the netlist extraction script!

QEDA looks interesting. I’m for anything that reduces the amount of repetitive point-and-click and the other problems that GUIs introduce. But I don’t know much about YAML. Does it provide programming constructs that I can use to describe an entire symbol or footprint? Or do I have to specify every pin individually? Or is this something I would do in a general-purpose language by making use of a YAML library?

Looking at the second link yaml, that is a full SMD connector, with outline and 2 mounting tabs, and 6 pins. (image on their examples page)

padWidth1: 0.7 padHeight1: 1.8 rowCount1: 1 rowDY1: 3.3 columnCount1: 6 columnPitch1: 1.25

seems to generate the 6 pins in an array, then the mounting tabs follow

padWidth2: 1.6 padHeight2: 2.2 padPosition2: -4.675, 0, 4.675, 0

seems to use a simple list of X,Y to repeat.
The QEDA author has the parsing engine for those files, and applies IPC rules and PCB fab rules, to make the actual KiCad footprint files.

You could do your own parser, & there is a yaml parser for Python.

It is probably not a lot of work to at least add yaml as alternative choice to your csv for SCH side ?

schematic: symbol: connector right: 6-1 top: 8 bottom: 7

The QEDA way seems to be one way - description > symbol+footprint - so that one always comes from the master description and creates current symbols+footprints.

KiPart is two way csv <-> symbol+footprint (within limits).

Personally I’d expect the KiCAD library maintainers to jump onto QEDA and use it - if it works reliably.
Should make library maintenance a breeze.

Yes, what I have seen impresses, and I’ve been looking around for ways to define parts in an ‘easier’ way.
Certainly KiCAD library maintainers could use this !

Yes, tho the same reverse path could be added, in either format I expect.