3D Printing – L’elettronica ed il firmware

main

Dopo tanta attesa, finalmente l'elettronica della 3DRag! La roadmap prosegue con l'analisi della scheda di controllo e del firmware che la gestisce, per poi dare uno sguardo alle funzionalità  previste sia a livello HW che FW ma non ancora attivate sulla versione della stampante che stiamo vedendo. Seguiteci, adesso arriva la parte divertente!

Il pregio della Meccatronica e' che si tratta di un settore multidisciplinare, in cui ci si trova a spaziare tra concetti di Fisica, Informatica, Meccanica, Elettronica ed altro, e ciò favorisce di certo la costruzione di una visione mentale più ampia del mondo tecnologico.
Di contro, il suo difetto è il fatto stesso che per comprendere a fondo un dato aspetto spesso ci si deve scontrare non solo con i "propri" problemi ma anche con quelli dei mondi confinanti.
La seconda puntata della nostra serie sulla Stampa 3D ha confermato proprio questa tendenza: un elettronico che voglia capire per bene come funziona un stampante 3D non può fermarsi ad analizzare le sole componenti elettroniche della stessa, ma deve "sbattere la testa" anche sulle componenti meccaniche del sistema, così da poterle associare alle scelte dei componenti elettronici sulla scheda di controllo ed alle istruzioni che troverà nel firmware.
Come già osservato, gli elettronici finora si saranno forse un pò annoiati, ma vi assicuro che per le letture a venire si divertiranno.
Infatti, visti i muscoli del sistema, entreremo ora nei dettagli del cervello e del DNA dello stesso, ovvero "spulceremo" la scheda di controllo, tutti i cablaggi da/verso le periferiche ad essa connesse e vedremo cosa è in grado di gestire il firmware che vi gira sopra.
Vedremo inoltre degli accenni al G-Code in input alla scheda.
Come ormai sapete, 3DRag è una stampante open source italiana progettata e realizzata partendo da una base RepRap: se però le differenze si notano soprattutto a livello di meccanica, sulla parte elettronica c'è una grande affinità tra le due dato che sulla prima è stata inizialmente utilizzata la stessa scheda montata sulla seconda.
Dico "inizialmente" in quanto della 3DRag fino ad ora sono state prodotte 3 versioni (1.0, 1.1 e 1.2), ed ognuna di esse monta un controller diverso: la versione 1.0 si avvaleva della board Sanguinololu, ovvero proprio la scheda che equipaggia alcune implementazioni di stampanti RepRap. Nella stampante in mio possesso (la 1.1) la scheda di controllo è invece una customizzazione di un'altra scheda nota nel mondo RepRap, la RAMPS; viene prodotta dalla stessa ditta che produce la 3DRag e pertanto, un pò come avvenuto per la meccanica, si può dire che anche in questo caso l'elettronica è figlia del progetto RepRap, dal quale ha preso le basi ed al quale ha aggiunto qualche nuova feature.
Del resto, questo è il bello dell'open source!
Di seguito un'immagine della scheda per la stampante oggetto di questi articoli:

Il firmware che gira su tale scheda è un'altra "vecchia conoscenza" del mondo RepRap, il cosiddetto Marlin scritto dal programmatore Erik van der Zalm. Anch'esso di natura open source, si adatta abbastanza facilmente ad una serie di schede di controllo che abbiano a bordo un determinato set di componenti HW. La versione che attualmente utilizzo io è la 1.0.
Fatte le dovute presentazoni, entriamo dunque nei dettagli di scheda e firmware.

 

La scheda di controllo

Una scheda di controllo per stampanti 3D di tipo FFF, così come avviene per le normali stampanti 2D, è un dispositivo complesso nell'HW ma abbastanza semplice nel suo principio di funzionamento; è deputato fondamentalmente al controllo dei motori lungo gli assi di spostamento del piatto di stampa e di una serie di altri parametri quali la gestione della temperatura dell'estrusore, la velocità di spostamento dei carrelli, la trazione del filamento di stampa, la ventola di raffreddamento ed altri aspetti. E, ultimo ma non per ultimo, il dialogo con il dispositivo di comando della stampante (caso classico è il PC).
In buona sostanza, la componentistica HW fondamentale di un tale tipo di scheda prevede, oltre al suo stadio di alimentazione, dei driver per il controllo degli stepper-motor, dei finali di potenza per il riscaldamento dell'estrusore, una sonda di controllo della temperatura raggiunta da quest'ultimo ed una sezione per la conversione seriale/USB per lo scambio di dati con il PC.  
Quella sopracitata può essere considerata a tutti gli effetti la dotazione HW minima per la scheda di una stampante FFF.
Chiaramente, gli specifici componenti elettronici utilizzati possono fare la differenza tra le varie funzionalità a disposizione.
Un esempio su tutti: il microcontrollore.
La scheda Sanguinololu della 3DRag 1.0 impiegava a bordo un ATmega644 della ATMEL, senz'altro un valido chip ma con alcune limitazioni legate alla sua architettura interna, come ad esempio una memoria programma un pò limitata (64 KB) ed un ridotto numero di periferiche HW disponibili sui suoi pin. Entrambi questi aspetti portavano a limitare eventuali nuove funzionalità implementabili sia nell'HW che nel FW.
Per la scheda della versione 1.1, che per praticità d'ora in avanti chiameremo CONTR-V1.1, si è invece passati al micro ATmega2560, ben più performante nei due aspetti appena discussi.

 

