OpenPnP vs Vendor Software
Buyers comparing desktop pick and place machines ask the same question early: does this machine run its own software, or does it run OpenPnP? The answer usually reads as a maturity score, and it isn't one. Every machine in this class needs a motion control program and a machine profile. OpenPnP supplies the first. Someone at the machine vendor supplies the second, and the second one is where the work sits.
I have reloaded the config on our machine twice now, once after moving it and once after swapping nozzle tips. Both times the interesting part had nothing to do with the engine version.
What "our own software" usually means
On machines with a closed application, the vendor writes the whole stack: the application, the profile, and the firmware on the controller board. The CHMT36VA is a documented example. Its OEM software drives the vacuum pump at 50% through a 16 kHz PWM signal, and an OpenPnP port for that machine needs an example machine.xml plus a firmware flash to reproduce the same behaviour. The OpenPnP wiki entry for it states the tradeoff plainly: OpenPnP "does not reach the same level of performance as the original software, but there are many new features and functions in OpenPnP that are not available in the OEM software."
Nothing about a closed application is automatically worse. What you give up is the ability to retarget it. Converting a machine to OpenPnP is also sometimes one-way: flashing third-party firmware onto that CHMT board means the OEM application is gone for good.
On a machine built for OpenPnP from the start, such as the LumenPnP platform the Vertex 4 is based on, the vendor never writes the engine. Opulo's setup docs put the requirement on the configuration instead: "We highly recommend using the provided configuration files and following this documentation."
What a config file actually holds
In OpenPnP 2.x the configuration lives in a .openpnp2 folder in your user profile (C:\Users\you\.openpnp2 on Windows, ~/.openpnp2 on Linux and macOS), and it is made of machine.xml, parts.xml, packages.xml and vision-settings.xml. The running log is in log, camera snapshots you save by double-clicking the camera view go to snapshots, and every save leaves a copy in backup.
For a Vertex 4 that folder is where the machine is defined. Our downloads page lists four configuration variants: two firmware versions (4.1.0 and 4.0.1) crossed with two nozzle variants. The JUKI variant carries nozzle tip calibration data and the S255 solenoid fix. The stock variant is the uncalibrated default, kept as a reference. Loading the 4.1.0 file onto a board still running 4.0.1 firmware gives you actuator definitions the firmware does not have, so firmware version gets matched first and nozzle variant second.
Two entries from our FAQ show what that difference looks like on a bench. On a stock config the solenoid actuator sends S180, while the firmware wants S255 to open the valve fully, so jobs fail even though the air pump and valves test fine on the debug page. And OpenPnP's default vacuum sensing always reports a failure on a Vertex 4, because the machine ships without a pressure sensor and reads part presence from the bottom camera instead. Set the sensing method to None for each nozzle and the error stops appearing. Both faults look like hardware and both are configuration.
Vision settings sit in the same layer. The default bottom vision pipeline exposes two sliders to the GUI, Threshold (1 to 254, default 100) and Min. Detail Size (up to 0.25 mm², default 0.01), sitting on top of stages that blur with a 9 pixel kernel, mask a 525 pixel circle, key on a hue band of 60 to 130, and filter contours between 0.01 and 900000 mm². A closed application gives you a brightness knob if you are lucky. OpenPnP gives you the pipeline, then exposes the two values you are most likely to need.
Freedom you can point at
Three mechanisms account for most of it, and all three are documented upstream.
Scripting. OpenPnP runs JavaScript (Nashorn), Python (Jython) and BeanShell scripts from the scripts folder in your profile. Anything dropped there appears under the Scripts menu, subfolders become submenus, and an empty .ignore file hides a directory. Scripts get config, machine, gui and scripting objects, so they can move the machine or reset a feeder. A ScriptActuator runs a script as part of a motion sequence, which is how you attach custom hardware to a job without forking the program.
Driver abstraction. OpenPnP converts its commands into whatever the controller speaks through a driver. GcodeDriver and GcodeAsyncDriver cover machines that take G-code, and the community has published setups for Marlin, Grbl, Duet3D and Smoothieware controllers. This is why one machine can mix hardware from different vendors, feeders included, and it is the part we get asked about most often. The three questions to answer are mechanical, electrical and protocol, and the feeder compatibility page works through all three for Photon feeders on a non-Opulo machine.
Running two configurations side by side. java -DconfigDir=<path> -jar ... starts OpenPnP against any profile folder you name, so you can keep a known-good config untouched and test changes against a copy. Hand-editing is possible for the settings that never made it into the GUI, and then the rule from the community docs applies: stop OpenPnP first, or it overwrites your edits when it exits.
What the freedom costs
OpenPnP's own documentation does not pretend this is turnkey. The Issues and Solutions page opens with the admission: "OpenPnP is complex to set up and the more flexibility and optimization is added, the more the complexity grows." The wiki's advice for anyone porting a machine is blunt about the schedule: "Be prepared to have the machine down for a week or more while you get everything configured and become familiar with OpenPnP."
The linear setup path still exists in the wiki as 17 numbered steps, from Before You Start through Driver Setup, Steps Per Mm and Bottom Vision to Next Steps. The same page now says following it is no longer recommended, because Issues and Solutions does the job interactively. It scans your configuration at startup, tracks milestones, and proposes fixes that generate machine-specific G-code and regular expressions, which removed the need to hand-edit machine.xml for common setups. You can accept or dismiss each proposal, and an accepted solution can still be reopened until you press Find Issues & Solutions again.
A vendor configuration narrows that list further. Opulo's calibration documentation splits Issues and Solutions entries into three severities: fundamental steps, suggestions, and error steps, and notes that with their configuration files loaded, some steps appear labelled as errors that should be ignored during calibration. The same page warns that a few calibration steps cannot be undone, and starting over may mean reloading the downloaded config files.
Upgrades and version pinning
OpenPnP shows its version as a date under Help → About. Our install page pins the release we test against, OpenPnP v2.6 (2026-03-01), and the installers are self-hosted on this site so a download link does not rot when a third-party mirror disappears. OpenPnP 2.6 needs Java 11 or newer; a Java 8 runtime throws a startup error that reads like a corrupt install, which is the first thing to check when the window flashes and closes.
The community FAQ has one line worth keeping: after an upgrade, check Issues and Solutions again, because new entries often point at new features rather than at problems. Config backups in the backup folder are the way back if a release disagrees with a profile written for an older one.
Which is the better call
Choose the closed application when you want a machine that switches on and runs, when placement speed straight out of the box matters more than the changes you would make later, and when having a vendor to call has value. Choose OpenPnP when the machine is the thing you are tuning: different feeders, a vision problem specific to your parts, a scripted pre-flight check, or a second machine you want to run on the same profile.
The question worth asking a machine vendor is narrower than "do you ship your own software". Ask which OpenPnP release their configuration was tested against, what the file carries besides the motion profile, and what happens to your calibration when you load a vendor config or upgrade the engine. Those three answers separate a machine that ships a working profile from one that ships a download link. A Vertex 4 arrives with OpenPnP and four config variants, listed with the nozzle variants and firmware versions they match, on the downloads page. The machine is $1,499 with 50 feeder slots, a 0402 lower bound and Marlin firmware on the mainboard; the introduction has the full spec table.