Due guasti. Una sera. Entrambi mentivano.

Prima, un errore di validazione con valori che erano chiaramente corretti. Poi, un comando “invia alla stampante” che spariva nel silenzio. Nessuna conferma. Nessun errore. Nulla.

La missione: determinare cosa si fosse rotto davvero. Non cosa affermava la finestra di dialogo. Non cosa dicevano i forum. Cosa si fosse rotto davvero, isolato strato per strato, con prove concrete.

Stampo miniature. Ho una Bambu A1 con ugello da 0.2mm e profili della community per miniature da tavolo. Orca Slicer è il mio strumento di scelta perché mi dà più controllo rispetto a Bambu Studio. Quel controllo ha un costo: quando le cose vanno storte, sei da solo.

La settimana scorsa ho incontrato due guasti separati nella stessa serata. Entrambi risolti non cercando l’errore su Google o tornando a una versione precedente, ma applicando lo stesso metodo che uso al lavoro: leggi i log, isola il livello, elimina i sospettati uno per uno.

Questo articolo parla di quel metodo. La stampa 3D è solo lo scenario.

Atto 1: L’Errore che Mentiva

Ho caricato un profilo miniature della community (Dungeons and Derps 2.0, ottimizzato per dettagli da 0.2mm) e ho avviato lo slice. Orca ha mostrato questo:

Organic support tree tip diameter must not be smaller than support material extrusion width

Bene. Ho letto i valori. Diametro della punta: 1.2mm. Larghezza di estrusione: 0.2mm. Una punta sei volte più larga dell’estrusione. L’errore affermava che 1.2 < 0.2. Non funziona così con i numeri.

Passo 1: non fidarsi dell’interfaccia, leggere la fonte.

Il profilo vive come file JSON. L’ho aperto con grep invece di cliccare nei menu:

grep -r "line_width" ~/Library/Application\ Support/OrcaSlicer/user/

Eccolo. Tutti e otto i campi di larghezza linea erano impostati come percentuali: "150%", "120%", e così via. L’interfaccia li mostrava come valori calcolati in mm, che sembravano corretti. Ma la logica di validazione faceva qualcos’altro con le stringhe percentuali grezze.

Passo 2: confermare spostando l’errore.

Ho convertito un campo in mm assoluti. L’errore si è spostato al campo percentuale successivo. Classico gioco del topo: premi in un punto e il problema riappare accanto. Questa è una conferma, non un nuovo problema. Significa che la diagnosi è corretta.

Soluzione: convertire tutti e otto i valori di larghezza linea da percentuale a mm assoluti (percentuale x diametro ugello). Reslice. Pulito.

