Arduino e devCnc Foam
 

Stavo pensando ad integrare GRBL + Arduino al mio devCnc Foam, che ora supporta solo Theremino, ma e' gia' strutturato in modo da poter interfacciarsi ad altri sistemi.

La domanda: c'e' qualche esperto di GRBL su Arduino che ha voglia di collaborare?

Uno per volta, non spingete... :P

Vabbe', vista la mancanza di adesioni credo partiro' da solo. :P

La mia idea e' di usare un tipico kit minimale per stampanti 3d composto da

- RAMPS 1.4 + 5x driver DRV8825 + Arduino MEGA 2560 R3 ATmega2560 CH340
-5 motori nema 17

e trasformalo per la taglia polistirolo riscrivendo lo sketch per arduino in base alle mie esigenze.

Partiro' con qualcosa di semplice con 4 assi lineari interpolati, per poi eventualmente aggiungere controllo temperatura filo, quinto asse rotante (per il mio devFoam 3D che sto sviluppando) e gestione fine corsa.
Il tutto sara' pilotato via Usb dal mio devCnc Foam, con l'ambizione di rendere trasparente all'utente la selezione dell'attuale Theremino o di Arduino.
In pratica voglio mantenere la stessa interfaccia con visualizzazione 3D in tempo reale, sulla base della posizione attuale che da arduino comunichero' al pc.
Il protocollo di comunicazione sara' probabilmente proprietario, per ottimizzare i tempi di elaborazione dei dati in input/output da parte di Arduino.
I pin diretti ai driver stepper saranno comandati tramite registri ed interrupt per permettere la massima fluidita' e velocita' dei motori.

Un progetto forse ambizioso (considerando che non ho mai scritto una riga di codice per arduino), ma che poi permetterebbe di avere un qualcosa di praticamente plug&play, semplicemente acquistando un analogo economico e supertestato kit hardware ed installando il mio software.

Altre due parole sul devFoam 3D che sto sviluppando: alla attuale gestione di tagli rastremati di devFoam Pro aggiungera' il quinto asse rotante, di tipo tavola o tornio.
Questo permettera' il taglio di veri oggetti 3D partendo da file STL o da apposite forme di roto-twist generabili direttamente all'interno del programma.
Questi oggetti di vario tipo saranno 'impilabili' per poter fare con un solo taglio oggetti complessi, tipo un'orrenda colonna con treppiede e mostruosa testa di cavallo sopra. :-)

Spero di aver incuriosito qualcuno.
Vi terro' aggiornati sullo sviluppo del progetto, anche se i tempi non saranno brevissimi in quando devo incastrare questo nel tempo libero rimanente dai miei altri pastrocchi che ho in corso.

Se qualcuno vede qualche incongruenza nel mio progetto parli adesso o taccia per sempre :lol:

Ecco qualche foto del mio banco prova supertecnologico per Arduino Mega + Ramps.
Non ve ne frega niente, ma come promesso vi tengo aggiornati :P

Sto riscrivendo lo sketch per dialogare col mio devCnc Foam e sono arrivato a questo punto:

- gestione di 5 assi indipendenti ed interpolati linearmente. I primi 4 saranno per i due carrelli, ed il quinto per l'asse rotante. Sara' possibile usarli tutti e 5 nello stesso comando, in quanto sono tutti interconnessi nella interpolazione interna.

- invio impulsi stepper tramite interrupt con scrittura a basso livello, per sfruttare al massimo il microprocessore

- gestione dei pin di uscita/ingresso da software. In questo modo non sara' necessario dover ricompilare e ricaricare lo sketch su arduino in caso di modifica ai collegamenti o uso di una scheda diversa da Ramp. Questa e' stata la cosa piu' difficile da ottenere, perche' tutti gli altri esempi trovati (Grbl, Marlin etc) per avere la massima velocita' di accesso ai registri impostano le porte di uscita a livello di codice, e quindi restano fissi. Ho dovuto usare qualche vecchio trucco per scrivere su registri modificabili a runtime. Mi piace l'idea di poter considerare Arduino una scatola nera a cui mandare e da cui ricevere semplicemente comandi, senza dover modificarne il codice interno, ricompilarlo e ricaricarlo. In questo modo bastera' definire i pin in devCnc Foam dal menu Setting, come faccio adesso per Theremino Usb.

