Stampante con motori DC ed elettronica (molto) low cost

Salve a tutti! Questo è il mio primo post sul forum, e ho pensato di condividere il progetto che sto cercando di realizzare.

Innanzitutto mi presento: mi chiamo Adriano, sono un (quasi) ingegnere dell'automazione e mi sono recentemente deciso ad affacciarmi in questo mondo

L'idea che sta alla base del progetto è semplice e tipicamente ingegneristica: massimo rendimento, minimo costo.

Ho notato che le stampanti 3D, nonostante la larghissima diffusione che questa tecnologia sta subendo, spesso non riescono a scendere sotto lo zoccolo duro dei 400 euro (circa), e che una larga metà di questo costo è dato dalle elettroniche (80 euro per la RAMPS circa, una ventina per ciascun NEMA17, un'altra ventina per il piano riscaldato PCB, 20 per un arduino e circa 40 per un arduino mega...insomma, un bel po' di quattrini). Da qui l'idea originaria (ma non particolarmente originale... ) di assemblare una macchina dalla spazzatura. Mi sono quindi dato a smontare varie stampanti (ne ho reperite un paio multifunzione, qua all'isola ecologica non ti danno niente...), un vecchio scanner e qualche altro giocattolo sperando in qualche motore e qualche trasmissione e...sorpresa: montano tutte motori DC (anche di una certa consistenza) al posto dei vecchi cari stepper (relegati ahimé al trascinamento del leggero neon/LED dello scanner e poco altro, addirittura mi sono ritrovato con uno stepper miniaturizzato su una cremagliera di plastica ).

Pensa e ripensa, alla fine sono giunto alla soluzione (anche questa non particolarmente originale... sto diventando vecchio): servoazionamenti in continua.

E si dà il caso che questa roba era parte della mia tesi di laurea triennale (una tesi sulla taratura automatica dei regolatori PID applicata alla robotica mobile, molto in breve).

Dopo aver (quasi) completato un telaio in alluminio (fatto con degli scarti di lavorazione e molto poco altro, quindi a costo quasi zero...siamo sui 30-40 euro a occhio e croce, a fronte di un'area di stampa di circa 35x35x30, devo ancora misurarla), ieri mi sono dedicato allo shopping. Ecco il setup che ho pensato di realizzare per l'elettronica:

1) Innanzitutto, via questo arduino: il cervello sarà una STM32F3 Discovery, reperita usata a 10 euro (nuova ne costa 16, se non erro). 72 MHz di clock, il numero di pin pari (se non superiore) a quello dell'arduino mega, giroscopio e accelerometro integrati (per ora non particolarmente utili) e, soprattutto, la possibilità di configurare i timer per l'interfacciamento diretto con gli encoder! (hence -> un paio di integrati da una decina di euro ciascuno risparmiati, se tutto va bene...in alternativa (magari per chi ha Arduino e non vuole intasarlo) per la lettura degli encoder avevo pensato di usare dei decoder della Avago, mi pare si chiamino HSC-2032 )
2) Encoder e motori DC recuperati dalle stampanti: costo zero, arrivano a numeri come 38000 CPT per i lineari (38000 impulsi in circa 30/35 centimetri... significa una precisione ai livelli del micron ). Il controllo si può ottimamente realizzare con uno schema in cascata (velocità e posizione) e dei regolatori PI (eventualmente, volendo fare i pignoli, identificando i motori prima...altrimenti con delle tarature automatiche da zingaro )
3) Arriviamo alla nota dolente: i driver di potenza per i motori DC...ho pensato di uniformarmi ai 12V usati nella maggior parte dei progetti reprap. Il problema è che un driver per motori DC può arrivare a costare anche 40-50 euro. Io però, ho conosciuto loro: i microdriver Pololu con su il Toshiba TB6612FNG. Piccoli, decorosamente potenti (fino a 14V e 1A per canale, ciascuno pilota 2 motori) e, soprattutto, pagati 3 euro e 10 centesimi l'uno da un'azienda in Polonia!