Gli effetti che sono subito emersi sono stati la non saturazione della memoria con il firmware (il che si traduce in firmware espandibile) e la disponibilità fisica di funzionalità aggiuntive. Un esempio che a qualcuno farà gola è la possibilità di collegare una SD-card in cui sia inserito il G-Code di un modello 3D e farlo leggere direttamente alla CONTR-V1.1 senza che sia un PC a doverglielo inviare. Il tutto grazie alla messa a disposizione dei pin del bus di comunicazione SPI del micro. Inoltre, grazie alla disponibilità di un maggior numero di I/O dell'ATmega2560 "portati fuori", si può collegare alla scheda un piccolo display LCD (basato sul classico controller HD44780), sempre per favorire un controllo autonomo della stampante.

 

Certo, utilizzare un software di controllo direttamente dal PC è un modo molto più completo di comandare e controllare la 3DRag, ma una volta ottenuto il G-Code del modello da stampare e lanciata la stampa, i parametri principali da tenere sotto controllo durante il processo non sono poi molti: visualizzarli su un display LCD permette di non essere legati al PC e di poterlo spengere, e siccome l'assorbimento di corrente dei motori che lavorano non è indifferente, tali "plus" vi assicuro che risulteranno utili.
Sempre sul microcontrollore va detta una cosa importante: alcuni degli "Arduino-addicted" tra voi avranno sicuramente notato che si tratta dello stesso chip montato da Arduino Mega: questo aspetto, unito alla presenza del noto chip FT232RL per la conversione USB/seriale, permette di (ri)compilare il firmware e di inviarlo alla CONTR-V1.1 da un IDE Arduino esattamente come faremmo con un normalissimo sketch di Arduino Mega. Anche in questo caso, non sottovalutate la potenza di questa funzionalità, poichè essa comporta l'utilizzo di componenti COTS per la programmazione dell'HW (ovvero un semplice PC con porta USB), uno degli aspetti che ha favorito di gran lunga il succeso di Arduino.

