Costruire un Ecosistema di Tracciamento del Filamento Completamente Automatizzato

By 11 min read

Gestire una farm di stampa significa gestire i consumabili su larga scala. Il filamento arriva al chilogrammo, viene caricato sulle macchine, consumato da decine di lavori e alla fine si esaurisce — spesso nel mezzo di una stampa se non si presta attenzione. Lo stesso stock serve contemporaneamente due padroni: alimenta le stampanti come consumabile di produzione e figura nel catalogo WooCommerce come prodotto disponibile per la rivendita. Una bobina caricata su una macchina è una bobina non più disponibile per un cliente. Per un’operazione commerciale, la differenza tra sapere esattamente cosa si ha e dover indovinare è la differenza tra quotare con precisione e accollarsi il costo di un lavoro fallito — o vendere in eccesso stock che è già su un piano di stampa.

Questo post descrive il sistema end-to-end che abbiamo costruito presso 3D ETPLUS per tracciare il filamento dalla fattura d’acquisto all’ugello della stampante ai livelli di stock WooCommerce, usando una combinazione di strumenti open source, hardware economico, software bridge personalizzati e — per l’importazione iniziale in blocco — un modello linguistico che leggeva le fatture e scriveva le proprie chiamate API.

Il sistema ha cinque livelli, ognuno dei quali risolve un problema distinto:

  1. Spoolman come database di inventario centrale, esteso per comprendere più formati di tag NFC
  2. Lettori NFC su ogni stampante che collegano le bobine fisiche all’inventario software nel momento in cui vengono caricate
  3. Un fork di Moonraker che traccia il consumo di filamento per estrusore per macchine multi-utensile senza richiedere modifiche alle macro
  4. Un bridge Snapmaker che porta una stampante IDEX con firmware proprietario nello stesso ecosistema delle nostre macchine Klipper
  5. Uno script di sincronizzazione che traduce i dati di consumo di Spoolman in livelli di stock WooCommerce in tempo reale sul sito di produzione

La Fondazione: Spoolman con Supporto NFC

Spoolman è un servizio web self-hosted per il tracciamento delle bobine di filamento. Di default si integra con Klipper/Moonraker e OctoPrint, fornisce un’API REST e permette di segnalare il consumo di filamento durante le stampe. Il progetto upstream è solido — lo usiamo come colonna vertebrale del sistema — ma non sa leggere i tag NFC che i produttori incorporano sempre più frequentemente nelle confezioni.

Il nostro fork di Spoolman aggiunge l’identificazione delle bobine tramite NFC sia a livello di browser che di server, con supporto per tre formati di tag che coprono la maggior parte del mercato:

TigerTag (ISO 14443A / NTAG213) è un formato binario usato dal filamento Bambu Lab e da un numero crescente di produttori terzi. Il tag memorizza un identificatore prodotto; le specifiche effettive del filamento si trovano nel database esterno di TigerTag, che il fork interroga al momento della scansione per recuperare tipo di materiale, colore, diametro e densità. Un TigerTag non riconosciuto attiva la creazione automatica della bobina dalla ricerca nel database — scansionare una nuova bobina la fa apparire in Spoolman senza alcuna immissione manuale.

OpenPrintTag (ISO 15693 / NFC-V) è lo standard aperto NDEF/CBOR di Prusa. I tag portano UUID per bobina e incorporano i dati del filamento direttamente sul chip, rendendoli autonomi senza richiedere una ricerca esterna.

Qidi (ISO 14443A / MIFARE Classic 1K) copre il filamento delle stampanti Qidi. Il formato del tag codifica tipo di materiale e dati colore nel layout di settori proprietario di Qidi.

Il fork espone due interfacce di scansione. Il percorso basato su browser usa la Web NFC API — supportata su Chrome per Android — così chiunque abbia un telefono compatibile può toccare una bobina e farla apparire in Spoolman. Il percorso lato server usa un lettore NFC USB collegato all’host Spoolman, abilitando la scansione da una stazione fissa. Entrambi i percorsi condividono la stessa logica di identificazione e creazione automatica.

Avviare 300 kg di Inventario con un LLM

