Printrun: pronterface, pronsole and printcore for G-code printers

What Printrun replaces in a 3D printing workflow

Slicers turn a model into G-code. Something still has to push that G-code down a serial line, wait for the firmware's ok, and let a human pause, jog an axis or send a raw M-command when a first layer looks wrong. That middle layer is what Printrun occupies. The repository describes it as a suite of hosts for 3D printers and other CNC machines, made of three programs: printcore.py as a library for writing RepRap hosts, pronsole.py as an interactive command-line host with tab completion, and pronterface.py as a graphical host with the same functionality as pronsole. The audience is narrow and specific. It is for people who own or maintain a machine that accepts G-code over a serial port, and who would rather type a command or import a module than click through a wizard. It is not a slicer, and the README never presents it as one; the plater scripts are the only part that touches model files.

The three-layer architecture: printcore, pronsole, pronterface

The layering is the design decision that matters. printcore.py holds the serial connection, the send queue and the G-code/M-code send and receive logic, and the README states it is a library that makes writing RepRap hosts easy. pronsole.py and pronterface.py both sit on top of it and, per the README, pronterface has the same functionality as pronsole. That means the GUI is not a separate code path with its own behaviour; it is a front end over the same command set. For anyone automating a machine, this is the useful part: you can write a Python script that imports printcore and speaks to the printer directly, skipping both the CLI and the GUI. The cost is that printcore is a library, not a service, so process supervision, logging and retry logic are yours to build. The README also documents an RPC Server, which is the supported way to expose host control to another process rather than reimplementing the serial protocol.

Installing Printrun and sending your first G-code

There are three install routes: pre-compiled binaries from the GitHub releases page for Windows and macOS, distribution packages for Linux, and the Printrun package on PyPI. On Debian-derived systems the README gives a single command for the full suite.

sudo apt install printrun

Fedora uses the equivalent dnf command, and the README notes that adding --enablerepo updates-testing to dnf might sometimes give newer packages, with the caveat that those are also not very tested. If you prefer the Python package, install it inside a virtual environment. The README shows the Linux and macOS form with python -m pip install Printrun and the Windows form with py -m pip install Printrun. Once pronsole is on your PATH, start it and connect to the printer's serial device.

pronsole

Inside pronsole, the host is driven by commands; the README documents host commands and macros as separate sections, so check those before assuming a command name. The same functionality is available graphically by launching pronterface. Two platform notes from the README are worth reading before you file a bug. On macOS and on Windows, the operating system blocks the application because it is not from a verified developer, and the README links to wiki articles explaining how to allow it to start. You only need to do that once per new version.

Running from source, and the wxPython wheel problem

The README is explicit that running from source gives you the latest features and in-development changes, and warns they might not be fully working or stable. The documented sequence is to clone the repository, create a virtual environment, activate it, then install with python -m pip install . from the repository root.

git clone https://github.com/kliment/Printrun.git
cd Printrun
python -m venv venv
source venv/bin/activate
python -m pip install .

The friction is in the dependencies. requirements.txt pins wxPython >= 4.2.0 alongside pyserial (>= 3.0), numpy (>= 1.8.2), pyglet >= 1.1, < 2.0, psutil (>= 2.1), lxml (>= 2.9.1), platformdirs and puremagic, with platform markers for dbus-python on Linux, pyobjc-framework-Cocoa on macOS, and pillow plus pyreadline3 on Windows. The README states that wxPython4 does not have Linux wheels on the Python Package Index, and that skipping the wheel means compiling wxPython4 from source, which it calls time and resource consuming and which might fail. So on Linux the binary package route is usually the shorter path, and source installs are for people who need unreleased changes and can afford the build. The pyglet pin below 2.0 is another constraint to check if your environment already has a newer pyglet.

Where Printrun is the wrong tool

Printrun assumes a serial-attached machine that speaks G-code. If your printer is driven through a vendor cloud service, a proprietary network protocol, or a slicer that insists on owning the connection, this suite has nothing to offer. The README does not document rollback, print recovery after a host crash, or resuming an interrupted job, so a shop that needs job-level audit and restart should not treat Printrun as the layer that provides it. There is also no bundled slicing step; you bring G-code. And the configuration story is file-based. The repository ships dot.pronsolerc.example as the sample configuration, and the README has a Configuration section, but the example file is what you copy and edit. Anyone expecting a settings dialog that covers every firmware quirk will be disappointed. Finally, the maintenance picture is mixed in a way worth stating plainly: the last push to the default branch was on 2026-09-10, so the repository is not dormant, but the most recent tagged release listed is printrun-2.2.0 from 2024-10-20. If you need a released artifact rather than master, you are on a release that is roughly two years behind the branch.

Printrun compared with a full print-management application

The obvious alternative is a slicer-plus-host application that bundles model import, slicing profiles, and printer control in one program. The difference is architectural rather than cosmetic. A bundled application owns the whole pipeline and typically keeps its host logic internal, so extending it means working around the application. Printrun exposes the host layer as printcore.py, a library the README describes as the basis for writing RepRap hosts, and it keeps the CLI and GUI at parity over that library. That makes Printrun the better choice when the printer control needs to be embedded in something else, or when you want to send raw commands and watch the responses. It is the worse choice when you want one installer that slices and prints, because Printrun does not slice and its Windows and macOS binaries require a manual security exception on first run. If you are choosing between them, the question to ask is whether the host layer is a product you want to configure or a library you want to call.

Licence and the cost of staying current

Printrun is GPL-3.0. The COPYING file is the licence text, and pyproject.toml declares the project licence by referencing that file. The practical implication for most users is nil: running the software to drive your own printer is not distribution. It matters if you embed printcore.py in a product you ship, because the GPL's terms attach to derivative works, and the README's own framing of printcore as a library for writing hosts invites exactly that use. That is a question for your own counsel, not for this article. On upgrade cost, the release cadence visible in the repository is slow: printrun-2.0.1 in May 2023, printrun-2.1.0 in May 2024, printrun-2.2.0 in October 2024, with the branch receiving commits as recently as 2026-09-10. The upgrade path itself is ordinary Python packaging, pip install Printrun or your distribution's package manager, and the changelog is NEWS.md. The cost is not in the upgrade mechanics; it is in the gap between what master contains and what the last tag contains.

Editorial conclusion

Adopt Printrun if you drive RepRap-style machines over serial and want the host layer to be readable Python you can script against, for example through printcore or the RPC server. Do not adopt it if you expect a slicer, a managed print farm, or a vendor-supported binary with a signed installer; the README itself tells macOS and Windows users they must manually allow the application to run. Before committing, verify that your printer's firmware speaks the G-code and M-code dialect your macros assume, and check whether the wxPython wheel for your distribution is available, because the README notes Linux wheels are not on the Python Package Index and building from source is time and resource consuming.

Frequently asked questions

Official sources

1. Issues
2. kliment/Printrun on GitHub
3. License: GPL-3.0
4. README
5. Releases