Al pilotaggio dei 4 motori (3 assi+trascinamento filo) sono deputati dei moduli driver basati sull'integrato A4988 della Allegro. Senza entrare nei loro dettagli elettronici, l'aspetto che colpisce di più è la loro capacità di far compiere ai motori dei passi estremamente ridotti: oltre al singolo step di 1 mm, è possibile impostarli via FW per ottenere spostamenti di 1/2, 1/4, 1/8 o 1/16 di step, e questo vuol dire estrema precisione nel controllo movimenti (specie nel caso dell'asse Z, in cui conviene "alzarsi" di poco tra ogni singola slice di stampa).

La temperatura è gestita nel modo seguente.
Al riscaldamento dell'elemento di fusione dell'estrusore provvede un MOSFET di tipo BUK6215-75C a canale N, controllato in PWM dal microntrollore al fine di limitare i consumi (o meglio, le perdite di energia). A tal proposito, siamo sui 2,5 A e questo permette di evitare l'uso di un dissipatore dedicato sulla scheda dato che per correnti di quest'ordine è sufficiente il raffreddamento dato dalla normale dissipazione della piazzola posteriore del chip a contatto con le piste.
Lo stesso tipo di componente è impiegato anche per controllare (sempre in PWM) la ventola di raffreddamento, necessaria a far solidificare in tempi brevi il filamento appena estruso dall'ugello di stampa, così da limitare le deformazioni plastiche dell'oggetto stampato.

 

I valori di temperatura raggiunti dall'estrusore vengono letti da una sonda a termistore NTC da 100 kOhm (a 25°C), ed è grazie a questo continuo feedback che il microcontrollore può portare/stabilizzare la temperatura ai valori impostati.

Altri elementi fondamentali sono i microswitch di fine corsa: si tratta di semplici interruttori elettromeccanici che chiudono un contatto, inviando dunque un segnale digitale al micro. Sono fondamentali in quanto permettono ai motori (o meglio, al microcontrollore che li gestisce) di capire qual'è il punto 0 su un determinato asse, evitando dunque di continuare ad inviare al motore l'impulso del movimento quando non necessario.

Questa è la dotazione di base che sto utilizzando al momento sulla 3DRag v1.1 e che ripeto essere stata concepita valutando sia quanto offerto dalla scheda Sanguinololu sia dalla RAMPS.
Come potrete notare, la CONTR-V1.1 impiega esclusvamente componentistica SMD.

L'alimentazione viene fornita da un alimentatore a 15V con uscita da 4A.
Come tuttavia ho accennato in precedenza, il bello di questa rivisitazione HW rispetto ad altre schede è che le potenzialità non si fermano qui.
Date un'occhiata allo schema di collegamento:

Abbiamo già visto come l'ATmega2560 permetta di avere disponibili il bus SPI e gli I/O per un controllo autonomo della stampante (l'area da 18 piazzole libere vicino al pulsantino di reset della scheda).
Se osservate bene lo schema, sono previste due sezioni di riscaldamento ("HEATER1" e "HEATER2"): mentre la prima è utilizzata per l'estrusore, la seconda viene resa disponibile nel caso si volesse utilizzare un piatto di stampa riscaldato (specie per chi lavora con l'ABS, che necessita di mantenere gli strati estrusi ad una certa temperatura anche dopo la deposizione, onde evitare rotture e deformazioni). In questo caso, l'uscita HEATER2 può fornire anche 6A.
Analogo discorso vale per la lettura della temperatura, dove lo strip di contatti "THERM1" è utilizzato dal termistore associato all'estrusore e lo strip "THERM2" è legato all'eventuale presenza di un secondo termistore per il piatto riscaldato.

 

Inoltre, sulla CONTR-V1.1 c'è la predisposizione fisica per poter sostituire i microswitch di fine corsa, al momento semplici interruttori elettromeccanici, con dei moduli ottici (da cui la presenza dei 3 pin sui relativi strip).
Ultima considerazione sulla dotazione HW presente ma non attiva (o comunque non utilizzata nella mia stampante) è il connettore ICSP per la programmazione in-circuit dell'ATmega2560, utile nel caso si voglia ricaricare il bootloader per la gestione di un nuovo firmware (o la ricompilazione di quello utilizzato per estendere le funzionalità), esattamente come si farebbe con una scheda Arduino.  
In poche parole, oggi la scheda mi permette di stampare in un certo modo base, ma se volessi fare degli upgrade futuri c'è già una buona parte di occorrente per non farmi cambiare la scheda!
 

Note sul cablaggio

Il cablaggio è stata un'operazione abbastanza lunga ed impegnativa. Il grosso del lavoro si è avuto nel saldare le varie giunture ed i terminali dei collegamenti. Ma di certo conviene perdere un pò più di tempo inizialmente nel creare giunzioni ben protette piuttosto che rischiare di mandare in corto la scheda perchè si è saldato o isolato male un contatto.
Fondamentale si è rivelato l'uso della guaina termorestringente come isolante: se siete di quella scuola che vede nel nastro adesivo la "via dell'isolamento", cambiate scuola…almeno nell'utilizzo di questa scheda, dove i vari contatti sono spesso fin troppo vicini.
Una cosa che personalmente mi è piaciuta poco nella dotazione per il cablaggio è stata l'impiego, al posto dei cavi bifilari, di quelli con anima centrale e rivestimento esterno con calza in rame isolata: la scomodità nel separare i due conduttori si è fatta sentire e non vedo particolari motivi (tecnici) per aver previsto nel kit questo tipo di fili.
Per il resto, non ci sono state particolari difficoltà nel collegare le varie componenti alla scheda. E' previsto per quest'ultima un alloggiamento sul montante verticale della stampante, che tuttavia la lascia completamente scoperta. Un motivo in più per realizzarsi in 3D un case apposito, una volta messa in funzione la stampante!
 

Il firmware

