<link href="https://fonts.googleapis.com/css?family=Roboto:light,regular,medium,thin,italic,mediumitalic,bold&display=swap" rel="stylesheet" /> <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet" />

Documentation

printlog-bridge


printlog-bridge is a small open-source program that watches your Klipper printers through Moonraker and logs every print to 3D Print Log by itself. You don't type anything in, and you don't have to edit the printer's configuration by hand.

It runs either on the printer's own host or in a Docker container on another computer on your network, and one bridge can watch several printers. The source is on GitHub under the MIT license: HoffmanEngineering/printlog-bridge. For a short overview to share, see Automatic print logging for Klipper.

Note:

The bridge is new

If something doesn't work the way this page says, troubleshooting explains how to send a report.

In this guide


What it logs

When a print starts, a new print appears on your Print List with the status Printing. Its title comes from the file name, and it carries the slicer's estimated print time and filament when the file has them. The largest thumbnail the slicer embedded in the file (OrcaSlicer, PrusaSlicer, Cura and SuperSlicer all embed one) becomes its picture. Shortly after, the print gets the slicer and its version, and the slicer settings it was sliced with in its notes.

When the print ends, the bridge records the outcome, the print time and the filament Klipper actually fed, and adds one frame from the printer's webcam. For a failed print, that frame becomes the picture shown.

Moonraker ends the job asThe print becomesNote added to the print
completedSuccess
cancelledCancelled
errorFailed"Klipper error", with Klipper's message when the bridge saw it
klippy_shutdownFailed"Klipper shutdown"
klippy_disconnectFailed"Lost connection to Klipper"
interrupted, server_exitFailed"Moonraker stopped during the print"

Each tool's filament is linked to a spool. The bridge links each tool's usage to the material loaded in that tool's slot in 3D Print Log, so your inventory stays current. You can load spools in the app, or assign them from the printer's console with the spool macros.

What you change in the app while it prints is kept: the title, your notes (the bridge adds its note after them), the spool on a usage row, and a status you already chose, such as Partial Success. A print you delete stays deleted.

Nothing is lost while 3D Print Log is out of reach. The bridge writes each event to an outbox on disk before sending it, and sends it once the connection is back, oldest first, even if the bridge was restarted in between. When the bridge itself was stopped, it catches up on jobs that started or ended while it was away. On its very first run it picks up a print that is already running, but not older history.

Slicer settings

Each print records the settings it was sliced with, as the Slic3r uploader and the Cura plugin do. Once a print starts, the bridge sends the settings the slicer wrote into the file, along with the summary Moonraker read from it (slicer, layer heights, nozzle, filament name and type, first layer temperatures). In 3D Print Log:

  • the print's Slicer and slicer version are filled in;
  • a Slicer settings section is added to the end of its notes, between --- Slicer settings (…) --- and --- End of slicer settings ---. If the settings are sent again, that section is replaced, not added twice, and the notes you wrote are kept.

It is on by default. To turn it off, set slicer_settings = false in [bridge] for every printer, or in a printer's section for just that one; the bridge then never reads the G-code file.

Good to know:

  • Only the settings are read, never the toolpaths, and the file is never uploaded. Hosts, API keys, passwords and other credentials are blanked before anything leaves the printer. Privacy and security lists exactly what is read and sent.
  • OrcaSlicer, PrusaSlicer, Anycubic Slicer Next and their forks write the full settings block the bridge reads. Bambu Studio and FLSun Slicer put their settings near the top of the file, so for their prints only Moonraker's summary is recorded today.
  • The uploader's and the plugin's settings win. When the bridge logs a job to a print you already made with the Slic3r uploader or the Cura plugin, that print keeps the richer settings they recorded, and the bridge doesn't send its own.

Printers with more than one tool

