# LumenPnP: an open source pick and place machine you can buy or build

> The LumenPnP is an open source pick and place machine from Opulo, sold assembled and documented as hardware source plus an OpenPnP setup. Here is what the repository contains, how to get a machine running, and where the project's documentation stops short.

**opulo-inc/lumenpnp** — The LumenPnP is an open source pick and place machine.

- Repository: https://github.com/opulo-inc/lumenpnp
- Stars: 3,660 · Forks: 502
- Language: HTML
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/opulo-inc-lumenpnp

## What problem the LumenPnP solves, and who it is for

Small-run electronics assembly has an awkward middle. Hand placement is slow and inconsistent once a board carries more than a few dozen parts. Contract assembly houses want volumes and setup fees that do not suit a batch of twenty boards. The LumenPnP sits in that gap: an open source pick and place machine that the README describes as assembling electronic components onto circuit boards, with machines "being used in active production daily" according to the same document. The intended user is a hardware team or a serious individual who wants to place parts in-house and who is comfortable treating the machine as something to be configured and maintained rather than a sealed product. The README also states that the project includes feeders designed to work with the machine, with the powered feeder source living in a separate repository, opulo-inc/feeder. That detail matters for scope: this repository is the machine, not the whole assembly cell.

## What is actually inside the lumenpnp repository

The top level is a hardware and firmware project, not an application. Alongside README.md and LICENSE there is DESIGN_DECISIONS.md, bom.csv, and three directories that carry the real weight: pnp/, openpnp/ and lib/. There is a .gitmodules file, so parts of the tree are pulled in as submodules rather than vendored directly. The README is explicit that exported artefacts (STLs, schematic PDFs, compiled binaries) are attached to the latest release rather than committed as build outputs, which is why the repository reads as source. The primary language reported for the repository is HTML, a consequence of documentation and generated pages rather than of the machine logic itself. If you are evaluating this as software, adjust expectations: the interesting content is CAD, board files, firmware and an OpenPnP configuration tree.

## How the machine and its software fit together

The README points at the wiki for the state of the project, contributing instructions and frequently asked questions, and that is where the operational detail lives. The openpnp/ directory in this repository is the bridge between the hardware and the control software: OpenPnP is the host application that drives the machine, and the project ships its configuration for it. Release v4.1.0 is titled "Secondary Fiducial Support, OpenPnP v2.6", which tells you two things at once. First, the project tracks a specific OpenPnP release line, so the version of the host application is a compatibility constraint, not a free choice. Second, fiducial handling is part of the release surface: secondary fiducials are an alignment feature, and support for them arrived in this version rather than in the v4.0.x line. The data flow is conventional for this class of machine. OpenPnP holds the job, the board definition and the component placements; the machine's controller executes motion; the camera feeds back positions for alignment. The repository supplies the machine-side half of that contract.

## Getting a LumenPnP and making the first placement

The README does not give a build procedure. It says the machine is available for sale on the Opulo website and directs readers to the wiki, so the first step is documentation rather than a command. The repository itself is fetched with git, and because .gitmodules is present, a plain clone is not enough on its own.

```bash
git clone --recurse-submodules https://github.com/opulo-inc/lumenpnp.git
cd lumenpnp
```

After that, the two directories worth opening first are pnp/ and openpnp/. The exported artefacts you need for a build (STLs, schematic PDFs, compiled binaries) are attached to the latest release, so check the release assets for v4.1.0 before assuming the tree contains printable files. The BOM for the machine is bom.csv at the top level, and the README also points at the separate feeder repository for powered feeders.

```bash
ls pnp openpnp
head -5 bom.csv
```

What you should see is a parts list with real line items and two directories of source. What you should not expect is a single command that brings a machine online. The README states plainly that the wiki covers the state of the project and the FAQ, and that is where commissioning steps belong.

## Where the LumenPnP is the wrong tool

The documentation gap is the first limitation. The README does not document rollback, and it does not describe what happens when a firmware or configuration change leaves the machine in a bad state. For a machine that runs production, that silence is a real risk: you are expected to work from the wiki and from the release notes, and the release notes for v4.0.1 are titled "Tweaks and Adjustments", which is not a migration guide. The second limitation is scope. The README treats feeders as part of the system but keeps their source in a different repository, so a reader who clones this repository has the machine and not the feeding setup. Third, the version coupling to OpenPnP v2.6 in the v4.1.0 release means you cannot casually upgrade the host application and assume the shipped configuration still applies. If your requirement is a machine with a vendor support contract and a documented upgrade path with rollback, this is not that. If your requirement is a black box that places parts without you understanding its configuration, this is also not that.