Abbiamo detto che il firmware con cui viene precaricata la 3DRag 1.1 è Marlin v1.0.
Marlin è un firmware complesso e questa non è la sede per spiegarne le singole righe di codice (molte e comunque ben commentate).
Piuttosto conviene cercare di illustrarne le macro-caratteristiche e ciò che lo ha reso una scelta valida per la 3DRag tra quelle disponibili.
Innanzitutto è open source, e questo ha permesso di poterlo utilizzare customizzandolo per la nostra stampante. In realtà, quella della customizzazione è una via abbastanza condivisa nel mondo Reprap: perchè creare un firmware specifico per ogni nuova implementazione di stampante 3D quando in fondo le operazioni di base sono sempre quelle e ciò che varia è principalmente l'associazione pin del microcontrollore-componenti elettroniche/elettromeccaniche della stampante?
Ecco perchè si è scelto di suddividere il firmware in due parti logiche: da un lato c'è il motore software che si occupa dell'interpretazione dei comandi e del G-Code e dall'altro la gestione delle feature specifiche viene demandata alla componente software di configurazione del sistema. E' poi l'utente che, per installare il firmware o abilitarne certe funzionalità aggiuntive, agisce (abbastanza semplicemente) su un file di configurazione: si tratta di un file .h (header C) in cui sono presenti una serie di direttive #define in cui ad ogni voce di configurazione è associato un dato valore.
Ad esempio, la prima da valutare è la direttiva riguardante la motherboard del controller utilizzato:

#define MOTHERBOARD 7

dove il codice 7 rappresenta la scheda CONTR-V1.1: questa informazione consente la compilazione del firmware con la giusta mappatura  tra i pin analogici/digitali e le varie risorse del sistema.
Altro esempio è la direttiva

#define BED_SENSOR_0 0

con cui si sta istruendo il firmware a non tenere conto del segnale rilevato del termistore del piatto di stampa (ad esempio perchè la stampante non è dotata di piatto riscaldato, come nel mio caso).

Si potrebbero vedere molti altri esempi di direttive, come quelle legate ai limiti di spostamento dei carrelli lungo i vari assi:

#define X_MAX_POS 200
#define X_MIN_POS 0
#define Y_MAX_POS 200
#define Y_MIN_POS 0
#define Z_MAX_POS 220
#define Z_MIN_POS 0

