Ein vollständig automatisiertes Filament-Tracking-Ökosystem aufbauen

Eine Druckfarm zu betreiben bedeutet, Verbrauchsmaterialien in großem Maßstab zu verwalten. Filament kommt kiloweise an, wird auf Maschinen geladen, über Dutzende von Aufträgen verbraucht und geht schließlich zur Neige — oft mitten in einem Druck, wenn man nicht aufpasst. Derselbe Bestand dient gleichzeitig zwei Herren: Er versorgt die Drucker als Produktionsverbrauchsmaterial und steht im WooCommerce-Katalog als wiederverkäufliches Produkt zur Verfügung. Eine Spule, die auf eine Maschine geladen wird, ist eine Spule, die nicht mehr für einen Kunden verfügbar ist. Für einen kommerziellen Betrieb ist der Unterschied zwischen dem genauen Wissen, was man hat, und dem Raten der Unterschied zwischen präzisen Angeboten und dem Tragen der Kosten eines fehlgeschlagenen Auftrags — oder dem Überverkauf von Bestand, der bereits auf einem Druckbett liegt.

Dieser Beitrag beschreibt das Ende-zu-Ende-System, das wir bei 3D ETPLUS aufgebaut haben, um Filament vom Kaufbeleg bis zur Druckerdüse und zu WooCommerce-Bestandsniveaus zu verfolgen, unter Verwendung einer Kombination aus Open-Source-Tools, günstiger Hardware, benutzerdefinierten Software-Bridges und — für den ersten Massenimport — einem Sprachmodell, das Rechnungen las und seine eigenen API-Aufrufe schrieb.

Das System hat fünf Schichten, von denen jede ein spezifisches Problem löst:

  1. Spoolman als zentrale Inventardatenbank, erweitert um das Verständnis mehrerer NFC-Tag-Formate
  2. NFC-Lesegeräte an jedem Drucker, die physische Spulen mit dem Software-Inventar verbinden, sobald sie geladen werden
  3. Ein Moonraker-Fork, der den Filamentverbrauch pro Extruder für Mehrkopf-Maschinen verfolgt, ohne Makro-Änderungen zu erfordern
  4. Eine Snapmaker-Bridge, die einen IDEX-Drucker mit proprietärer Firmware in dasselbe Ökosystem wie unsere Klipper-Maschinen bringt
  5. Ein Synchronisierungsskript, das Spoolman-Verbrauchsdaten in Echtzeit-WooCommerce-Bestandsniveaus auf der Produktionswebsite übersetzt

Das Fundament: Spoolman mit NFC-Unterstützung

Spoolman ist ein selbst gehosteter Webdienst zur Verfolgung von Filamentspulen. Standardmäßig integriert es sich in Klipper/Moonraker und OctoPrint, bietet eine REST-API und ermöglicht die Meldung des Filamentverbrauchs während des Drucks. Das Upstream-Projekt ist solide — wir verwenden es als Rückgrat des Systems — aber es kann die NFC-Tags nicht lesen, die Hersteller zunehmend in ihre Filamentverpackungen einbetten.

Unser Spoolman-Fork fügt NFC-Spulenidentifikation sowohl auf Browser- als auch auf Serverebene hinzu, mit Unterstützung für drei Tag-Formate, die den Großteil des Marktes abdecken:

TigerTag (ISO 14443A / NTAG213) ist ein Binärformat, das von Bambu Lab-Filament und einer wachsenden Anzahl von Drittherstellern verwendet wird. Der Tag speichert eine Produktkennung; die eigentlichen Filamentspezifikationen befinden sich in TigerTags externer Datenbank, die der Fork zur Scan-Zeit abfragt, um Materialtyp, Farbe, Durchmesser und Dichte abzurufen. Ein nicht erkannter TigerTag löst die automatische Spulenerstellung aus dem Datenbank-Lookup aus.

OpenPrintTag (ISO 15693 / NFC-V) ist Prusas offener NDEF/CBOR-Standard. Tags tragen spulenspezifische UUIDs und betten die Filamentdaten direkt auf dem Chip ein, wodurch sie ohne externe Suche eigenständig sind.