Costo complessivo: meno di 20 euro


Il problema ora è: testare tutto questo. Quindi se qualcuno ha commenti, idee, suggerimenti o si accorge che per qualche motivo tutto questo è una cagata pazzesca (cito ), io sono tutto orecchie

Edited 2 time(s). Last edit at 11/29/2014 05:28AM by ApBrandy.

e adesso.... di firmware quale usi?

---

Davide
Immagina e Crea
Progetto Flusso canalizzatore 4 vie
My Thingiverse

Pensavo di scriverlo prendendo a modello qualcuno di quelli esistenti. Tu quale consigli?

Ah, dimenticavo, ho recuperato un LCD da una stampante Canon che speravo di recuperare

(a proposito, complimenti per il post sull'estrusore a quattro vie, gli ho dato uno sguardo rapido e mi sembra fatto molto bene )

Edited 1 time(s). Last edit at 11/29/2014 05:55AM by ApBrandy.

Quote
immaginaecrea
e adesso.... di firmware quale usi?

Ho pensato esattamente la stessa cosa!

---

Alessandro

Prusa I3 Rework molto modificata - Taurino Classic - Ramps 1.4 - Driver DVR8825 - Titan Extruder e Hotend E3D V6 - Bltouch originale - Firmware MarlinKimbra - Cura - Repetier Host

Ho pensato la stessa cosa anche io.
Ovviamente, avere il codice già scritto è una comodità... però io non ho nessuna fretta.

Pensavo di procedere così: innanzitutto, implementare il controllo dei motori (lettura encoder e comunicazione col driver pololu) in posizione e velocità. Fatto questo, la movimentazione assi dovrebbe essere una banalità (gli passi delle terne di posizioni e lui porta i motori in quel posto).
Per quanto riguarda l'estrusore, pensavo di fare sostanzialmente un relè con una banda di isteresi non troppo ampia (semplice ed efficace).
Stessa cosa per l'heated bed (eventualmente).
Il controllo di accelerazione andrebbe fatto con un controllo di coppia, ma questo diventa più complicato non disponendo di un feedback di corrente...quindi questo è da vedere.

Resta da fare la lettura dei file generati dai programmi di slicing (quella potrebbe essere un po' una rogna) e poi aggiungere qualche altra funzionalità qua e là (lettura da usb, impostazione parametri da tastierino, comunicazione con LCD, piccole cose per renderla il più "indipendente" possibile).

Dimentico qualcosa?

Complimenti...
La prima cosa da fare per il FW , non conoscendo la scheda, è l'interfaccia seriale. Cioè devi fare in modo che la USB venga vista come una seriale. Poi devi crearti la parte che con il classico protocollo seriale riceva comandi, una volta fatto questo il resto (per quanto riguarda i comandi gcode) è banale) ogni comando corrisponde una funzione, quindi piano piano ti crei le funzioni che ti servono...
Invece andiamo ai punti dolenti quelli più complessi.
1° la gestione delle temperature, tutto deve essere fatto con degli interrupt, in modo da consentire al processore il continuo controllo della temperatura del/degli hotend.
2° il movimento, non è poi cosi facile come hai detto tu. Gli dico di andare in quel punto e ci va... Magari... C'è un elemento che condiziona tantissimo tutta la routine di movimento, l'estrusore. Cioè devi tenere conto del materiale che sta uscendo mentre ti muovi e quindi essere conseguente a quello.
Anche con i movimenti devi lavorare di pianificazione, cioè pianificare un movimento e il suo successivo etc etc in modo che il processore tenga sempre d'occhio i motori...
Cmq visto che i vari fw sono scritti in C (più o meno) non è molto difficile adattarli a un altro processore, le differenze sono solo su i timer e pin. Quindi un po alla volta piccole routine le prendi le adatti e via cosi..
Facci sapere i risultati....

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Grazie mille per gli utilissimi consigli
Purtroppo temo che i risultati li saprete tra un po', sto procedendo molto a rilento causa vari impegni...diciamo che è un progetto senza scadenza

La cosa positiva sarebbe quella di avere un firmware completamente modulare e adattabile alle esigenze (oltre che estremamente economico). Ovviamente mi sono attrezzato per la costruzione di PCB (prima della stampante mi sono costruito un piccolo bromografo a fotoimpressione col case dello scanner che ho smontato ) con la prospettiva di realizzare una simil-RAMPS o una specie di generation7.

Per quanto riguarda la gestione delle temperature, penso che la questione degli interrupt non sia poi impossibile...insomma, da qualche parte sul manuale te lo spiegheranno come gestirli X] Come dicevo, la scheda ha un clock a 72 MHz contro gli 8 (mi pare) di Arduino, quindi non dovrebbe caricarla particolarmente...con una banda di isteresi di 5/10 gradi e un buon isolamento termico del'estrusore secondo me si tratta di un aggiornamento con una frequenza dell'ordine di grandezza dei decimi di secondo (un'inezia, per il processore, che di fatto deve solo attaccare e staccare un contatto )

Per quanto riguarda la questione estrusore, pensavo di fare esattamente il contrario: fissare il movimento e poi decidere di conseguenza la velocità di estrusione...dici che è possibile?
(comunque ovviamente io mi riferivo alla movimentazione assi in sè per sè, la questione estrusione devo ancora studiarla...se poi non dovesse funzionare, alla peggio la riciclerò come CNC per qualche altro scopo...o come sgabello hi-tech ) Credo però che, per questo, la cosa migliore sia copiare qualche altro firmware già fatto.

Infine, di solito la USB è già vista come una seriale (quantomeno, nell'altro processore ARM che mi è capitato di programmare funzionava così)

Edited 1 time(s). Last edit at 11/29/2014 07:05AM by ApBrandy.

Permettimi di dirti due cosine...
1° 5/10° d'isteresi, non è possibile, l'hotend deve rimanere a quella temperatura senza variare di un solo grado, per quanto riguarda il bed si ci può stare infatti viene pilotato on/off, ma gli hotend no. Hanno un sistema chiamato PID, e a essere sinceri ancora fatico a capirlo, ma piano piano ci arriverò. Purtroppo mi mancano tutte quelle nozioni sulla termica...

2° no l'estrusore ha una velocità molto più bassa dei movimenti sui tre assi, in più è la sinergia dei tre movimenti, asse X, Y e Estrusore, la Z è un movimento libero visto che viene fatto solo ad ogni layer, non del tutto vero...
Ora se il nozzle deve andare dal punto (20,30) al punto (21,35) e estrudere 1 mm di materiale, il nozzle si deve muovere di X e di Y e di E in modo che arrivi nel punto (21,35) e abbia estruso 1 mm di filo, quindi non deve finire di estrudere prima di essere arrivato o viceversa, non deve arrivare a X prima di arrivare a Y. Ecco perchè viene pianificato il movimento e una routine di timing fa in modo da suddividere i movimenti nel tempo per fare in modo che i tre movimenti siano sincroni e alla velocità del più basso, di solito l'estrusore, ma può anche essere uno dei due assi stessi....
Insomma non è proprio facilissimo, è la parte dove c'è più matematica, geometria e informatica di tutto il FW, il resto è comunissima programmazione...

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Ahhhh, non sapevo l'estrusore avesse un controllo così fine! Pensavo bastasse un relè con qualche grado di banda...farò degli esperimenti comunque, magari con una banda più stretta (tipo 1 grado o giù di lì). Comunque il PID è lo stesso che voglio montare per i motori (nella versione PI, che è quella che si usa comunemente per questo tipo di applicazioni), quindi penso di poter riusare quasi tutto il codice che scriverò. Se hai domande su questo chiedi pure, ci ho fatto svariati esami...bisogna condividere le informazioni

Per quanto riguarda la velocità di estrusione, penso di aver capito cosa intendi...guarderò qualche FW già fatto e cercherò di venirne a capo. Comunque credo che si possa fare così: per il fatto di completare X e Y insieme, è un problema abbastanza semplice di scalatura del moto (robotica più che classica). Ammesso che la Z rimanga costante poi, calcoli la distanza tra il punto di partenza e quello di arrivo (banalmente, col teorema di Pitagora) e poi sulla base di quello fai avanzare E (il motore dell'estrusore, un altro servomotore DC con regolatore PI) di quella distanza (ammesso che ci sia una dipendenza tra quantità di materiale estruso e distanza percorsa, ma immagino di sì). Dici che potrebbe funzionare?

Grazie ancora!

Edited 2 time(s). Last edit at 11/29/2014 08:19AM by ApBrandy.

Ciao, l'argomento mi interessa moltissimo, c'è anche un altro utente del forum (un desaparecidos sardo [forums.reprap.org]) che stava lavorano con i motori DC.
Credo però che "sprecare" risorse che non verrebbero adottate da nessuno sia l'approccio sbagliato.
Mi spiego. Come il Mago per il firmware tu ne sai di hw, quindi perché non usare quello che hanno bene o male tutti (arduino) e migliorarlo?
Il Mago lo sta facendo con il firmware, tu potresti creare uno shield per arduino "attivo" e quindi sfruttare la logica di calcolo già implementata e consolidata.
Forse basta solo delocalizzare i pololu e far arrivare alla scheda per i DC solo i segnali di step e dir (che potrebbe riceverli a treno e gestirsi un buffer di dati)?

Cmq attendo sviluppi

Buon lavoro

PS: altri del forum [forums.reprap.org]

---

Prusa i3 R2 + The Shell - Saintsmart Ramps 1.4 - Mega2560 R3 - Driver A4988 - Firmware MarlinKimbra
Mini Kossel - Alligator - Firmware MarlinKimbra4due

A Trieste, al Makerfaire,
un tizio (se trovassi la foto!!!!) aveva assemblato una stampante con parti (motore, encoder, conghie e struttura) ri stampanti vecchie con motori dc.
Utilizzave encoder per motori dc che avevano il formato pololu e una ramps come controller.

EIDT ecco la vecchia discussione [forums.reprap.org]

Edited 1 time(s). Last edit at 12/03/2014 03:03AM by enricodare.

---

Enrico

[www.dapa3dservice.it] [www.studiodapa.it]
repstrap dApA, Ramps 1.4, MarlinKimbra / scanner 3D Cubify Sense / Formlabs Form 2

Si, progetto interessante, anche se non ho ben capito il vantaggio dei motori DC rispetto ai supercollaudati stepper... ma sono sicuro che ci sia, dal momento che qualcuno li usa

Certo creare un nuovo firmware da zero... è un peccato, visto l'enorme lavoro che c'è stato dietro a quelli esistenti e le continue migliorie, come la gestione di estrusori/hotend muiltipli e l'auto-level.

Un'altra cosa che non ho capito è la seguente:

Quote
ApBrandy
Il controllo di accelerazione andrebbe fatto con un controllo di coppia, ma questo diventa più complicato non disponendo di un feedback di corrente...quindi questo è da vedere.

Perchè? L'accelerazione, come la velocità, non la ricavi direttamente dagli encoder... derivata seconda...

Ultimo punto: il controllo della temperatura dell'hotend non deve necessariamente passare dai PID. Repetier implementa un algoritmo alternativo chiamato Dead-time Control. Mi sembra piuttosto intelligente, di sicuro funziona bene! In pratica, da quanto ho capito, "impara", attraverso interpolazione dei dati, come si comporta l'hotend e si comporta di conseguenza.

Quote
lexon
Come il Mago per il firmware tu ne sai di hw, quindi perché non usare quello che hanno bene o male tutti (arduino) e migliorarlo?
Il Mago lo sta facendo con il firmware, tu potresti creare uno shield per arduino "attivo" e quindi sfruttare la logica di calcolo già implementata e consolidata.
Forse basta solo delocalizzare i pololu e far arrivare alla scheda per i DC solo i segnali di step e dir (che potrebbe riceverli a treno e gestirsi un buffer di dati)?

Il controllo per i motori DC è leggermente diverso, non si tratta di segnali step/dir ma di ricevere due segnali in quadratura di fase generati dagli encoder e ricavare da quelli le opportune misurazioni. Inoltre, il controllo va tarato opportunamente, quindi per la diffusione "su larga scala" andrebbe implementato un algoritmo di calibrazione ad hoc.
Tutto ciò comunque è sicuramente fattibile con arduino, però a fronte di un costo quasi doppio. La ST può interfacciarsi direttamente con gli encoder senza passare per dei contatori (i Timer on board li leggono direttamente senza sottrarre risorse alla CPU), mentre per Arduino (che già di suo costa il doppio) servirebbero ricevitori e contatori dedicati (minimo altri 20/30 euro, tra spedizioni e tutto il resto...); l'alternativa sarebbe una gestione basata su interrupt, ma fatta per 4/5 motori consumerebbe troppe risorse. Oltretutto (devo essere sincero) mi ritrovavo la ST, quindi mi faceva piacere vedere di ricavarne qualcosa di utile prima di pensare ad altri microcontrollori (fermo restando che, alle brutte, l'alternativa Arduino è sempre valida)
In più, penso sarebbe ora di portare questi firmware su altre piattaforme per avere un po' più di scelta (fatto il controllo di basso livello dei motori, contavo di ricalcare qualcuno dei firmware stra-collaudati che già si trovano per Arduino).

A riguardo:
[www.youtube.com]

Quote
enricodare
A Trieste, al Makerfaire,
un tizio (se trovassi la foto!!!!) aveva assemblato una stampante con parti (motore, encoder, conghie e struttura) ri stampanti vecchie con motori dc.
Utilizzave encoder per motori dc che avevano il formato pololu e una ramps come controller.

All'inizio avevo avuto un'idea simile (il primo telaio era fatto di legno e materiali riciclati), però poi farlo in alluminio mi è sembrato più "pulito". Ho la fortuna di poterlo rimediare gratis, quindi alla fine per il telaio mi sono arrangiato diversamente
Comunque, una volta sviluppato il controllo per i motori DC, potrebbe essere molto semplice assemblare una macchina sfruttando i carrelli delle testine delle stampanti. Ne esiste anche una fatta con dei lettori CD/floppy:
[www.instructables.com]

Quote
Qbert25
Si, progetto interessante, anche se non ho ben capito il vantaggio dei motori DC rispetto ai supercollaudati stepper... ma sono sicuro che ci sia, dal momento che qualcuno li usa

Certo creare un nuovo firmware da zero... è un peccato, visto l'enorme lavoro che c'è stato dietro a quelli esistenti e le continue migliorie, come la gestione di estrusori/hotend muiltipli e l'auto-level.

Un'altra cosa che non ho capito è la seguente:

Quote
ApBrandy

ApBrandy
Il controllo di accelerazione andrebbe fatto con un controllo di coppia, ma questo diventa più complicato non disponendo di un feedback di corrente...quindi questo è da vedere.

Perchè? L'accelerazione, come la velocità, non la ricavi direttamente dagli encoder... derivata seconda...

Ultimo punto: il controllo della temperatura dell'hotend non deve necessariamente passare dai PID. Repetier implementa un algoritmo alternativo chiamato Dead-time Control. Mi sembra piuttosto intelligente, di sicuro funziona bene! In pratica, da quanto ho capito, "impara", attraverso interpolazione dei dati, come si comporta l'hotend e si comporta di conseguenza.

I DC sono più veloci, più potenti, più precisi, più silenziosi. E si trovano molto più facilmente nelle stampanti, soprattutto, già forniti di sensoristica dedicata (il riciclo è sempre cosa buona...).
Per quanto riguarda il firmware, come dicevo conto di riutilizzarne qualcuno già scritto. Il mio scopo è soprattutto quello di realizzare delle elettroniche a basso costo, 150 euro per un controller e qualche motore sono veramente troppi.

Per quanto riguarda l'accelerazione, dovresti ottenerla come derivata numerica a partire da una derivata numerica (già la velocità viene calcolata così), quindi la misura diventa sporca e imprecisa, oltre a consumare risorse a livello di CPU. Generalmente, in letteratura, il controllo di coppia è basato su un feedback di corrente che io sappia (corrente e coppia sono proporzionali nei motori DC). Comunque alla peggio anche la soluzione che dici tu è possibile, ma probabilmente non è necessaria (un doppio loop velocità - posizione dovrebbe essere più che sufficiente per i nostri scopi).

Per la hotend, credo basti e avanzi un relè con banda sufficientemente stretta, ma dovrò fare qualche esperimento a riguardo

EDIT: dimenticavo, i DC eliminano anche il problema della scattosità alle basse velocità


Detto tutto ciò, ovviamente chiunque volesse partecipare (soprattutto per la scrittura del codice, è un lavoro lungo e noioso... ) è più che ben accetto.

Salut

Edited 2 time(s). Last edit at 12/09/2014 08:34AM by ApBrandy.

Cmq grazie dei chiarimenti. Hai per caso materiale in giro per approfondire (web, tesi etc)?


Ciao

PS: è un po che seguo questo progetto [makeatronics.blogspot.it] magari può interessare anche ad altri.

---

Prusa i3 R2 + The Shell - Saintsmart Ramps 1.4 - Mega2560 R3 - Driver A4988 - Firmware MarlinKimbra
Mini Kossel - Alligator - Firmware MarlinKimbra4due

Quote
lexon
Cmq grazie dei chiarimenti. Hai per caso materiale in giro per approfondire (web, tesi etc)?


Ciao

PS: è un po che seguo questo progetto [makeatronics.blogspot.it] magari può interessare anche ad altri.

Le delta hanno un loro fascino...prima o poi dovrò farne una
Per ora ho adottato una struttura tipo Makerbot.

Per quanto riguarda gli approfondimenti, in giro si trova molto, ma se hai qualche curiosità specifica chiedi pure (se posso ti rispondo direttamente io altrimenti ti rimando da qualche parte che può esserti utile )

Bravo, ottime considerazioni! Mi hai fatto venire voglia di compramela una di queste schede... anche se non so ancora cosa farci. Ho visto che la usano su droni e multicotteri, sicuramente per via del giroscopio e bussola integrati.

Scherzo, a dire il vero mi piacerebbe seguirti nella sperimentazione dei motori DC. Tienici aggiornati, mi raccomando!

Edited 2 time(s). Last edit at 12/09/2014 09:13AM by Qbert25.

Sì, è molto usata per droni DIY (avere un giroscopio e un accelerometro -oltre che una bussola- già montati on board è un bel vantaggio )
Anche la cugina F4 pare ottima (sempre disponibile a un prezzo irrisorio).

Ovviamente, qualora dovessi riuscire a cavarne qualcosa ve lo farò sapere per il momento sto cercando di ottenere una comunicazione seriale stabile e funzionante via terminale tra PC e scheda (sembra essere più difficile del previsto in compenso, la gestione delle periferiche dovrebbe essere una passeggiata)

[EDIT] Comunque mi è già capitato di usare un controllo di questo tipo su piattaforma Mbed (sempre un ARM Cortex) per un rover omnidirezionale (tesi di laurea triennale...)
Se trovo i video magari li carico

[riEDIT] F**K, era un bug nell'IDE x] pare risolto, ora posso finalmente vedere se questi encoder vengono letti...spero di potervi dare notizie a breve

Edited 2 time(s). Last edit at 12/09/2014 10:05AM by ApBrandy.