Lezione: il messaggio di errore accusava il colpevole sbagliato. Puntava al diametro della punta. Il vero colpevole era come la validazione legge le larghezze linea basate su percentuale, un bug noto (OrcaSlicer issue #5431 ). Il JSON era la verità. La finestra di dialogo era un’interpretazione.

Atto 2: Invia alla Stampante, Non Succede Nulla

Sliced. Premo invia. Niente. Nessuna barra di avanzamento. Nessun errore. Nessuna conferma. Provato in modalità LAN: stesso silenzio. Provato in modalità cloud: stesso silenzio. Solo il pulsante, e poi il vuoto.

Questo è il pattern UX peggiore: un guasto che non produce nessun segnale. Nessun segnale significa che non puoi iniziare a ragionare. La prima mossa deve essere creare un segnale.

Passo 1: leggere i log.

tail -f ~/Library/Application\ Support/OrcaSlicer/log/orcaslicer.log

Segnale acquisito:

print_job: failed, result = -26
LAN connection verification failed: ftp_ok=false

ftp_ok=false. Lo slicer sta cercando di connettersi alla stampante via FTPS (porta 990) e fallisce. Ora ho una direzione.

Passo 2: isolare il livello.

Ho aperto Bambu Studio. Stesso computer. Stessa rete. Stessa stampante. Stesso firmware. Invia alla stampante: ha funzionato immediatamente.

Questo elimina quattro sospettati in una volta: la stampante, la rete, il firmware e le credenziali. Se Bambu Studio riesce a raggiungere la stampante, nessuno di questi è il problema. La lista dei sospettati ora contiene esattamente un elemento: qualcosa di specifico a Orca Slicer.

Passo 3: eliminare il plugin.

Orca usa un plugin di rete (un bundle .dylib su macOS) per gestire la comunicazione con la stampante. L’ho spostato fuori dal bundle dell’applicazione e rilanciato. Orca ha riscaricato il plugin, stessa versione. Stesso fallimento.

Stato del plugin: innocente. Il problema non è un dylib corrotto o obsoleto.

Passo 4: dimostrarlo con il protocollo grezzo.

Se il livello FTPS funziona e la stampante funziona, il bug è in come Orca gestisce la connessione. Ho verificato con due comandi:

# La porta è aperta?
nc -z PRINTER_IP 990

# Posso autenticarmi e listare i file?
curl --ftp-ssl --user bblp:ACCESS_CODE ftps://PRINTER_IP:990/

nc ha confermato che la porta 990 è aperta. curl ha listato lo storage interno della stampante. Lo stesso codice di accesso salvato nel file di configurazione di Orca. Lo stesso IP. Funzionante.

Verdetto: il protocollo FTPS funziona. La stampante accetta connessioni. Il plugin di rete di Orca 2.4.1 su macOS ha un bug in come inizia quella connessione (OrcaSlicer issue #12563 ).

Workaround: dato che curl riesce a raggiungere la stampante direttamente, non ho bisogno che Orca invii il file. Slice in Orca, esporto come plate .3mf, poi carico con uno script shell:

#!/usr/bin/env bash
# send-to-a1.sh: carica un plate 3mf sulla Bambu A1 via FTPS
FILE="${1:?usage: send-to-a1.sh <file.3mf>}"
PRINTER_IP="192.168.68.XXX"  # sostituisci con l'IP della tua stampante
ACCESS_CODE="XXXXXXXX"       # sostituisci con il codice di accesso mostrato sullo schermo della stampante

curl --ftp-ssl \
  --user "bblp:${ACCESS_CODE}" \
  -T "${FILE}" \
  "ftps://${PRINTER_IP}:990/cache/$(basename ${FILE})"

echo "Caricato. Avvia la stampa dallo schermo della stampante."

Slice in Orca. Esporta. Esegui send-to-a1.sh plate_1.3mf. Avvia dallo schermo. Dieci secondi.

Il Metodo, Estratto

Questi erano due guasti indipendenti. L’approccio di debug era identico entrambe le volte.

  • I messaggi di errore sono affermazioni, non fatti. Riflettono cosa l’autore del codice pensava fosse sbagliato al momento della scrittura. I log e i protocolli grezzi sono fatti.
  • Ricerca binaria sullo stack. App / plugin / rete / credenziali / dispositivo. Ogni test deve eliminare esattamente un livello. Quando qualcosa funziona, quel livello è innocente.
  • Un secondo client è un gruppo di controllo gratuito. La presenza di Bambu Studio sullo stesso computer ha trasformato un’indagine di rete da 30 minuti in un’eliminazione da 30 secondi.
  • Quando il percorso GUI è rotto, il protocollo sottostante spesso funziona. curl è l’ultima risorsa universale. Se sai quale protocollo usa l’app, puoi usarlo tu stesso.
  • Archivia le prove upstream. Una riga di log più un repro curl funzionante è il bug report più prezioso che puoi scrivere. I maintainer possono riprodurlo in minuti.

Missione compiuta. La stampante era innocente dall’inizio. Lo slicer ha confessato sotto interrogatorio. Prossimo obiettivo: lo stesso metodo si applica ovunque. Leggi i log. Isola il livello. Fidati del protocollo, non della finestra di dialogo.