openpnp-tools — CLI toolkit for KiCad → OpenPnP workflow

[Christof Länzlinger]

Hi all,

I've been building a CLI tool to automate the repetitive parts of going from KiCad to OpenPnP. It's open source (GPL-3.0) and works with any strip feeder setup — I'm using it daily with an Opulo Lumen.

What it does:

- generate — reads a KiCad position CSV and generates an OpenPnP board XML with remapped package names. Fiducials are auto-detected, hand-place parts are automatically disabled.
- ensure-parts — creates missing parts and packages in OpenPnP config with correct heights, tape specs, nozzle tip assignments, and rotation offsets.
- assign — loads feeder assignments from a simple CSV, sets tape type, part pitch, and rotation automatically.
- map — generates a self-contained HTML page showing feeder positions, job parts, missing feeders, and board outlines. Optionally cross-references with a KiCad BOM for IPN/inventory tracking.
- config — manages the base machine config in a git repo (backup, apply, pull, save, status). Version-controlled calibration and vision settings with automatic backup using OpenPnP's own format.

The key idea: a single CSV file (openpnp-package-map.csv) maps KiCad footprints to OpenPnP packages and carries all the tape metadata (type, pitch, width, nozzle tip, rotation offset). This is the single source of truth shared across all projects. When you add a new component type once, every future project picks it up automatically.

Typical workflow:

# Generate board + ensure parts exist
kicad-cli pcb export pos ... | openpnp-tools generate -o pnp -n myboard
openpnp-tools ensure-parts pnp/myboard.board.xml

# Set up machine and run job
openpnp-tools config apply
openpnp-tools assign --reset-unused pnp/feeders.csv
# open OpenPnP, run job, close

# Save tuning changes
openpnp-tools config save -m "tuning: update from myboard"

With a Makefile this becomes just "make setup" before a job and "make save" after.

Install: binaries for Linux, macOS, and Windows on the releases page, or with mise:
mise use -g github:laenzlinger/openpnp-tools@latest

GitHub: https://github.com/laenzlinger/openpnp-tools

The interactive feeder map was inspired by Pat Deegan's psypnp scripts.

Happy to hear feedback, feature requests, or ideas for improvement.

[Chuck Hackett]

I was heavy into Eagle-Land but I am trying to transition to KiCAD.  I have a couple of boards transferred already.

I am also a novice at OpenPnP and need to get a better understanding of the "Raw" workflow but I'm a big believer in tools.

This looks like a very good start to me ...

My machine is a converted Quad IVc that uses auto-feeders (Z-rod breaking light sensor advances tape). These feeders 'latch' into a latching base with 70-odd slots (different feeders take up differing number of slots). I am just starting to understand referenceslotautofeeder and I assume it's the way to go in my case.  

In your mind, would it be hard to add support of referenceslotautofeeder to your program?  With some guidance as to the interface and approach I might be able to contribute this aspect.  

After that, it would be nice if there was a step that optimized feeder layout (number of placements and travel distance) to produce a suggested mapping of feeders to slots with the ability to "lock" certain common parts (bypass caps, etc) in certain slots.

Regards,

Chuck

[Christof Laenzlinger]

 Hi Chuck,

 Thanks for the kind words — great to hear you're making the move to KiCad + OpenPnP!

 Short answer: yes, adding ReferenceSlotAutoFeeder support is very doable, and I'd welcome a contribution.

 Here's how the tool is structured and what would need to change:

 he commands that are feeder-type-agnostic would already work for you:

  - generate — KiCad position CSV → OpenPnP board XML (nothing machine-specific)

  - ensure-parts — creates missing parts/packages in your OpenPnP config

  - map — the interactive feeder visualization

The map command in particular should be quite useful for a 70-slot bank — it shows at a glance which slots hold which parts, what's needed for the current job, and what's missing. With your setup it would also naturally show which cartridges need to be swapped when switching between jobs.

The part that needs work is assign — currently it does string surgery on machine.xml targeting ReferenceStripFeeder elements by name. For your slot auto feeders, the data model is different (slot → feeder cartridge → part), so we'd need to:

  1. Parse the slot positions and their installed feeder/part associations

  2. Set part-id on the feeder cartridge (not the slot)

  3. Optionally assign which cartridge goes in which slot

Best next step: could you share a snippet of your machine.xml showing a few ReferenceSlotAutoFeeder entries and the associated feeder/bank structure?

(Positions can be approximate — it's the XML structure that matters.) I can then sketch the parsing code and we figure out the right interface together.

The feeder layout optimization idea is interesting too — once we have the slot geometry parsed, computing a placement-count-weighted travel distance and suggesting a layout would be a natural extension. The "lock certain parts" constraint fits well with how feeders.csv already works (you'd just mark some slots as fixed).

Feel free to open an issue on the repo — happy to collaborate on this.

  Cheers,

  Christof

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/cb6b4d5c-160b-4921-baa6-cec9771d9662n%40googlegroups.com.

-- 
Christof Laenzlinger
chri...@laenzlinger.net

[cdh...@gmail.com]

“Best next step: could you share a snippet of your machine.xml showing a few ReferenceSlotAutoFeeder entries and the associated feeder/bank structure?”

 

LOL -Gladly!  As soon as I figure it out myself in manual setup 😊

 

I’m very new to this and I am bouncing off walls and feeling my way through.  I’m still learning how things are connected/hierarchy.

 

I’ll follow up with you when I surface on the other side … or drown … 😊

 

Chuck

To view this discussion visit https://groups.google.com/d/msgid/openpnp/1778087088286.7876808.1309286546%40laenzlinger.net.