## LumenPnP versus OpenPnP, and versus assembling by hand

The comparison that search traffic keeps asking for is LumenPnP versus OpenPnP, and the answer is that they are not the same kind of thing. OpenPnP is the control software; the LumenPnP is a machine plus the configuration that lets OpenPnP drive it. Choosing OpenPnP alone gets you an application and no hardware. Choosing the LumenPnP gets you a machine whose openpnp/ directory is tuned for it, and the v4.1.0 release pins that relationship to OpenPnP v2.6. The other real alternative is not a different machine but a different process: hand assembly with stencils and a reflow oven. That approach needs no configuration, no fiducial calibration and no firmware, and it scales down to a single board gracefully. It stops scaling when placement count and repeatability start to dominate your time. The honest dividing line is whether you will run enough boards that the setup cost of a machine is repaid, and whether you want to own the configuration work that comes with it.

## Maintenance, releases and what the licence actually tells you

The repository is not archived, and the last push was on 2026-09-23. Release cadence is uneven in a way that is worth reading carefully: v4.0.0 arrived on 2024-09-09 with a new motherboard, control box and dual drag chain; v4.0.1 followed on 2025-01-10 as tweaks and adjustments; v4.1.0 landed on 2026-02-25 with secondary fiducial support and the OpenPnP v2.6 alignment. That is roughly one substantive release per year, so plan for a long-lived configuration rather than a stream of patches. The upgrade cost sits mostly in the OpenPnP version coupling and in hardware revisions: v4.0.0 changed the motherboard, which means a v4.1.0 configuration is not automatically meaningful for an older board. On licensing, GitHub reports the licence as NOASSERTION, meaning the platform could not classify the LICENSE file automatically. The README and repository do not summarise the terms, so read LICENSE and DESIGN_DECISIONS.md directly before you build a product around the design. This is not legal advice; it is a pointer to the two files that carry the answer.

## Conclusion

Adopt the LumenPnP if you want a pick and place machine whose hardware source, BOM and firmware you can read and modify, and if you are willing to work through the wiki and the OpenPnP configuration rather than expecting a turnkey appliance. Do not adopt it if you need a documented rollback path between firmware versions, or if you want the repository alone to be your build guide: the README points at the wiki and the release assets, and the top level is source, not a manual. Before committing, verify three things: which machine revision the v4.1.0 release assets match, whether your feeder plan is covered by the separate opulo-inc/feeder repository, and how the openpnp/ directory in this repository relates to the upstream OpenPnP release the project targets. Those three answers decide whether the machine fits your line.

## FAQ

### What is the LumenPnP?

It is an open source pick and place machine from Opulo that assembles electronic components onto circuit boards. The README states that machines are being used in active production daily, and that the project also includes feeders designed to work with the machine.

### Is the LumenPnP open source?

The README describes it as an open source pick and place machine, and the hardware source, BOM and OpenPnP configuration are in the opulo-inc/lumenpnp repository. Note that GitHub reports the licence as NOASSERTION, so read the LICENSE file yourself rather than assuming a specific licence.

### Is there an open source pick and place machine available?

Yes, the LumenPnP is one, and the README says it is available for sale on the Opulo website as well as being documented as source. Exported artefacts such as STLs, schematic PDFs and compiled binaries are attached to the latest release.

### How do the LumenPnP and OpenPnP relate to each other?

OpenPnP is the control software and the LumenPnP is the machine, with this repository shipping the openpnp/ configuration for it. Release v4.1.0 is titled "Secondary Fiducial Support, OpenPnP v2.6", so the shipped configuration is tied to that OpenPnP version.

## Sources

- [Issues](https://github.com/opulo-inc/lumenpnp/issues)
- [opulo-inc/lumenpnp on GitHub](https://github.com/opulo-inc/lumenpnp)
- [README](https://github.com/opulo-inc/lumenpnp/blob/main/README.md)
- [Releases](https://github.com/opulo-inc/lumenpnp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opulo-inc-lumenpnp
