OpenPnP Footprint Manager - Introduction

[Marshall S. (Alakuu)]

Hi everyone,

Marshall here! I've developed a tool to help automate importing LCSC/EasyEDA footprints into OpenPnP. This has been a time-consuming manual process for many of us, so I wanted to share this solution with the community.

What it does:
The program reads your BOM file (CSV or Excel), identifies parts that need footprints, fetches the footprint data directly from LCSC/EasyEDA, and writes them into your OpenPnP configuration files (packages.xml and parts.xml). It handles the full workflow including part height assignment, nozzle tip selection, and creating proper backups before making any changes.

Key features:
- Automatic BOM parsing with support for CSV and Excel formats
- Direct integration with LCSC/EasyEDA API to fetch accurate footprint data
- Visual footprint preview before confirming
- Per-part height and nozzle tip configuration
- Automatic backup system with restore capability
- Handles shared footprints intelligently (one R0402 footprint used by multiple resistor values)
- Dark mode support
- BOM template export to help structure your files correctly

How it works:
The program follows OpenPnP's default naming scheme: "footprint-value" (e.g., R0402-10K, C0402-100nF). This matches the standard convention OpenPnP uses when you manually import parts. It processes your BOM, presents each unique footprint for confirmation, lets you adjust parameters, and then writes everything to your OpenPnP config in one batch.

Important limitations:
- Only works with parts that have LCSC part numbers in your BOM
- Parts without LCSC numbers are skipped automatically
- Requires OpenPnP to be closed during the write operation
- Currently tested only on Windows 10/11

The tool includes comprehensive backup functionality. Before making any changes to your OpenPnP configuration, it creates timestamped backups that you can restore from within the program. I recommend verifying everything works in OpenPnP after import before deleting backups.

Testers needed:
I've developed and tested this on Windows, but the code is cross-platform Python/PyQt6. I'm looking for volunteers willing to test on Linux and macOS to verify everything works correctly on those platforms. The Python script should work fine, but I want to make sure there are no platform-specific issues with file paths or OpenPnP config detection.

Technical details:
- Written in Python with PyQt6 for the GUI
- Uses httpx for LCSC API communication
- Parses OpenPnP XML files with lxml
- Available as Python source or Windows executable

I'll have the tool on GitHub very soon!

GitHub: https://github.com/SkreeCustomKeyboards/Openpnp-LSCS-Footprint-Tool

I've been using it for my own projects and it's saved me hours of manual footprint entry. Hoping it helps others in the community as well.

Looking forward to any feedback, bug reports, or feature requests.

Side note I made a rambling video that shows the whole process and then branch off into my ideal end goal with this and some other in the works projects at the end.
https://www.youtube.com/watch?v=1eg0B8x1NP4

Thanks,
Marshall Somerville
Skree LLC

[gong yi (K-Pax)]

great! very useful tool.

[Marshall S. (Alakuu)]

If you managed to get it up and running let me know what general environment you're running on!

[gong yi (K-Pax)]

I am using Windows 11, and everything is working fine, but it lacks a feature to update existing component packages.

[Marshall S. (Alakuu)]

So existing components would be challenging. This relies on the user providing the LCSC number to the part. If you don't have that connection already made (I'm trusting the user creating the BOM / schematic that the bom is made from) then logic to 'conclude' what the LCSC# becomes sketchy. 

[Marshall S. (Alakuu)]

One thing I really want to point out is these footprints are just the visual aid you use as setup.

Z height is important as it's part of the advanced calibration and placement math.

Body size is important and this is trying to have that correct BUT 50% of the time in my experience the vision pipeline disagrees with the on sheet body size.
This is generally because it's measuring bright points and then draws a BOX. If pads change that actual box size you're stuck needing to match what vision says the body size is. Period. 
You can tweak the vision pipeline to draw differently but the final decision is always vision. 

My workflow is to set a body size by the datasheet / footprint (what this does) then enforce vision body measurement. Vision will measure the part and 50% of the time say Failed on the first time I'm doing a specific part. This is fine though. The output says the measured size. I just ensure the box that it draws is accurate (it didn't pick up something else in vision or fail to see specific pins on the component) then use the number it provided.
If your lighting and parts are consistent you should be good with the values vision comes up with.

TLDR: Nozzle selection and Z height 'actually' matter. Body size 'actually' matters too but Vision pipeline determines this, not the datasheet, nor the physical measurements. These footprints are great for visual aids but aren't placement critical.