On a toolchanger, an IDEX printer or a Snapmaker U1, each tool gets its own usage row, numbered from 0 the way Klipper numbers its extruders (extruder is T0, extruder1 is T1). The bridge follows which extruder is active while Klipper's filament count grows, so the rows add up to the job's total. When the slicer listed a weight per filament (PrusaSlicer, OrcaSlicer, Snapmaker Orca), the print starts with an estimate on each tool's row.

With Spoolman

If the printer's [spoolman] section points at 3D Print Log (the block from Connect Spoolman), the bridge keeps Moonraker's active spool and the spools in 3D Print Log's slots in sync both ways. A spool picked on the printer is loaded into the active tool's slot. A spool loaded in the app, with PRINTLOG_SET_SPOOL or by the U1's RFID reader becomes Moonraker's active spool when that tool is active. The bridge also sets the active spool on each tool change. If [spoolman] points at another server, the bridge leaves it alone. While the bridge runs for a printer, the block's notifier is ignored, so prints aren't logged twice.

Not covered yet:

  • A multi-material unit feeding one extruder (ERCF, Happy Hare, AFC). Everything is counted on T0.
  • IDEX copy or mirror mode, where Klipper counts what two heads print only once.

Local mode and remote mode

The bridge talks to Moonraker, so it can run anywhere Moonraker can be reached.

Local modeRemote mode
Runs onThe printer's own host (MainsailOS, FluiddPi, any Klipper install with Moonraker)Any computer on your network: a NAS, a home server, a Raspberry Pi
Talks to Moonraker overIts local socketIts WebSocket, at the printer's address
Installed withinstall.sh, as a systemd serviceThe Docker image
UpdatesFrom the update panel in Mainsail or FluiddBy pulling the image again
Spool macrosInstalled for youCopied to the printer by hand, where the printer allows it
Best forPrinters you can install software onPrinters you can't, such as the Snapmaker U1, and watching several printers from one place

Moonraker accepts one bridge per printer, so pick one mode for each printer. A second bridge waits until the first one stops.


Requirements

  • A printer running Klipper and Moonraker, with Moonraker's job history ([history] in moonraker.conf). Most installs have it already, and the bridge tells you when it's missing.
  • A 3D Print Log account, with the printer added on the Printers page.
  • A personal API key for the bridge to sign in with.
  • Local mode: Python 3.9 or newer on the printer's host (Raspberry Pi OS Bullseye or later), and a user that can use sudo to install the service.
  • Remote mode: Docker on a computer that is always on. The image is built for linux/amd64, linux/arm64 and linux/arm/v7.

Signing in

The bridge signs in with a personal API key, which you create on the Personal API Keys page and store on the computer the bridge runs on. Each install page has a Connect to your account section with the steps. One-step pairing, where you confirm the printer in 3D Print Log instead of copying a key, is planned.

Already using the Moonraker notifier?

If the printer still sends prints through the Moonraker notifier, 3D Print Log logs each print only once, from the bridge, and shows a banner suggesting you remove the notifier. Switch from the notifier has the steps and the exact rule.


Once it runs

Once the bridge runs, the printer's Edit Page lists it under Connections as printlog-bridge (voron), with the name you gave the printer in the bridge's config. It checks in every 5 minutes, and the app shows it as Stale after 15 minutes without hearing from it.

Update

The bridge tells you when a newer version is out. 3D Print Log answers each check-in with the latest version, so the bridge asks nobody else. When yours is older:

  • the printer's Connections say printlog-bridge 0.2.0 is available (with the new version);
  • the bridge writes printlog-bridge 0.2.0 is available (this is 0.1.0) in its log, once for each new version;
  • printlog-bridge status shows an Update: line, and printlog-bridge doctor a warning.

To update:

  • In Docker: in the folder with docker-compose.yml, run docker compose pull, then docker compose up -d. Your config and everything in /data stay as they are. See Run it in Docker.
  • On the printer: update printlog-bridge in the update panel of Mainsail or Fluidd, next to Klipper and Moonraker. See Install it on the printer.

To stop the notice in the bridge's log, status and doctor, set update_check = false in [bridge]. The bridge sends the same check-in either way.