Ora mi metto al lavoro per gestire il filo caldo. Ramps dispone gia' di un'uscita PWM max 24 volt x 11A, quella usata per il riscaldamento del piatto, quindi inizio le prove con quella.
Poi la gestione dei fine corsa, che vedro' di fare a livello di firmware ed indipendenti per ogni asse.
Infine l'invio della posizione corrente a devCnc Foam, che faro' in maniera diversa dalla attuale che usa troppa banda sulla porta Usb.

Neanche male, pensavo peggio.

a me frega e seguo

per il resto, come fosse arabo :lol:

Beh io provoco, sperando di interessare qualcuno... :)

ciao,

molto interessante invece .

seguo anch'io ma non sono in grado di intervenire e tanto meno di aiutare
però è giusto sostenere chi lavora :wink:

Idem, seguo ;) ma li mi fermo
Se un giorno magari farò upgrade alla mm2001, so già che scegliere ;)
Ciao


Inviato dal mio iPad utilizzando Tapatalk

Interessante la cosa sopratutto perche ormai HW per gestire 5 assi
nato per comando stampanti 3D ha avuto una diffusione cosi massiccia
che costa veramente poco.

Io posso solo giocare nella parte HW di programazzione sono un ciuccio :(

Sulle Stampanti 3D come FW uso MK il programmatore è Italiano e molto disponibile
MarlinKimbra & MK4duo se il tuo ostacolo è quello prova a chiedere magari
ti aiuta già ha fatto qualcosa per poter gestire un laser TTL al posto del estrusore
per trasformare la stampante 3D in Incisore non si sa mai che modifica il FW
anche per farla diventare TGA :wink:

Grazie ma lo sta gia' modificando io :)
Sto chiedendo consigli allo sviluppatore di Grbl perche' la parte critica deriva dal suo codice, insieme stiamo vedendo di ottimizzare la parte sotto interrupt per riuscire a gestire gli assi aggiuntivi nel breve tempo concesso dall'interrupt. Non e' un solo problema di aggiungere il codice che gestisce gli assi in piu', ma il difficile e' gestirli senza impiegare piu' cicli di clock di prima, altrimenti occorre abbassare la velocita' massima (che comunque in una TGA non e' critica). Sto provando una ottimizzazione del codice a basso livello, lavorando temporaneamente su 8 bit invece che 32 (cosa molto lenta sun un micro a 8 bit) ed integrando i risultati a 32 bit solo ogni 5 interrupt, un'asse per volta.
Oggi gli propongo la mia soluzione, magari la vorra' adottare anche sulla sua versione ufficiale.
Di Marlin c'e' di buono la possibilita' di definire i pin su piu' porte del microprocessore, cosa che Grbl non puo' fare. A questa cosa ho aggiunto la possibilita' di ridefinire i pin da software, senza dover ricompilare e ricaricare lo sketch

Da uno che ha fatto questi ottimi programmi possiamo aspettarci solo grandi
cose anche sul campo FW anche se non è per ora la tua specializzazione :wink:

Ma a quel Punto perche non vedere Arduino DUE
e lavorare direttamente a 32Bit ? I costi tra 8 e 32Bit oggi sono simili
Sopratutto il Clone tra Arduino Mega e Due è quasi lo stesso

Lo dico da profano di programmazione dato che noto che in molti anche
sulla stampa 3D Stanno migrando a sistemi 32Bit sopratutto nelle stampanti a Delta per via dei calcoli maggiori rispetto al sistema cartesiano non so se nella gestione TGA con gestione PWM e 5 Asse sia la stessa cosa ?

Per la parte taglio filo usando il PWM di elettroniche tipo la Ramps che sono nate per gestire il letto caldo un suggerimento ti basta interporre a valle un 600W o 800W Boost DC-DC Converter Power Supply Step-up
Module 12V 19v 24v 48v to 12-80V e inalzi cosi la tensione da 24 ti sconsiglio di non superare i 48V e il taglio filo va meglio :wink:

Beh io avevo iniziato 35 anni fa proprio col programmare in assembler direttamente sui microprocessori del tempo, quindi qualcosa so :-)
Facevo anche giochino elettronici per il commodore 64, tutti scritti in assembler.
E mi ero inventato un modulo eeterno per fare carica/scarica batterie al NiCd, con grafici di rendimento che venivano poi generati sul commodore.
Cosa non si faceva pur di non studiare Analisi 2... :P

