Codex riporta in vita una da Vinci Nano del 2017 rimasta senza software moderno
L’intelligenza artificiale può allungare la vita delle vecchie stampanti 3D? Una da Vinci Nano del 2017 mostra una strada possibile
Niklas Barning ha utilizzato Codex e il reverse engineering del traffico USB per creare NanoPrint, una nuova app macOS capace di controllare una stampante XYZprinting rimasta senza software moderno
Una stampante 3D acquistata quasi dieci anni fa può essere ancora meccanicamente funzionante e diventare ugualmente inutilizzabile perché il software necessario a controllarla non gira più sui computer moderni. È esattamente il problema incontrato dallo sviluppatore e maker Niklas Barning con una XYZprinting da Vinci Nano, piccola stampante FFF presentata nel 2017 come sistema plug-and-play economico per principianti. L’hardware continuava a funzionare, ma il software XYZprinting necessario per gestirlo non era più adeguatamente utilizzabile sulle versioni moderne di macOS. Barning ha quindi adottato una soluzione che pochi anni fa avrebbe richiesto un lavoro di sviluppo molto più impegnativo: ha osservato il traffico USB prodotto dal vecchio software, ha ricostruito progressivamente alcuni dei comandi utilizzati dalla macchina e, con il supporto di Codex, ha sviluppato NanoPrint, una piccola applicazione nativa per Mac attraverso la quale può eseguire calibrazione, movimenti degli assi, caricamento e scaricamento del filamento, pulizia dell’ugello e altre operazioni di manutenzione. Il caso analizzato da Fabbaloo è interessante perché mostra un possibile nuovo ruolo dell’intelligenza artificiale nella stampa 3D: non generare modelli o ottimizzare parametri, ma contribuire a mantenere utilizzabile hardware che il software commerciale ha abbandonato.
È però importante descrivere correttamente ciò che è accaduto. Barning non ha riscritto il firmware interno della da Vinci Nano e non ha sostituito l’elettronica della stampante. Il firmware originale continua a controllare motori, estrusore, temperatura e logica di basso livello. NanoPrint è un nuovo programma host che gira sul Mac e comunica con quel firmware attraverso USB. La differenza è sostanziale: ricostruire un’applicazione che invia comandi a una macchina già funzionante è generalmente molto più semplice che sostituirne completamente il firmware, soprattutto quando microcontrollore, bootloader, pinout e protocolli interni non sono documentati. L’intelligenza artificiale ha quindi aiutato soprattutto nella scrittura e nell’iterazione del nuovo software, mentre la parte fondamentale di reverse engineering è rimasta basata sull’osservazione del comportamento reale della macchina, sul traffico USB e su numerosi tentativi sperimentali.
La da Vinci Nano nasceva proprio come stampante dipendente dal software del produttore
Quando XYZprinting presentò la da Vinci Nano al CES 2017, uno dei principali argomenti commerciali era la semplicità. La macchina costava circa 230 dollari, offriva un volume di costruzione di circa 120 × 120 × 120 mm, calibrazione automatica e un funzionamento fortemente integrato con il software dell’azienda. Il manuale ufficiale indicava XYZmaker Suite come strumento necessario per preparare i modelli e controllare la macchina e specificava addirittura che la prima installazione richiedeva una connessione Internet. Per il pubblico consumer dell’epoca era un vantaggio: invece di configurare manualmente firmware, profili e comunicazione seriale, l’utente installava il programma fornito dall’OEM e utilizzava un ambiente predisposto. Lo stesso livello di integrazione diventa però uno svantaggio quando il produttore esce dal mercato. XYZprinting ha confermato ufficialmente che nel 2023 ha cessato lo sviluppo e le vendite globali della propria attività di stampa 3D, organizzando periodi transitori di assistenza differenti a seconda delle regioni. In Europa l’assistenza aftermarket ufficialmente prevista attraverso Fabistron arrivava al 30 giugno 2025, mentre in Giappone alcune attività continuano fino alla fine del 2026 e per determinati prodotti sono state prospettate riparazioni limitate fino al 2028 in funzione della disponibilità dei ricambi. Nel 2023 Nexa3D aveva inoltre acquisito la parte SLS di XYZprinting, ma la gamma desktop da Vinci non è confluita in una nuova piattaforma consumer equivalente.
Il risultato è un caso quasi da manuale di obsolescenza software. La da Vinci Nano non ha improvvisamente perso precisione meccanica perché è arrivato il 2026. La sua elettronica non ha necessariamente smesso di funzionare. Semplicemente il ponte software fra computer e stampante è rimasto congelato mentre i sistemi operativi hanno continuato a evolvere. Copie dei vecchi programmi sono ancora conservate da alcuni distributori: gli archivi Fabistron e Comprise, per esempio, ospitano versioni di XYZmaker Suite e XYZprint, ma le versioni macOS vengono indicate per sistemi che arrivano sostanzialmente fino a OS X/macOS 10.15, e lo stesso distributore segnala che XYZmaker Suite non è più supportata. Il firmware più recente della da Vinci Nano reperibile negli archivi ufficiali è la versione 1.2.0 pubblicata nel maggio 2022. Conservare installer e firmware può permettere di mantenere operativo un vecchio computer dedicato, ma non risolve la compatibilità con un ambiente informatico che continua ad aggiornarsi.
NanoPrint sostituisce il programma sul computer, non il cervello della stampante
Per capire perché l’esperimento di Barning sia replicabile solo in determinate condizioni conviene separare i differenti strati software di una stampante FFF. Il slicer trasforma la geometria del modello in percorsi utensile. Il programma host può inviare file e comandi alla macchina e offrire funzioni come movimento manuale, homing, cambio filamento e calibrazione. Il firmware, invece, gira direttamente sull’elettronica della stampante e controlla stepper, heater, termistori, endstop e tutte le funzioni che richiedono temporizzazione in tempo reale. NanoPrint interviene essenzialmente sul secondo livello. Il firmware XYZprinting rimane al proprio posto e Barning ha creato una nuova interfaccia che sa comunicare con esso.
È una distinzione che ridimensiona ma contemporaneamente rende più interessante il ruolo dell’AI. Non serve necessariamente ricostruire un intero sistema embedded. Se il firmware continua ad accettare comandi e il protocollo fisico USB è ancora accessibile, può bastare capire quali byte il vecchio software invia quando l’utente preme un determinato pulsante. L’operazione tipica consiste nel registrare il traffico durante un’azione nota, confrontare pacchetti differenti e cercare una relazione fra comandi e comportamento della macchina. Si muove X di dieci millimetri, si osservano i dati. Si cambia la distanza e si verifica cosa cambia nel pacchetto. Si ordina un caricamento filamento e si identifica la sequenza corrispondente. Una volta compreso abbastanza del protocollo, il nuovo programma può replicarlo. Un coding agent può velocizzare enormemente la scrittura del codice USB, la costruzione dell’interfaccia, il parsing dei pacchetti e le numerose modifiche necessarie durante i test, ma non conosce magicamente il protocollo proprietario della stampante se nessuno gli fornisce evidenze da analizzare.
Il “vibe coding” riduce la barriera d’ingresso, ma il reverse engineering rimane un lavoro sperimentale
Fabbaloo utilizza il caso per mostrare l’effetto del cosiddetto vibe coding, cioè una modalità di sviluppo nella quale l’utente descrive in linguaggio naturale ciò che vuole realizzare e un modello AI genera e modifica una parte considerevole del codice. Barning indica esplicitamente Codex fra gli strumenti utilizzati insieme all’analisi USB e a “quite a lot of trial and error”. Quest’ultima parte è forse la più importante. Il progetto non è nato pronunciando una frase come “fammi un driver per la da Vinci Nano”. Il coding agent ha potuto produrre software intorno a informazioni che venivano progressivamente ricostruite e verificate sul dispositivo reale.
Gli agenti moderni di programmazione possono creare funzionalità, effettuare refactoring, leggere codebase, eseguire test e aiutare nello sviluppo di intere applicazioni. Questo rende realisticamente accessibili progetti personali che in passato avrebbero richiesto molte più ore di studio di API, framework grafici, USB e linguaggi di programmazione. Ma sia OpenAI sia altri fornitori di strumenti AI insistono sulla necessità di confinare e verificare le azioni dei coding agent quando interagiscono con sistemi reali. Nel caso di una stampante 3D questo principio assume un significato molto concreto: il programma non controlla semplicemente pixel su uno schermo, ma una macchina dotata di motori, elementi riscaldanti e organi in movimento.
Barning non pubblica liberamente NanoPrint proprio per motivi di sicurezza
Questo dettaglio della storia merita particolare attenzione. NanoPrint non è stato semplicemente caricato su un repository pubblico affinché chiunque possa scaricarlo. Barning spiega che l’applicazione è stata sviluppata con forte assistenza dell’AI e controlla hardware che si muove e diventa caldo; per questo preferisce fornire accesso al repository privato o una copia dell’app soltanto a chi possiede effettivamente la stessa stampante e lo contatta.
La prudenza è tecnicamente sensata. Un errore in un programma di gestione potrebbe comandare un movimento oltre una posizione prevista, estrudere materiale nella fase sbagliata oppure richiedere una temperatura non appropriata. Un firmware ben progettato dovrebbe comunque mantenere protezioni locali, limiti di temperatura e controlli di sicurezza indipendenti dall’applicazione host, ma non è prudente presupporre che una macchina consumer di quasi dieci anni fa gestisca correttamente ogni comando anomalo possibile. GitHub, nelle proprie linee guida sui coding agent, sottolinea espressamente che il codice generato dall’AI può sembrare corretto ma contenere errori semantici o vulnerabilità e deve quindi essere controllato e testato. Nel mondo della stampa 3D al normale code review dovrebbe aggiungersi un test fisico progressivo, iniziando da operazioni a basso rischio e verificando ogni comando prima di consentire al software di controllare automaticamente l’intera macchina.
Non tutte le vecchie stampanti hanno bisogno dell’AI per essere mantenute in vita
Il caso XYZprinting rappresenta una situazione particolarmente interessante perché l’ecosistema era relativamente chiuso. Per molte altre stampanti il problema è molto più semplice. Numerose macchine FFF utilizzano Marlin, firmware open source nato nell’ambiente RepRap e tuttora mantenuto. Marlin supporta un’ampia gamma di elettroniche, dalle vecchie schede AVR a differenti generazioni ARM, STM32, ESP32 e altri microcontrollori. Una macchina basata su hardware documentato e protocollo G-code standard può spesso essere collegata a nuovi slicer e software host senza dover ricostruire un protocollo proprietario.
Esiste inoltre Klipper, che sposta una parte importante dei calcoli su un computer esterno, per esempio un Raspberry Pi, lasciando al microcontrollore della stampante l’esecuzione temporizzata degli impulsi. La documentazione Klipper sottolinea che perfino vecchi microcontrollori 8-bit possono raggiungere elevate frequenze di stepping utilizzando questa architettura. In alcuni casi, quindi, una vecchia stampante può essere modernizzata sostituendo firmware, aggiungendo un piccolo computer e mantenendo gran parte della meccanica originale. Anche OctoPrint ha costruito negli anni un enorme ecosistema intorno alla comunicazione seriale con stampanti G-code.
Il problema nasce quando il produttore introduce protocolli proprietari, file cifrati, autenticazioni, servizi cloud obbligatori o elettroniche completamente non documentate. È proprio in questi casi che reverse engineering e AI possono avere un ruolo molto maggiore.
La famiglia da Vinci era già nota per protocolli meno aperti rispetto alle macchine RepRap
Le discussioni storiche della comunità OctoPrint mostrano che utenti interessati a macchine XYZprinting avevano già incontrato anni fa protocolli non direttamente compatibili con il normale flusso G-code. Nel 2018, per esempio, un utente impegnato a integrare una da Vinci Jr osservava che la macchina utilizzava un protocollo proprietario e cercava un modo per intercettare e trasformare la comunicazione seriale prima di inviarla alla stampante. Il problema non era impossibile da risolvere, ma richiedeva un livello software aggiuntivo fra G-code standard e protocollo del produttore.
Questa è precisamente una delle aree nelle quali gli agenti AI possono ridurre drasticamente il costo personale dell’esperimento. Un maker può fornire campioni di traffico, vecchie documentazioni, frammenti di codice e descrizioni del comportamento e chiedere all’agente di individuare pattern, creare parser, scrivere test e modificare rapidamente il programma. Il processo rimane reverse engineering, ma una parte delle competenze che prima avrebbero richiesto settimane di apprendimento può essere acquisita mentre il progetto procede.
La vera evoluzione sarebbe far stampare la Nano direttamente dai slicer moderni
NanoPrint, nella versione descritta pubblicamente da Barning, serve principalmente per calibrazione, movimento, filamento, pulizia dell’ugello e manutenzione. Non viene presentata come sostituto completo di XYZprint per l’intero workflow dal modello 3D alla stampa. Fabbaloo osserva però che un’estensione naturale sarebbe integrare la macchina con un slicer moderno.
Tecnicamente il problema potrebbe essere separato in due parti. Il primo consiste nel creare un profilo macchina per Cura, PrusaSlicer, OrcaSlicer o un’altra piattaforma capace di generare percorsi compatibili con volume, cinematica, nozzle e materiali della da Vinci Nano. Questa parte è relativamente affrontabile: negli archivi dei distributori XYZprinting esiste perfino una documentazione storica denominata “CURA Setting Parameter – 120mm” per la Nano. Il secondo problema è capire come trasferire quei percorsi alla macchina attraverso il suo protocollo proprietario. Potrebbe essere necessario trasformare il G-code, aggiungere metadata, utilizzare pacchetti USB specifici oppure riprodurre una parte delle funzioni della vecchia suite XYZprinting. È proprio qui che il lavoro di Barning può diventare la base di un vero sostituto moderno del software originale.
Se questo passaggio venisse completato, l’hardware del 2017 potrebbe utilizzare uno slicer sviluppato nel 2026 pur mantenendo il firmware originale. Sarebbe probabilmente la forma più concreta di “software life extension” immaginata da Fabbaloo.
L’AI potrebbe trasformare vecchi installer e traffico USB in documentazione che non è mai esistita
Un secondo beneficio potenziale riguarda la documentazione. Molti dispositivi consumer sono diventati obsoleti non perché i protocolli fossero tecnicamente impossibili da implementare, ma perché erano conosciuti soltanto all’interno dell’azienda che li aveva prodotti. Quando quella società chiude il reparto o elimina i server, la conoscenza rischia di scomparire insieme al software.
Gli LLM sono particolarmente adatti a lavorare con grandi quantità di informazioni eterogenee: manuali, codice, log, output USB, messaggi di errore e osservazioni umane. Possono quindi aiutare a costruire progressivamente una specifica non ufficiale del protocollo, generare test automatici e trasformare un insieme disordinato di osservazioni in documentazione leggibile. Una volta ottenuta una specifica verificata, mantenere l’applicazione diventa molto più semplice rispetto a dover ripetere il reverse engineering ogni volta che cambia il sistema operativo.
Questo può essere uno degli effetti più importanti dell’AI sulla conservazione dell’hardware: non soltanto produrre codice, ma diminuire il costo necessario per ricostruire conoscenza tecnica perduta.
La situazione ricorda il retrogaming, ma con conseguenze fisiche molto diverse
Nel mondo dei computer e delle console esistono da decenni emulatori e progetti community che mantengono utilizzabile hardware o software abbandonato. Le stampanti 3D potrebbero seguire una traiettoria simile: quando il produttore smette di aggiornare l’applicazione, la comunità può creare un client compatibile oppure sostituire completamente firmware ed elettronica.
La differenza è che una stampante è una macchina fisica. Un emulatore che interpreta male un comando può produrre un artefatto grafico o bloccare un gioco; un programma che interpreta male la temperatura o la posizione di un asse può danneggiare hardware. Per questo il livello di verifica necessario è superiore. L’AI abbassa la barriera di ingresso alla programmazione, ma non elimina la necessità di comprendere il sistema fisico che il software sta comandando.
Il rischio potrebbe anzi aumentare se utenti privi di esperienza considerassero il codice generato automaticamente intrinsecamente affidabile. Il fatto che Barning mantenga NanoPrint privato è quindi un esempio utile di comportamento responsabile: l’AI accelera l’esperimento, ma il controllo umano resta necessario.
Per alcune stampanti potrebbe essere più semplice sostituire completamente la scheda elettronica
Esiste inoltre un limite economico al reverse engineering. Se occorrono settimane per comprendere un protocollo proprietario mentre una moderna scheda controller compatibile con Marlin o Klipper costa poche decine di euro, può essere più razionale sostituire l’elettronica e conservare soltanto telaio, motori, hotend e alimentatore. È una strategia praticata da anni dalla comunità maker con macchine aperte e facilmente modificabili.
Una conversione di questo tipo richiede però conoscere cablaggio, tensioni, termistori, endstop e caratteristiche degli stepper e può diventare difficile su macchine progettate con connettori, sensori o componenti proprietari. Inoltre, sostituendo la scheda, la stampante non è più realmente mantenuta nella configurazione originale: diventa una piattaforma meccanica riutilizzata per un nuovo sistema elettronico.
NanoPrint dimostra una soluzione più elegante quando il firmware originale è ancora funzionante: non modificare nulla nella macchina e sostituire soltanto il software che la controlla.
L’hardware rimane comunque il secondo limite alla longevità
L’AI non può risolvere ogni forma di obsolescenza. Una cinghia usurata deve essere sostituita fisicamente. Un hotend danneggiato richiede un ricambio compatibile. Un termistore fuori produzione può costringere a modifiche elettriche o firmware. Guide, ventole, connettori, alimentatori e sensori continuano a invecchiare indipendentemente dal software.
L’uscita di XYZprinting dal mercato mostra bene questo secondo problema. La stessa comunicazione ufficiale del produttore spiegava che anche ricambi, riparazioni e assistenza sarebbero terminati progressivamente nelle diverse regioni. In Giappone il distributore Iguazu continua alcune attività più a lungo, ma precisa che la disponibilità dipende dalle scorte dei componenti. Un’app moderna può quindi rimuovere il blocco software, ma non può creare fisicamente un componente elettronico proprietario che non esiste più.
Paradossalmente la stampa 3D può aiutare almeno per alcuni elementi meccanici: cover, supporti, manopole, guide o adattatori possono essere ridisegnati e ristampati. L’AI potrebbe persino contribuire al reverse engineering del pezzo. Ma componenti critici elettrici e termici richiedono ancora sostituti reali e compatibili.
La vera differenza è tra macchine aperte e macchine dipendenti dal produttore
L’esperienza XYZprinting riporta quindi l’attenzione su una caratteristica che al momento dell’acquisto viene spesso ignorata: quanto del funzionamento della stampante dipende da servizi e software controllati esclusivamente dall’OEM? Una macchina che accetta G-code standard tramite USB, rete o scheda SD può continuare a essere utilizzata anche se il produttore scompare. Una macchina che richiede un’applicazione proprietaria, un account cloud e protocolli non documentati può invece diventare inutilizzabile pur essendo meccanicamente perfetta.
La differenza può sembrare poco importante quando il prodotto è nuovo e l’azienda aggiorna regolarmente il software. Diventa decisiva dopo dieci anni. Nel febbraio 2026, per esempio, Bambu Lab ha annunciato la fine della produzione della P1P accompagnandola da un calendario esplicito: aggiornamenti funzionali e bugfix fino al novembre 2027, patch di sicurezza fino al novembre 2029 e parti e supporto fino al febbraio 2031. È un approccio molto differente dal semplice lasciare progressivamente scomparire il software senza indicare una data di supporto e mostra come la longevità digitale stia diventando un tema sempre più concreto anche nel mercato consumer della stampa 3D.
Le nuove generazioni di stampanti potrebbero essere più vulnerabili, non meno
C’è inoltre un paradosso. Le stampanti moderne sono molto più semplici da utilizzare rispetto a quelle del 2017, ma proprio per questo sono spesso molto più dipendenti dal software. Una macchina recente può includere telecamere, computer Linux, cloud, smartphone app, sistemi di autenticazione, aggiornamenti OTA, AI vision, gestione multi-materiale e servizi remoti. Tutti questi elementi migliorano enormemente l’esperienza durante gli anni di pieno supporto, ma aumentano anche il numero di dipendenze che possono rompersi nel lungo periodo.
Una vecchia Ender-3 quasi interamente meccanica può essere mantenuta operativa sostituendo una scheda. Una stampante smart fortemente integrata potrebbe richiedere invece server, certificati, API e firmware firmati dal produttore. L’affermazione di Fabbaloo secondo cui il problema dell’obsolescenza software potrebbe diventare più importante in futuro è quindi plausibile anche per una ragione differente da quella indicata nell’articolo: non soltanto perché il miglioramento dell’hardware rallenterà, ma perché la quantità di software necessaria per far funzionare l’hardware continua ad aumentare.
L’AI potrebbe diventare una sorta di manutentore software dell’hardware abbandonato
In questo scenario gli agenti di coding possono cambiare l’economia della conservazione. Nessuna società commerciale avrebbe probabilmente interesse a finanziare lo sviluppo di una nuova applicazione macOS per poche centinaia di utenti rimasti con una da Vinci Nano del 2017. Il costo degli sviluppatori supererebbe facilmente il valore economico del mercato. Per un singolo proprietario, però, il calcolo cambia se gran parte della scrittura del codice può essere accelerata da un agente AI.
Questo potrebbe creare una nuova categoria di piccoli progetti di compatibilità: un proprietario ricostruisce il protocollo di una vecchia stampante, un altro sviluppa un driver per uno scanner 3D abbandonato, un terzo crea un convertitore per un formato proprietario ormai inutilizzabile. Non serve necessariamente costruire un prodotto commercialmente sostenibile. Basta che il costo personale dello sviluppo diventi sufficientemente basso.
È forse questa la vera novità mostrata da NanoPrint. L’intelligenza artificiale non rende improvvisamente immortale l’hardware, ma riduce il numero di dispositivi per i quali la frase “nessuno svilupperà mai più quel software” rappresenta necessariamente la fine.
L’esempio della da Vinci Nano non dimostra ancora che chiunque possa farlo
Rimane però un rischio di semplificazione nella conclusione di Fabbaloo secondo cui, se manca il software, in futuro basterà crearlo. Barning possiede comunque competenze tecniche sufficienti per registrare traffico USB, eseguire test, comprendere il comportamento della macchina e valutare il codice prodotto. Un utente completamente inesperto potrebbe descrivere all’AI ciò che vuole ottenere, ma avrebbe molte più difficoltà a capire quando il risultato è sbagliato.
Gli stessi produttori degli strumenti di coding sottolineano che il codice generato deve essere revisionato e testato. La probabilità di errore diventa particolarmente importante quando il programma deve interpretare un protocollo che non è documentato: anche l’AI possiede poche informazioni affidabili dalle quali partire e può facilmente proporre supposizioni plausibili ma false.
L’effetto realistico è quindi soprattutto un moltiplicatore delle capacità dell’utente, non una sostituzione totale delle competenze.
NanoPrint apre però una prospettiva interessante per la sostenibilità della stampa 3D
Una da Vinci Nano del 2017 non compete in velocità e automazione con una moderna stampante consumer. Potrebbe però essere perfettamente adeguata per piccoli oggetti PLA, applicazioni scolastiche o utilizzi occasionali. Sostituirla esclusivamente perché il software non gira più significa trasformare motori, telaio, elettronica e alimentatore funzionanti in rifiuto elettronico per una causa che non riguarda l’hardware.
Se un’applicazione relativamente piccola può prolungarne la vita di altri cinque anni, il valore non è soltanto economico. Significa utilizzare più a lungo materiale ed energia già incorporati nella macchina. Da questo punto di vista l’AI coding potrebbe diventare un vero strumento di right-to-repair digitale, anche senza modifiche legislative: permette alla comunità di ricostruire almeno alcune delle funzioni software che il produttore non mantiene più.
Il caso di Niklas Barning resta per ora un esperimento individuale e NanoPrint non è una soluzione universale. Non sostituisce ancora l’intero workflow di stampa, non risolve la disponibilità dei ricambi e dipende dal fatto che il firmware originale della Nano continui a funzionare. Ma dimostra un principio importante: la fine del supporto ufficiale non deve più coincidere necessariamente con la fine della vita utile dell’hardware.
Nel prossimo decennio potremmo quindi assistere a un cambiamento curioso. Fino a oggi i progetti community che mantenevano in vita vecchie stampanti erano prevalentemente realizzati da programmatori e appassionati con competenze specifiche. Gli agenti AI possono aumentare enormemente il numero di persone in grado di provarci. Quando una vecchia applicazione smetterà di funzionare, la prima domanda potrebbe non essere più “quale stampante nuova devo comprare?”, ma “quanto è difficile ricostruire il piccolo pezzo di software che mi serve per continuare a usare quella che ho già?”.