Prima che la scansione NFC fosse utile, avevamo bisogno dell’inventario esistente in Spoolman. Avevamo ricevuto un singolo grande ordine all’ingrosso da un produttore — circa 300 kg di filamento, un unico marchio, in più materiali e colori — e quello stock esisteva solo come righe su una fattura d’acquisto, non in alcun database strutturato.

Inserirlo manualmente avrebbe richiesto ore ed era soggetto a errori. Invece, abbiamo fornito i PDF delle fatture a Claude e descritto cosa ci serviva: per ogni riga, identificare il marchio del filamento, il materiale, il colore, il diametro e la quantità; cercare la scheda tecnica del produttore per completare densità e altre specifiche tecniche; poi generare le appropriate chiamate API REST di Spoolman per creare le voci delle bobine.

Il processo ha funzionato meglio del previsto. Il LLM ha analizzato correttamente le righe della fattura, trovato le schede tecniche sui siti web dei produttori e prodotto richieste curl POST valide puntando alla nostra istanza di Spoolman. Alcune voci hanno necessitato correzioni minori, ma la maggior parte dell’inventario è stato importato in una singola sessione.

La lezione pratica: un LLM combinato con un’API REST strutturata è una pipeline ETL capace per documenti semi-strutturati. La fattura è la fonte, la scheda tecnica è l’arricchimento, l’API è il target, e il LLM gestisce la trasformazione. Nessuno script personalizzato necessario, nessun formato intermedio da mantenere.

NFC alla Stampante: klipper-nfc-daemon

Far entrare una bobina in Spoolman è solo metà del problema. L’altra metà è dire alla stampante — e a Spoolman — quale bobina è effettivamente caricata. Senza questo collegamento, Klipper e Moonraker non hanno modo di sapere quale peso di bobina decrementare quando il filamento viene consumato.

klipper-nfc-daemon gira come servizio sull’host Klipper e gestisce questo collegamento automaticamente. Le nostre macchine Klipper girano sulla scheda controller Recore di Intelligent Agent, una scheda ARM dedicata che sostituisce la combinazione Raspberry Pi + MCU con un’unica unità. L’hardware NFC è un lettore PN532 collegato tramite cavo USB-UART.

Quando una bobina viene caricata, l’operatore la avvicina al lettore. Il daemon legge il tag, interroga l’endpoint NFC di Spoolman per trovare il record bobina corrispondente e collega quella bobina all’utensile attivo in Spoolman. Da quel momento, ogni millimetro di estrusione segnalato da Klipper viene attribuito alla bobina corretta.

Per le stampanti con più estrusori — una macchina IDEX, un cambio utensile, un sistema multi-materiale — il daemon presenta un dialogo UI che chiede in quale utensile viene caricata la bobina scansionata. L’operatore seleziona l’utensile e il daemon completa il collegamento per quell’estrusore specifico. Questa interazione è minima: toccare la bobina, scegliere l’utensile se richiesto, fatto.

Una nota sull’hardware: il PN532 via USB-UART gestisce solo tag di Tipo A (NTAG213/215). OpenPrintTag usa NFC-V (Tipo V / ISO 15693), che richiede un chipset lettore diverso. Per una flotta che mescola filamenti TigerTag e OpenPrintTag, il percorso di scansione browser lato server nel fork Spoolman gestisce NFC-V tramite telefono, mentre il PN532 gestisce TigerTag alla stampante.

L’economia dei costi favorisce nettamente NTAG213. I chip NTAG213 vergini costano circa 0,02 $ per unità in quantità da 100, rendendoli essenzialmente gratuiti alla scala di una flotta. I tag NFC-V sono significativamente più costosi. Cosa fondamentale, i tag NTAG213 sono riscrivibili — lo stesso tag fisico può essere cancellato e riassegnato a una nuova bobina quando una si esaurisce, il che significa che il pool di tag si ammortizza sull’intera vita della flotta piuttosto che essere consumato una per bobina.

Tracciamento del Filamento Multi-Utensile: Il Fork Moonraker

Il Moonraker upstream gestisce bene l’integrazione Spoolman per macchine a singolo estrusore. Per stampanti IDEX e multi-utensile, l’implementazione upstream traccia solo una bobina attiva — riflettendo un’assunzione nel design originale dell’API che ci sia un solo filamento attivo in qualsiasi momento.

Il nostro fork di Moonraker estende l’integrazione Spoolman per tracciare una bobina per utensile, senza richiedere modifiche alle macro della stampante. L’approccio è puramente a livello API.

I cambiamenti chiave:

Archiviazione bobine per utensile. Invece di una singola chiave database spoolman.spool_id, il fork memorizza spoolman.spool_id.0, spoolman.spool_id.1, ecc. — una chiave per utensile. Le configurazioni a singolo estrusore esistenti migrano automaticamente al primo avvio.

Endpoint API consapevoli degli utensili. L’endpoint HTTP GET/POST /server/spoolman/spool_id e i corrispondenti handler WebSocket RPC accettano un parametro opzionale tool. Questo corrisponde alla forma API che il pannello Spoolman multi-estrusore di Mainsail si aspetta.

Campo risposta tool_spool_map. Mainsail usa questo campo per passare dalla modalità visualizzazione singola bobina alla modalità visualizzazione per utensile. Senza di esso, Mainsail torna al comportamento singola bobina indipendentemente dalla configurazione del backend.

Il risultato è che una macchina Klipper con due, quattro o più utensili mostra accurate assegnazioni bobina per utensile in Mainsail, e il consumo di filamento viene addebitato alla bobina corretta mentre ogni utensile estrude. Nessuna macro. Nessuna chiamata ACTIVATE_EXTRUDER nel GCode di avvio. Il tracciamento avviene al livello Moonraker, al di sotto del GCode.

Portare lo Snapmaker J1S nell’Ecosistema

Non tutto sul piano lavora con Klipper. Il nostro Snapmaker J1S è una stampante IDEX con hardware capace — doppia estrusione indipendente, un volume di costruzione decente, meccanica affidabile — ma gira sul firmware proprietario di Snapmaker e parla un protocollo binario chiamato SACP. Dal punto di vista del nostro workflow basato su Mainsail, era un’isola.

snapmaker-moonraker è il bridge che abbiamo costruito per collegarlo. Il bridge gira accanto a un’istanza Klipper/Moonraker e traduce tra l’API Moonraker che Mainsail, PrusaSlicer e Spoolman si aspettano e il protocollo binario SACP che il J1S effettivamente parla.

L’integrazione è abbastanza profonda da rendere il J1S ora indistinguibile da una macchina Klipper a livello di strumenti:

  • I file vengono caricati da PrusaSlicer direttamente in Mainsail, che li inoltra attraverso il bridge alla stampante
  • Un post-processore GCode riscrive i numeri utensile, genera l’header di metadati Snapmaker V1 richiesto dal touchscreen, estrae i dati delle miniature dello slicer e li converte nel formato che l’HMI del J1S mostra
  • Il controllo di stampa (avvio, pausa, ripresa, annullamento) avviene tramite comandi SACP nativi, mantenendo sincronizzato l’HMI del touchscreen
  • Reporting e controllo temperatura, controllo ventola e avanzamento stampa sono tutti esposti tramite l’API Moonraker e visibili in Mainsail
  • L’integrazione Spoolman traccia il consumo di filamento per estrusore, usando lo stesso meccanismo bobina per utensile delle nostre altre macchine multi-estrusore
  • I modi IDEX Copia e Specchio funzionano: PrusaSlicer segnala il modo tramite M605, il post-processore lo incorpora nell’header Snapmaker V1

Il bridge viene fornito con 12 profili stampante PrusaSlicer che coprono tutti e tre i modi IDEX su otto preset di qualità.

Il principio di design per tutto è stato di spingere tutta l’adattazione nel bridge e lasciare invariato l’ecosistema circostante. Mainsail non sa che sta parlando con uno Snapmaker. Spoolman non sa che sta tracciando una macchina proprietaria. PrusaSlicer usa la stessa configurazione dual-estrusore che usa per qualsiasi altra stampante IDEX. Il bridge assorbe la complessità in modo che nient’altro debba farlo.

Un resoconto tecnico dettagliato dello sviluppo del bridge è disponibile nel nostro post precedente.

Chiudere il Cerchio: Da Spoolman a WooCommerce