I problemi di Arduino 2 sono:
- lavora a 3.3 volt, e quindi le schede attuali (ramps etc) non sono compatibili, ed anche i driver possono avere problemi. Ci sono schede apposite, ma hanno problemi, sono molto costose e di difficile reperimento. Avevo chiesto ad un produttore diu schede italiano se aveva voglia di lanciarsi nell'impresa di realizzarne una da vendere a poi poveri smanettoni, ma mi ha fatto capire che non ci vede il tornaconto.
- non ha una eeprom interna, quindi ad ogni accensione bisogna ricaricare tutti i parametri. Non una gran problema per la mia architettura collegata al pc, ma comunque un passo indietro
- le ottimizzazioni dei vari registri sono completamente differenti, quindi c'e' una marea di lavoro da fare/baciare/lettera/testamento. Quello che manca a me adesso e' il tempo in eccesso...

Quindi per ora vado su Arduino Mega ed Uno, sono molto piu' semplici da mettere in piedi in quanto basta inserire la shield specifica per gli stepper (ramps etc) e si lavora in 5 minuti. Con 30/40 euro si ha tutto, driver compresi, e non bisogna spostare un solo filo. Si incastra lo shield su arduino, ci connette l'alimentazione, si infilano gli spinotti a 4 poli dei motori (li vendono gia' cablati) e si e' pronti.
Resta solo magari da regolare la corrente dei driver, ma per esempio quelli che ho comprato io erano gia' pretarati su un valore ragionevole.
Se poi si brucia un driver (puo' succedere) con 2 euro passa la paura, basta sfilare quello rotto ed inserire quello nuovo.

Per ora lavori procedono bene, direi che anche la gestione del filo caldo e' fatta.
Per piccole potenze e' sufficiente usare l'uscita a 12/24 volt di Ramps, posta sotto Mosfet. Per potenze maggiori basta collegare un elevatore di corrente, come suggerito da saviothecnic o soluzioni similari.
E' anche possibile usare l'uscita come semplice On/Off per pilotare un relais che accenda spenga un normale dimmer manuale.

Ora sono alle prese con la gestione dei fine corsa, interessanti piu' che altro per dare la possibilita' alla macchina di effettuare un Homing preciso ed automatico.
In pratica l'Homing consisterebbe nel cercare la posizione di minima corsa di tutti i carrelli, e poi posizionarsi ad una distanza di sicurezza da questi.
Questa e' una cosa molto noiosa da fare manualmente, e spesso poco precisa.
Per il caso TGA la cosa e' un po' piu' complessa, perche' non e' una buona idea fare l'Homing su un solo carrello per volta, in quanto potrebbe portare la macchina a forzare il filo caldo ad alte angolazioni, poco gradite a sistemi con semplice molla di recupero tensione filo.

Azz non sapevo allora rispolverare questo tipo di programmazione ti ha riportato bambino :lol:

I drivers NO pero sicuramente i 3.3V rispetto al 5 da noie sui sensori ma quasi tutte le schede hanno il DC DC per gestire 3.3 5V

Si lo so le ho provate un po tutte le schede a 32Bit
alla fine la più affidabile è la Radds 1.5 ma un po tutte vanno anche la più economica Ramps FD o SmartRamps problemi più noti sono nella gestione del LCD o nella Sonda lettura letot caldo ma non credo tu Nel FW TGA userai LCD e il Sensore Temperatura Filo o Usi anche quello in caso sopratutto per il tutto grafico sarebbe una superFigata :D E anche il Feedback leggendo l temp Filo per gestire in modo automatico il PWM o magari un Autotune sul algorimo temp

Per la EEprom non è un problema tutte le elettroniche 32Bit la integrano ad esclusione della FD ma li con il modulo da 2€ si collega alla seconda Uscita I2C
ed il gioco è fatto :D

Si la gestione dei finecorsa è una bella cosa molto comoda ma va pensata per bene

Boh, certi driver danno un range da 3.0 a 5.0v volt per il segnale alto, con 3.3 volt ci si espone un po' a potenziali problemi, temo

Lo schermo LCD nella mia architettura ha poco senso credo, in quando il tutto e' governato dal pc. E siccome la potenza richiesta al pc (a differenza di Mach3) e' molto bassa, e' poi possibile usare un semplice tablet Windows (se ne trovano a meno di 100 euro) per creare una soluzione autonoma compatta e con schermo touch. In questo modo si puo' ad esempio usare un collegamento wireless per spedire i file di taglio dal pc di progettazione a quello di taglio, non sarebbe male.
E si ha il riscontro in 3D in tempo reale del processo di taglio (come faccio adesso per Theremino), con la possibilita' di testare prima il GCode in modo simulazione a motori fermi, ma con grafica 3D attiva.

Leggere la temperatura del filo all'interno del polistirolo (e' li' che serve) non e' molto semplice. E' possibile farlo misurando la variazione di resistenza del filo in tempo reale, ma non credo che il gioco valga la candela, diventa tutto molto complicato da fare e mettere a punto.

Per ora mi concentro sulle funzionalita' base, che sono secondo me proprio quelle che ho indicato.
Poi vedo di aggiungere la possibilita' di usare versioni di Arduino meno nobili del Mega (Arduino 1) o piu' nobili (Arduino 2), sempre pero' tenendo d'occhio la possibilita' di interfacciarli con schede stepper (tipo Ramps per intenderci) di facile reperibilita' e basso costo, in modo da avere comunque una soluzione che non richieda neanche l'uso dello stagnatore o di cablaggi esterni, ma sia tutta plug&play.

Se poi restera' tempo, aggiungero' la possibilita' di usare le schede in modo custom, per chi vuole usare pin diversi o anche magari per chi richieda la massima velocita', facendo in questo caso una mappatura pin preimpostata con pin della stessa classe (step/dir/enable) raggruppati sulla stessa porta di Arduino (quello che fa Grbl).
Questo non e' possibile su Ramps, che usa pin sparsi ovunque, seguendo la comodita' di sbroglio scheda e non delle delle prestazioni.
Col raggruppamento su porte singole modo si risparmiano molti cicli di clock del processore per l'invio finale del comando al registro (se ne usa 1 al posto di 10), e si possono spingere velocita' piu' elevate. Comunque gia' adesso arrivo parecchio in alto come velocita', e riesco a stallare i motori prima di stallare la scheda, il cui timer stepper viaggia a 30kHz (e ad ogni ciclo vengono pilotati tutti e 5 i motori).
Quindi piu' che altro sarebbe una questione di prestigio, o magari una necessita' di chi usera' questo sistema su macchine industriali ad alta velocita' (ed alto costo).

Un progetto avvincente, per quanto mi riguarda, anche perche' fino a 10 giorni fa per me Arduino era un re del medioevo :P

Bene bene

Giusto giusto ho li sul tavolo un arduino mega con appiccicata sopra una ramps che aspettano di essere smanettate... :fiu:

Domanda agli smanettatori di Arduino: se io distribuisco per fare prove uno sketch nella forma

NomeSketch.ino.with_bootloader.hex

puo' andare?
Altri suggerimenti?

Se ti riferisci al nome del file, non credo sia un problema e se lo fosse uno lo rinomina prima di caricarlo.

Se ti riferisci alla distribuzione di un esadecimale già compilato in modo da non pubblicare il sorgente, non è un problema manco quello. La procedura non è single click come caricare un .ino, ha delle piccole variazioni da una versione dell'IDE all'altra ma è abbastanza documentato in giro.

Alla lunga, lo skecth lo potrebbe caricare dritto per dritto DevCNC, sempre scopiazzando in giro.

Curiosità: Torna indietro qualcosa a GRBL?

In attesa di fare una procedura di caricamento manuale, credo provero' XLoader.
Ma forse mi ero spiegato male, piu' che altro la domanda era per sapere se era meglio fornire la versione compresa di bootloader, immagino di si' per evitare che poi Arduino ne resti priva, se ho capito bene.

Per quanto riguarda la tua domanda vedo che lo sviluppatore di Grbl ha come lo sviluppatore di Theremino un pulsante per le offerte/contributi, quindi ne approfittero' come gia' fatto a suo tempo per Theremino, appena avro' la conferma di avere qualcosa di utile ai miei scopi.

Di solito si manda .ino ma cosi ovviamente la gente puo vedere peronalizzare
e scopiazzare il tuo codice pero se riesci ad usare il bootloader di arduino è meglio
Alcuni Bootloader modificati non vanno su alcuni cloni e putroppo su arduino sono
piu i cloni che gli originali che girano sopratutto sul Mega che originale
escono con i contagoccie.

Come mai non vuoi usare il loader di arduino ottimizzazione o recupero memoria ?

Di solito è così quando utilizzi qualcosa di opensource.
É la filosofia sulla quale l'opensource si basa :uhm:

Perche' voglio offrire un'applicazione facile da usare anche per chi non sa nulla di Arduino, e quindi ho trovato in sti giorni il modo di caricare e personalizzare il programma su Arduino senza che l'utente debba scaricare l'IDE di Arduino ed imparare ad usarlo. Usando Avrdude con gli opportuni comandi e' possibile non solo caricare il file .hex ma anche verificare su quale porta e' presente Arduino, e quale versione. Credo che sequiro' questa strada usando appunto avrdude in background

Vero, ma io sviluppo prodotti commerciali, quindi seguo una diversa filosofia.
Percio' vedo di usare codice di esempio di lecito utilizzo, e poi mando donazioni agli sviluppatori.

Si lo so Stefano, io rispondevo a Savio, se uno è preoccupato che la gente lavori sul suo codice avendolo diffuso in .ino, è meglio che non lo diffonda per nulla.

Tu fai bene a fare come fai, ed è giusto che tu protegga il tuo lavoro se lo desideri.

Non dirlo a me sono un pieno sostenitore lo puoi notare dal progetto OpenArdBir
che abbiamo presentato l'anno scorso al Maker
Dove codice e schemi elettrici e PCB è tutto open e gratis per tutti :D
e ovviamente sono state citate le fondi d'ispirazione

Ho semplicemente spiegato cosa comporta dare in formato .ino
o precompilato hex e perche volesse usare un bootloader ansiche usare quello classico e quindi compilare suando la IDE classica d' arduino

Anche io sono un sosteninote delle donazioni e quando vedo che
una cosa vale le ho sempre fatte :wink:

Ovviamente lui sta facendo un prodotto commerciale ed e giusto spiegare che se lo dava in ino il codice viene visto modificato ecc ecc ma questo un programmatore come lui sicuramento lo sa :D

Io per ora se possibile non rilascio il codice per Arduino che sto scrivendo perche' la cosa mi e' stata anche commissionata da una ditta che vende TGA e vuole spostarsi su controller di tipo Arduino, e quindi sono alle prese con una versione custom anche per loro.
Poi vedo come va il mercato, ma ho gia' visto che per avere le prestazioni e caratteristiche che servono a me ho in pratica riscritto (e sto riscrivendo) quasi tutto il codice dello sketch originale. Che a sua volta si basa sul lavoro fatto da altri ricercatori, in termini di approccio matematico alle problematiche.
Comunque e' incredibile vedere quanta teoria da imparare ci sia dietro un 'semplice' sketch per pilotare motori stepper, se si vuole ottenere un prodotto dalle prestazioni 'ambiziose'.

A ok tutto chiaro non capivo il perche del bootloader non standard
Si allora è la strada giusta un bel comando dal tuo soft che programma arduino
senza ne dover saper usare ide e come simili :wink:

Gia', cosi' posso anche tener traccia ed aggiornare automaticamente lo sketch per le nuove versioni, cosa che puo' essere critica se ad esempio cambia il protocollo bidirezionale di scambio dati su Usb tra pc ed Arduino.
Questo protocollo lo sto riscrivendo, in quanto a me servono informazioni diverse e con frequenza maggiore, quindi sto vedendo di usare un protocollo binario e non di testo come usato dal Grbl originale.

Arduino e' un gran bel progetto, ma non alla portata di tutti. Diciamo che e' un altro hobby a parte, e chi gia' oltre al modellismo si e' reso conto che tagliare ali al cnc e' una branca nuova, probabilmente non vuole dover diventare anche un mezzo ingegnere di micro elettronica :-)

Piccolo aggiornamento.
Sto procedendo con l'integrazione di Arduino con devCnc Foam.

Cose fatte:
- gestione completa di rilevazione Arduino e caricamento sketch corretto
- invio comandi GCode da file nc ad Arduino
- rilevazione dati di ritorno con 3D grafico in sincronia con gli stepper

Da fare:
- gestione allarmi, stop etc
- gestione Jog
- gestione limiti hardware e software
- caricamento parametri di lavorazione

Direi che la parte piu' complessa e' fatta, a questo punto sono ottimista :rolleyes: