Arduino e devCnc Foam

[devCad]

Originalmente inviato da saviothecnic

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

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

[saviothecnic]

Originalmente inviato da devCad

Grazie ma lo sta gia' modificando io

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

Originalmente inviato da devCad

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

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

[devCad]

Originalmente inviato da saviothecnic

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

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

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...

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.

[devCad]

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.

[saviothecnic]

Originalmente inviato da devCad

Beh io avevo iniziato 35 anni fa proprio col programmare in assembler direttamente sui microprocessori del tempo, quindi qualcosa so

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

Originalmente inviato da devCad

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.

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

Originalmente inviato da devCad

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...

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 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

Originalmente inviato da devCad

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

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

[devCad]

Originalmente inviato da saviothecnic

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

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

Originalmente inviato da saviothecnic

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 E anche il Feedback leggendo l temp Filo per gestire in modo automatico il PWM o magari un Autotune sul algorimo temp

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

[Mach .99]

Bene bene

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

[devCad]

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

NomeSketch.ino.with_bootloader.hex

puo' andare?
Altri suggerimenti?

[GentlemanRider]

Originalmente inviato da devCad

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?

[devCad]

Originalmente inviato da GentlemanRider

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.