Qidi (ISO 14443A / MIFARE Classic 1K) deckt Filament von Qidi-Druckern ab. Das Tag-Format kodiert Materialtyp und Farbdaten in Qidis proprietärem Sektorlayout.

Der Fork stellt zwei Scan-Schnittstellen bereit. Der browserbasierte Pfad verwendet die Web NFC API — unterstützt auf Chrome für Android — sodass jeder mit einem kompatiblen Telefon eine Spule antippen und sie in Spoolman erscheinen lassen kann. Der serverseitige Pfad verwendet einen USB-NFC-Leser, der mit dem Spoolman-Host verbunden ist, und ermöglicht das Scannen von einer festen Station. Beide Pfade teilen dieselbe Identifikations- und Auto-Erstellungslogik.


300 kg Inventar mit einem LLM hochfahren

Bevor das NFC-Scanning nützlich war, benötigten wir das vorhandene Inventar in Spoolman. Wir hatten eine einzige große Sammelbestellung von einem Hersteller erhalten — etwa 300 kg Filament, eine Marke, in mehreren Materialien und Farben — und dieser Bestand existierte nur als Positionen auf einer Kaufrechnung, nicht in einer strukturierten Datenbank.

Die manuelle Eingabe hätte Stunden gedauert und wäre fehleranfällig gewesen. Stattdessen haben wir die Rechnungs-PDFs an Claude übergeben und beschrieben, was wir brauchten: für jede Position die Filamentmarke, das Material, die Farbe, den Durchmesser und die Menge identifizieren; das Datenblatt des Herstellers nachschlagen, um Dichte und andere technische Spezifikationen zu ergänzen; dann die entsprechenden Spoolman REST API-Aufrufe zur Erstellung von Spuleneinträgen generieren.

Der Prozess funktionierte besser als erwartet. Das LLM analysierte Rechnungspositionen korrekt, fand Datenblätter auf Herstellerwebsites und produzierte gültige curl-POST-Anfragen, die auf unsere Spoolman-Instanz zielten. Einige Einträge benötigten geringfügige Korrekturen, aber der Großteil des Inventars wurde in einer einzigen Sitzung importiert.

Die praktische Lektion: Ein LLM kombiniert mit einer strukturierten REST-API ist eine leistungsfähige ETL-Pipeline für halbstrukturierte Dokumente. Die Rechnung ist die Quelle, das Datenblatt ist die Anreicherung, die API ist das Ziel, und das LLM übernimmt die Transformation. Kein benutzerdefiniertes Skript erforderlich, kein Zwischenformat zu pflegen.


NFC am Drucker: klipper-nfc-daemon

Eine Spule in Spoolman zu bringen ist nur die halbe Miete. Die andere Hälfte besteht darin, dem Drucker — und Spoolman — mitzuteilen, welche Spule tatsächlich geladen ist. Ohne diese Verbindung haben Klipper und Moonraker keine Möglichkeit zu wissen, welches Spulengewicht beim Filamentverbrauch dekrementiert werden soll.

klipper-nfc-daemon läuft als Dienst auf dem Klipper-Host und übernimmt diese Verbindung automatisch. Unsere Klipper-Maschinen laufen auf Intelligent Agents Recore-Controller-Board, einem zweckgebauten ARM-Board, das die Kombination Raspberry Pi + MCU durch eine einzelne Einheit ersetzt. Die NFC-Hardware ist ein PN532-Lesegerät, das über ein USB-UART-Kabel angeschlossen ist.

Wenn eine Spule geladen wird, tippt der Bediener sie gegen den Leser. Der Daemon liest den Tag, fragt Spoolmans NFC-Endpunkt ab, um den passenden Spulendatensatz zu finden, und verknüpft diese Spule mit dem aktiven Tool in Spoolman. Von diesem Punkt an wird jeder von Klipper gemeldete Extrusionsmillimeter der richtigen Spule zugerechnet.