(con cui diciamo al firmware che l'escursione massima dei carrelli X ed Y è di 200 mm e di 220 mm per quello Z), oppure quelle relative agli step dei motori:

#define DEFAULT_AXIS_STEPS_PER_UNIT (xxx, yyy, zzz, kkk)

(con cui indichiamo che per la rotazione dell'unità base di 1 mm occorrono xxx step per il motore X, yyy step per quello Y e così via).
Le voci sono molte e non possiamo elencarle tutte, ma il principio credo sia chiaro.
Piuttosto, quello che conviene capire del firmware è che in esso "convivono due anime", quella per la gestione delle operazioni dirette con l'utente, come i controlli manuali su carrelli/estrusore e lo scambio dati di funzionamento in tempo reale, e quella per l'esecuzione del G-Code, ovvero l'insieme di tutte le istruzioni macchina per la realizzazione fisica del modello 3D.
Potremmo dire che la prima è la mente, reattiva e che ascolta il mondo esterno, mentre la seconda è il braccio che esegue il lavoro che gli è stato affidato…senza pensarci troppo sopra!
Parlando del braccio, Marlin è in grado di interpretare sia istruzioni in G-Code sia in M-Code, i due standard industriali per il controllo di macchine CNC: fondamentalmente il primo prevede istruzioni di posizionamento del dispositivo mentre il secondo istruzioni operative circa lo stato della macchina. In particolare, rispetto alla versione standard, l'M-Code interpretato da Marlin prevede alcune istruzioni aggiuntive specifiche, come ad esempio la messa in pausa per il cambio del filamento e la gestione di una SD-card.
Di seguito riportiamo un brevissimo estratto di G-Code per la stampa di un piccolo fischietto (le righe di codice generato sono in tutto 24935!):

G21 ; set units to millimeters
M107
M104 S210 ; set temperature
G28 ; home all axes
G1 Z5 F5000 ; lift nozzle
G90 ; use absolute coordinates
G92 E0
M82 ; use absolute distances for extrusion
G1 F1800.000 E-1.00000
G92 E0
G1 Z0.500 F6000.000
G1 X76.819 Y81.051
G1 F1800.000 E1.00000
G1 X77.729 Y80.231 F1440.000 E1.07735
G1 X78.169 Y79.861 E1.11365
G1 X79.129 Y79.131 E1.18981
G1 X79.669 Y78.761 E1.23114
G1 X80.669 Y78.141 E1.30544
....

Come potete notare si alternano istruzioni G ad istruzioni M, sebbene da un certo punto in poi vi siano solo istruzioni G (questo accade quando le impostazioni sullo stato della macchina sono state effettuate e si parte con il lavoro dei motori).
Ricordate chi genera il codice? E' il software di slicing, quello deputato ad "affettare" un modello 3D digitale al fine di identificarne i passi per la realizzazione di ogni singola fettina. Il codice viene generato facendo un mix del modello 3D e delle impostazioni di stampa che andiamo a settare prima dello slicing. Infatti, la prima parte del listato riportato contiene informazioni non direttamente connesse con la geometria del modello 3D (es. "M104 S210" vuol dire "imposta la temperatura dell'estrusore a 210 °C"), mentre dalla quart'ultima istruzione in poi si hanno solo coordinate per lo spostamento del piatto di stampa.
Parlando invece della mente, Marlin dialoga con il PC (in genere serialmente con un opportuno software di controllo) al fine di recepire da esso comandi/controlli utente e la sequenza di istruzioni macchina.
Ora che abbiamo una visione d'insieme del lavoro del firmware, dovremmo poter capire anche perchè, per il mero lavoro di stampa, il PC non sia strettamente necessario.
Una volta ottenuto il G-Code (compito per cui serve ovviamente il PC), alla scheda occorre solamente una fonte da cui poterlo leggere: ecco l'utilità di avere la predisposizione in HW di una scheda SD e di un display LCD, in questo modo la scheda di controllo può autonomamente andarsi a prendere le istruzioni in G-Code dalla propria SD-card invece di "vedersele arrivare" sulla linea dati seriale e può restituire le informazioni di stato direttamente al piccolo schermo. Siccome per oggetti complessi ci vogliono diverse ore di stampa, pensate a che vantaggi si avrebbero a lanciare una stampa di notte spengendo il PC.
 

F.A.Q.

Q. Posso sfruttare l'ATmega2560 della scheda per ottenere qualche funzionalità personalizzata?
A. Sì. Le 18 piazzole libere permettono di controllare una serie di I/O del micro; c'è chi si è realizzato ad esempio una lampada per l'illuminazione controllata del piatto di stampa durante la lavorazione di un pezzo. Il più delle volte, però, serve realizzarsi un PCB aggiuntivo.

Q. E' davvero necessario un alimentatore da almeno 4A di corrente?
A.
Sebbene a regime il consumo sia può basso, i motori possono avvicinarsi molto a tale soglia, per cui è fortemente consigliato. Se poi si prevede l'utilizzo di un piatto di stampa riscaldato, 4A potrebbero addirittura essere pochi.

Q. Quale IDE Arduino devo utilizzare per ricompilare il firmware?
A.
Sembra sia necessario l'IDE 0022, un ambiente di sviluppo di qualche tempo fà ma ancora disponibile per il download presso il sito di Arduino.

Q. Marlin è l'unico firmware che supporta questa scheda?
A.
No. Ne esistono anche altri, come ad esempio Teacup, Sprinter, Repetier-Firmware, Five-D, la maggior parte dei quali open-source. Ovviamente bisogna compilare il nuovo firmware settando le opzioni relative alla scheda CONTR-V1.1

Q. Il G-Code deve provenire per forza da un software di slicing?
A.
No. La 3DRag è a tutti gli effetti una macchina CNC, per cui si può anche scrivere il G-Code di proprio pugno (o modificarne uno prodotto da qualche altro software) e darlo in pasto alla scheda di controllo. Ovviamente, a differenza di altri linguaggi di programmazione, il G-Code è molto legato alla macchina: se le si invia codice G per il taglio al plasma di una barra di metallo non si otterrà nulla.
 

Conclusioni

Anche questa tappa si è conclusa. Spero sia risultata più piacevole dell'altra e che ora abbiate un quadro più completo di come è fatta e come funziona una stampante 3D.
Non resta che calibrarla e vederla all'opera: ed è proprio quello che faremo nel quarto ed ultimo articolo di questa serie.
La scatola del kit che tanto mi spaventava all'inizio è ormai vuota.
Spero di poterla riempire presto con qualche bella stampa 3D.
Stay Tuned!

10 Comments

  1. Marven 27 dicembre 2013
  2. delfino_curioso delfino_curioso 27 dicembre 2013
  3. Alberto.Sassara 22 febbraio 2014
  4. delfino_curioso delfino_curioso 24 febbraio 2014
  5. Michele.Melillo 29 dicembre 2013
  6. delfino_curioso delfino_curioso 29 dicembre 2013
  7. Giorgio B. Giorgio B. 27 dicembre 2013
  8. delfino_curioso delfino_curioso 27 dicembre 2013
  9. adrirobot adrirobot 27 dicembre 2013
  10. delfino_curioso delfino_curioso 27 dicembre 2013

Leave a Reply