L’ultimo pezzo collega il sistema di inventario al negozio. Lo stesso stock di filamento che alimenta le stampanti è anche elencato per la rivendita — il che significa che ogni lavoro di stampa è un potenziale evento di livello stock. Mantenere accurate le quantità elencate è importante in entrambe le direzioni: la sovrapprovvigionamento significa ordini arretrati per stock che è già in un ugello, e la sottoprovvigionamento significa ricavi persi su materiale che è su uno scaffale.

La fonte di verità per l’inventario filamento è Spoolman. Man mano che le bobine vengono usate nella flotta — consumate da lavori di stampa tracciati tramite Klipper, il bridge Snapmaker, o registrate manualmente — Spoolman riflette il peso residuo aggiornato su ogni bobina.

Un cron job in esecuzione sul server di staging gestisce la riconciliazione:

  1. Interrogare Spoolman per tutti i record delle bobine. Identificare le bobine che sono state utilizzate — sia per la presenza di un timestamp last_used che per un peso residuo inferiore al peso originale della bobina.

  2. Calcolare lo stock disponibile per prodotto filamento (marchio, materiale, colore, diametro), aggregando il peso residuo su tutte le bobine corrispondenti.

  3. Interrogare il negozio WooCommerce di staging per verificare che i livelli di stock attuali corrispondano ai dati di Spoolman. Questo rileva qualsiasi deriva tra i due sistemi prima di fare push in produzione.

  4. Push in produzione. Una volta riconciliato l’inventario di staging, lo script aggiorna i livelli di stock del negozio WooCommerce di produzione tramite l’API REST.

Lo stato finale: quando un lavoro di stampa finisce e Spoolman registra il filamento consumato, quel consumo scorre attraverso il cron job nei livelli di stock dei prodotti visibili ai clienti sul sito. La latenza è un ciclo di cron — tipicamente meno di un’ora.

Il Sistema nel suo Insieme

Ogni pezzo è stato costruito per risolvere un problema specifico, ma si compongono in qualcosa di più grande delle loro parti:

Una nuova bobina arriva. Il PDF della fattura va al LLM, che crea la voce Spoolman. La bobina riceve un tag NFC se non ne ha già uno.

La bobina viene caricata su una stampante. L’operatore la avvicina al lettore PN532. Il daemon collega la bobina fisica all’utensile corretto in Spoolman. Se è una macchina multi-estrusore, seleziona quale utensile. L’intera interazione richiede cinque secondi.

Un lavoro gira. Klipper (o il bridge Snapmaker) segnala l’estrusione in tempo reale. Moonraker addebita la bobina corretta. Se è un lavoro dual-estrusore, entrambe le bobine vengono tracciate indipendentemente.

Il lavoro finisce. Spoolman ha pesi residui aggiornati. Entro l’ora, il cron job rileva la modifica, verifica contro lo staging e aggiorna lo stock prodotto WooCommerce.

Niente fogli di calcolo. Niente conteggi manuali dello stock. Niente riconciliazione a fine giornata. Lo stato dell’inventario è continuo e accurato perché ogni evento di consumo viene catturato nel momento in cui si verifica.

Cosa è Aperto, Cosa Non lo è

Tutti e quattro i componenti software sono open source:

Lo script di sincronizzazione WooCommerce è specifico per la nostra configurazione del negozio e non è attualmente pubblicato, ma l’approccio — API REST Spoolman in ingresso, API REST WooCommerce in uscita, con un passaggio di verifica sullo staging — è semplice da replicare.

Il costo hardware per l’integrazione di una singola stampante è inferiore a 10 $ per il lettore PN532 e il cavo USB-UART. Lo stack software gira sulla stessa scheda Recore che fa girare Klipper, quindi non c’è capacità di calcolo aggiuntiva da provisionare.

Questo è stato costruito con l’assistenza sostanziale di Claude (Anthropic). Il LLM è stato coinvolto ad ogni livello: scrivere le implementazioni iniziali dei protocolli, debuggare il parsing binario, generare le chiamate curl di importazione bobine dai PDF delle fatture e scrivere i post che lo descrivono. La dichiarazione di IA nel repository snapmaker-moonraker si applica a questo intero ecosistema.

Segui
InstagramFacebookLinkedin
Newest Art:
SHOPPING BAG 0
RECENTLY VIEWED 0