Für Drucker mit mehreren Extrudern — eine IDEX-Maschine, ein Werkzeugwechsler, ein Multi-Material-System — präsentiert der Daemon einen UI-Dialog, der fragt, in welches Tool die gescannte Spule geladen wird. Der Bediener wählt das Tool, und der Daemon vervollständigt die Verknüpfung für diesen spezifischen Extruder. Diese Interaktion ist minimal: Spule antippen, Tool auswählen wenn aufgefordert, fertig.

Ein Hardware-Hinweis: Der PN532 über USB-UART verarbeitet nur Type-A-Tags (NTAG213/215). OpenPrintTag verwendet NFC-V (Typ V / ISO 15693), was einen anderen Lesegerät-Chipsatz erfordert. Für eine Flotte, die TigerTag- und OpenPrintTag-Filament mischt, übernimmt der serverseitige Browser-Scan-Pfad im Spoolman-Fork NFC-V über ein Telefon, während der PN532 TigerTag am Drucker übernimmt.

Die Kostenökonomie begünstigt NTAG213 stark. Blanke NTAG213-Chips kosten bei 100er-Mengen etwa 0,02 $ pro Stück, was sie auf Flottenebene praktisch kostenlos macht. NFC-V-Tags sind deutlich teurer. Entscheidend ist, dass NTAG213-Tags wiederbeschreibbar sind — dasselbe physische Tag kann gelöscht und einer neuen Spule zugewiesen werden, wenn eine leer ist, was bedeutet, dass der Tag-Pool über die gesamte Lebensdauer der Flotte amortisiert wird, anstatt eine pro Spule zu verbrauchen.


Multi-Tool-Filament-Tracking: Der Moonraker-Fork

Upstream Moonraker behandelt die Spoolman-Integration gut für Einzel-Extruder-Maschinen. Für IDEX- und Multi-Tool-Drucker verfolgt die Upstream-Implementierung nur eine aktive Spule — was eine Annahme im ursprünglichen API-Design widerspiegelt, dass es zu jedem Zeitpunkt nur ein aktives Filament gibt.

Unser Moonraker-Fork erweitert die Spoolman-Integration, um eine Spule pro Tool zu verfolgen, ohne Änderungen an Druckermakros zu erfordern. Der Ansatz ist rein auf API-Ebene.

Die wichtigsten Änderungen:

Spulenspeicherung pro Tool. Anstelle eines einzelnen Datenbankschlüssels spoolman.spool_id speichert der Fork spoolman.spool_id.0, spoolman.spool_id.1 usw. — einen Schlüssel pro Tool. Bestehende Einzel-Extruder-Konfigurationen werden beim ersten Start automatisch migriert.

Tool-bewusste API-Endpunkte. Der HTTP-Endpunkt GET/POST /server/spoolman/spool_id und die entsprechenden WebSocket-RPC-Handler akzeptieren einen optionalen tool-Parameter. Dies entspricht der API-Form, die Mainsails Multi-Extruder-Spoolman-Panel erwartet.

Antwortfeld tool_spool_map. Mainsail verwendet dieses Feld, um vom Einzel-Spulen-Anzeigemodus in den Per-Tool-Anzeigemodus zu wechseln. Ohne es fällt Mainsail auf das Einzel-Spulen-Verhalten zurück, unabhängig von der Backend-Konfiguration.

Das Ergebnis ist, dass eine Klipper-Maschine mit zwei, vier oder mehr Tools genaue Tool-spezifische Spulenzuweisungen in Mainsail anzeigt und der Filamentverbrauch von der richtigen Spule abgebucht wird, während jedes Tool extrudiert. Keine Makros. Keine ACTIVATE_EXTRUDER-Aufrufe im Start-GCode. Das Tracking erfolgt auf der Moonraker-Ebene, unterhalb des GCodes.


Den Snapmaker J1S ins Ökosystem bringen

Nicht alles auf dem Produktionsboden läuft mit Klipper. Unser Snapmaker J1S ist ein IDEX-Drucker mit fähiger Hardware — unabhängige Doppelextrusion, gutes Bauvolumen, zuverlässige Mechanik — aber er läuft auf Snapmakers proprietärer Firmware und spricht ein Binärprotokoll namens SACP. Aus der Perspektive unseres Mainsail-basierten Workflows war er eine Insel.

snapmaker-moonraker ist die Bridge, die wir gebaut haben, um ihn zu verbinden. Die Bridge läuft neben einer Klipper/Moonraker-Instanz und übersetzt zwischen der Moonraker-API, die Mainsail, PrusaSlicer und Spoolman erwarten, und dem SACP-Binärprotokoll, das der J1S tatsächlich spricht.

Die Integration ist tief genug, dass der J1S nun auf der Tooling-Ebene von einer Klipper-Maschine nicht zu unterscheiden ist:

  • Dateien werden von PrusaSlicer direkt in Mainsail hochgeladen, das sie über die Bridge an den Drucker weiterleitet
  • Ein GCode-Nachbearbeiter schreibt Tool-Nummern um, generiert den Snapmaker V1-Metadaten-Header für das Touchscreen-Display, extrahiert Slicer-Thumbnail-Daten und konvertiert sie in das Format des J1S-HMI
  • Drucksteuerung (Start, Pause, Fortsetzen, Abbrechen) erfolgt über native SACP-Befehle und hält das Touchscreen-HMI synchronisiert
  • Temperaturberichterstattung und -steuerung, Lüftersteuerung und Druckfortschritt sind alle über die Moonraker-API verfügbar und in Mainsail sichtbar
  • Spoolman-Integration verfolgt den Filamentverbrauch pro Extruder mit demselben Per-Tool-Spulenmechanismus wie unsere anderen Multi-Extruder-Maschinen
  • IDEX-Kopier- und Spiegelmodus funktionieren: PrusaSlicer signalisiert den Modus über M605, der Nachbearbeiter bettet ihn in den Snapmaker V1-Header ein

Die Bridge wird mit 12 PrusaSlicer-Druckerprofilen geliefert, die alle drei IDEX-Modi über acht Qualitätsvoreinstellungen abdecken.

Das durchgängige Designprinzip war, die gesamte Anpassung in die Bridge zu schieben und das umgebende Ökosystem unverändert zu lassen. Mainsail weiß nicht, dass es mit einem Snapmaker spricht. Spoolman weiß nicht, dass es eine proprietäre Maschine verfolgt. PrusaSlicer verwendet dieselbe Dual-Extruder-Konfiguration wie für jeden anderen IDEX-Drucker. Die Bridge absorbiert die Komplexität, damit nichts anderes es tun muss.

Ein detaillierter technischer Bericht über die Entwicklung der Bridge ist in unserem früheren Blogbeitrag verfügbar.


Den Kreis schließen: Von Spoolman zu WooCommerce

Das letzte Teil verbindet das Inventarsystem mit dem Shop. Derselbe Filamentbestand, der die Drucker speist, ist auch zum Wiederverkauf gelistet — was bedeutet, dass jeder Druckauftrag ein potenzielles Bestandsniveau-Ereignis ist. Die genaue Haltung der gelisteten Mengen ist in beide Richtungen wichtig: Überverkauf bedeutet Rückstände für Bestand, der bereits in einer Düse sitzt, und Unterverkauf bedeutet entgangene Einnahmen für Material, das in einem Regal liegt.

Die Wahrheitsquelle für das Filamentinventar ist Spoolman. Wenn Spulen in der Flotte verwendet werden — konsumiert durch Druckaufträge, die über Klipper, die Snapmaker-Bridge verfolgt oder manuell aufgezeichnet werden — spiegelt Spoolman das aktualisierte Restgewicht auf jeder Spule wider.

Ein Cron-Job, der auf dem Staging-Server läuft, übernimmt die Abstimmung:

  1. Spoolman abfragen für alle Spulendatensätze. Spulen identifizieren, die verwendet wurden — entweder durch das Vorhandensein eines last_used-Zeitstempels oder durch ein Restgewicht unterhalb des ursprünglichen Spulengewichts.

  2. Verfügbaren Bestand berechnen pro Filamentprodukt (Marke, Material, Farbe, Durchmesser), aggregiert über das Restgewicht aller passenden Spulen.

  3. Den Staging-WooCommerce-Shop abfragen, um zu überprüfen, ob seine aktuellen Bestandsniveaus mit den Spoolman-Daten übereinstimmen. Dies erkennt jede Abweichung zwischen den beiden Systemen, bevor zu Production gepusht wird.

  4. In Production pushen. Sobald das Staging-Inventar abgestimmt ist, aktualisiert das Skript die Bestandsniveaus des Produktions-WooCommerce-Shops über die REST-API.

Der Endzustand: Wenn ein Druckauftrag abgeschlossen ist und Spoolman den verbrauchten Filamentanteil aufzeichnet, fließt dieser Verbrauch über den Cron-Job in die für Kunden auf der Website sichtbaren Produktbestandsniveaus. Die Latenz beträgt einen Cron-Zyklus — typischerweise unter einer Stunde.


Das System als Ganzes

Jedes Teil wurde gebaut, um ein spezifisches Problem zu lösen, aber sie bilden zusammen etwas Größeres als ihre Teile:

Eine neue Spule kommt an. Das Rechnungs-PDF geht an das LLM, das den Spoolman-Eintrag erstellt. Die Spule erhält einen NFC-Tag, falls sie noch keinen hat.

Die Spule wird auf einen Drucker geladen. Der Bediener tippt sie gegen den PN532-Leser. Der Daemon verknüpft die physische Spule mit dem richtigen Tool in Spoolman. Wenn es eine Multi-Extruder-Maschine ist, wählen sie welches Tool. Die gesamte Interaktion dauert fünf Sekunden.

Ein Auftrag läuft. Klipper (oder die Snapmaker-Bridge) meldet die Extrusion in Echtzeit. Moonraker belastet die richtige Spule. Wenn es ein Dual-Extruder-Auftrag ist, werden beide Spulen unabhängig voneinander verfolgt.

Der Auftrag ist abgeschlossen. Spoolman hat aktualisierte Restgewichte. Innerhalb einer Stunde nimmt der Cron-Job die Änderung auf, überprüft gegen das Staging und aktualisiert den WooCommerce-Produktbestand.

Keine Tabellenkalkulationen. Keine manuellen Bestandszählungen. Keine Abstimmung am Tagesende. Der Inventarstatus ist kontinuierlich und präzise, weil jedes Verbrauchsereignis am Punkt seines Auftretens erfasst wird.


Was Offen ist, Was Nicht

Alle vier Softwarekomponenten sind Open Source:

Das WooCommerce-Synchronisierungsskript ist spezifisch für unser Shop-Setup und wird derzeit nicht veröffentlicht, aber der Ansatz — Spoolman REST API ein, WooCommerce REST API aus, mit einem Staging-Verifikationsschritt — ist einfach zu replizieren.

Die Hardwarekosten für eine einzelne Druckerintegration liegen unter 10 $ für den PN532-Leser und das USB-UART-Kabel. Der Software-Stack läuft auf demselben Recore-Board, das Klipper betreibt, sodass kein zusätzlicher Rechenaufwand zu provisionieren ist.

Dies wurde mit wesentlicher Unterstützung von Claude (Anthropic) erstellt. Das LLM war auf jeder Ebene beteiligt: Schreiben der ersten Protokollimplementierungen, Debuggen der Binäranalyse, Generieren der Spulen-Import-Curl-Aufrufe aus Rechnungs-PDFs und Verfassen der Beiträge, die es beschreiben. Die KI-Offenlegung im snapmaker-moonraker-Repository gilt für dieses gesamte Ökosystem.

Folgen
Newest Art:
SHOPPING BAG 0
RECENTLY VIEWED 0