Algoritmo della linea di Bresenham su matrice per Arduino

[alberto863]

Ciao, da qualche parte ho letto (giuro che non riesco più a trovare dove) che il futuro computazionale nell'interpretare il g-code passerà per una pre-elaborazione del percorso e dell'accellerazione/decelerazione dei motori su matrice, per poi passare al controller (nel mio caso vuole essere arduino) la sola matrice pre-elaborata.

Arduino, a quel punto non dovrebbe più computare nulla (come invece adesso avviene con GRBL ad esempio), ma si limiterebbe ad eseguire singoli step con singole pause in microsecondi pre-elaborate e semplicemente lette da matrice; tutto ciò perchè GRBL non prevede un feed-back di encoder rotativi che invece a mè interesserebbe introdurre.

Qualche idea in merito? Qualcuno ci ha già provato?

Alberto

[Fiveaxis]

OT
non ci ho capito un tubo ...Adoro questo forum perchè è pieno zeppo di persone davvero preparate!!!....altro che hobbysti!!!!...
Complimentoni
Fine OT

[walgri]

@Alberto: sarebbe interessante leggere quel documento

Ad ogni modo la stragrande maggioranza dei controlli a cui possono accedere gli hobbisti compie in effetti una preelaborazione dei percorsi sul pc, e comunica alla periferica dei comandi semplificati, già digeriti insomma, in cui sono presenti spostamenti/velocità/accelerazioni. Si può trovare traccia di questo ad esempio nella documentazione della KFlop, o in certi documenti "storici" della Colibri.

Sul controllo poi vengono eseguiti effettivamente i calcoli (non solo di Bresenham) e da lì generati step/dir (nel caso di sistemi step/dir).

Ho dubbi che effettivamente si voglia passare direttamente a trasmettere "la matrice" come dici, perchè sarebbe l'esatto equivalente di tornare ad utilizzare la parallela. E la potenza di calcolo ora disponibile a costo simbolico nelle varie schede sarebbe semplicemente sprecata, si tornerebbe alle questioni di latenza tipici dei pc, esacerbate poi dal fatto che in questo momento l'hardware di comunicazione più comune è una linea seriale.

[alberto863]

Ciao walgri, io la matrice la vorrei spedire ad arduino prima che inizino a muoversi i motori e non in real-time. Probabile nasca un problema di memoria e si debba passare ad arduino DUE. Ad ogni modo sto tentando di decifrare il nuovo algoritmo di GRBL dal nome AMASS, ma non è semplice.

Questo è quello che dicono ad oggi i guru di GRBL:
NEW Super Smooth Stepper Algorithm: Complete overhaul of the handling of the stepper driver to simplify and reduce task time per ISR tick. Much smoother operation with the new Adaptive Multi-Axis Step Smoothing (AMASS) algorithm which does what its name implies (see stepper.c source for details). Users should immediately see significant improvements in how their machines move and overall performance!

Alberto

[Garkoll]

Si la logica è quella di caricare sul controller non il file con il gcode ma direttamente il "vero" percorso utensile.
Questo prefatto e non in realtime.
Può avere una utilità solo se questo viene "controllato" e verificato con una matrice di parametri della cnc stessa, cosa non proprio semplice da realizzare così da capire se eventualemente possono esserci punti critici.

Altrimenti almeno che tu non gestisca 5 assi in continuo con un percorso da ore e ore di lavoro vedo veramente dura mettere in crisi un processore come quello di arduino uno o relativi concorrenti

Però sono sempre passi avanti importanti, anche perché così potresti impegnare il controller in altri operazioni gravose e non solo in quella.
Mi sembra che le lavorazioni ad alta velocità e il controllo dell'errore di posizionamento siano sempre più la strada innovativa e in quel caso capisco l'ottimizzazione delle risorse "sprecate" per fare calcoli che ad oggi posso già fare in altra sede (vedi cam).

[Innaig]

Sono anni che su cnc professionali si usa quel sistema.
Tradurlo su arduino però la vedo dura.
Quello che una volta veniva chiamato "errore di inseguimento" non esiste piu sui nuovi cnc ma viene sostituito da questa famosa "stringa" (in realtà la cosa è molto piu complessa).
In pratica viene preso il GCODE, trasformato in matematica, calcolato percorso, accelerazioni,decelerazioni,velocità media, ecc. e poi passato agli azionamenti.
E qui casca l' asino....per far questo, l' azionamento deve avere un firmware adeguato (ormai sono a tutti gli effetti dei veri computer) e di solito scritto dallo stesso produttore del CNC (es Siemens, Fidia, Heidenain, ecc).
La matrice puoi calcolarla ma poi come la gestiscono gli assi?
passare singoli step e pause vale dire passare direttamente il gcode.
Fattibilmente si potrebbe usare un arduino per computare e un arduino per ogni asse.
Sul primo carichi il gestionale per la matrice, sugli altri il firmware di interpretazione.
Occhio che i calcoli sono pesantissimi!!!

Saluti

[walgri]

@alberto863: Purtroppo ora ho troppa roba sul fuoco e non posso studiare l'Amass. E sì che mi piacerebbe.

Tornando a noi e alla matrice e Bresenham: staresti trasformando una cnc in una stampante ad impatto. Ma quelle lavoravano per strisciate orizzontali, non seguivano linee oblique e curve.

Puoi mandare un flusso di step e dir, ma torno a dire è come tornare alla parallela. Oltre al fatto che in tal caso comunque NON staresti mandando affatto la matrice.

E anche se lo facessi, Bresenham deve a quel punto essere implementato sul PC. E l'Arduino finirebbe dallo psicologo per noia

Bresenham su Arduino serve proprio a trasformare in stepdir i comandi di spostamento generati dall'interprete gcode e dal pianificatore delle traiettorie.

[alberto863]

Che casino

[Pedro]

tanto per leggere qualcosa in merito, ma proprio come preliminary

https://www.marginallyclever.com/blog/2 ... terpreter/

è una tecnica vecchia, e in effetti la cosa viene accennata nella pagina linkata, e anche molto ma molto intuitiva, nulla di complesso insomma qualsiasi vettore si rappresenta come modulo e coefficiente angolare dopotutto, diciamo modulo, direzione e verso. Ci sono librerie belle che fatte comunque per interpretare i gcode su diverse piattaforme; ho messo il link giusto per vedere in somme linee come si fa ma ripeto ci sono librerie belle che ottimizzate, oggi non come anni fa che manco esisteva arduino

una piccolissima chiosa: un tempo, quando i computer non erano veloci e le schede grafiche erano...quello che erano, tty quasi insomma, esistevano i monitor vettoriali per fare rappresentazioni grafiche, erano per lo più analogici e in effetti ricevevano solo i vertici, mitico il 4010 Tektronix. La memorizzazione avveniva sui "fosfori", bei tempi. Chiuso OT

[alberto863]

Bene pedro, hai fatto chiarezza, io non trovavo le parole giuste e dopo 5 minuti davanti ad un post in bianco, ho saputo solo scrivere "che casino".

Però non mi spiego come mai i guru di GRBL non applichino una tecnica simile e nemmeno perchè non vanno contemporaneamente su più schede arduino come suggeriva l'utente innaig, dato che un clone costa pochi euro.

Alberto

[Pedro]

del perchè non lo facciano chiaramente non lo so, del perchè non usino un controller con Arduino per ogni asse anche, forse perchè chi lavora con Arduino tende sempre ad essere minimalista. Certo è che si può strizzare parecchio ma ha pur sempre i suoi limiti, può fare abbastanza, e ho avuto modo di toccare con mano su stampanti 3d, anche bene ma ha anche lui i suoi limiti, ovvio. Però considera che molti dei percorsi in cnc, diciamo quasi tutti, non sono lineari ma curvilinei, quindi trovare algoritmi che soddisfino le esigenze sia delle traiettorie lineari che curvilinee è essenziale. In più, ci si mette anche quello, la velocità e la relativa accelerazione complica ancora di più le cose per cui magari si opta per altre soluzioni

[turbina]

L'architettura "un controller per asse" è semplicemente assurda, il motion controller, la mente, deve essere una sola , dopo..ogni singolo asse può effettuare per conto suo il controllo di posizione ad anello chiuso gestendo il relativo errore di posizione , questo viene sempre più delegato all'azionamento, è tutto dentro l'azionamento che non è più un semplice servo amplificatore e al massimo un loop chiuso su una tachimetrica, come negli anni 80-90 , oggi l'azionamento comprende il controllo di posizione tranne encoder, che fa anche da tachimetrica, monta persino un processore a 8/16 bit e una CPLD oppure un processore a 32bit, nel mio azionamento CNC_ULTIMATE V2 monto ben 2 microcontrollori a 8 bit.

Arduino UNO o mega2560, può fare molto come controller 3 o 4 assi senza grossi problemi, con bresenham, ma se si vuole il massimo bisogna andare su arduino DUE che monta un ARM3 a 32bit a 84Mhz e ha un coprocessore a virgola mobile, ESSENZIALE per fare i calcoli a 32bit come minimo 10 volte più veloce di arduino UNO e mega2560

un progetto Motion controller con Arduino DUE esiste , si chiama tinyG2 , a dire il vero un pò fermo.... https://github.com/synthetos/g2/wiki
Anch'io ho in serbo di utilizzare arduino DUE per la versione futura utilizzando la shield PCAM13 http://www.dmxpassion.altervista.org/pg011.html progettata apposta a 3.3V e 5V per essere inserita indifferentemente su mega2560 o DUE.

[doctor_t]

questo interessantissimo post si è fermato a febbraio!

ci sono novità a riguardo?

personalmente è da qualche annetto che mi diverto ad utilizzare arduino in diverse applicazioni e sto aspettando che mi arrivi arduino 2 nelle prossime settimane.

mi ha molto interessato il discorso di inviare direttamente il percorso utensile ad arduino senza fargli interpretare il Gcode ma praticamente è quello che avviene con le stampanti 3d?
si inserisce la schedina con i vari codici e poi ci pensa il firmware caricato su arduino o chi per esso ad eseguire il percorso inserito nel file?

altro discorso è quello di poter utilizzare Arduino con programmi tipo Mach3 che ti permettono di far partire il codice in qualuque punto dell area di lavoro della CNC mentre per le stampanti hai la necessità degli end stop e non si ha la possibilità di intervenire durante l esecuzione del percorso

[Pedro]

il percorso, come lo chiami tu, è proprio il codice "G", un po' specializzato per le stampanti e con comandi speciali ma quello è

per le stampanti 3d e posizione: lo "zero" macchina mica è un obbligo, si toglie la macro che lo fa, metti dove vuoi e azzeri e parti come in una cnc qualsiasi, ed in effetti segue la stessa logica, magari nel firmware casomai fosse settato si toglie il passo che non fa accettare le coordinate negative; parliamo ovviamente delle stampanti ortogonali in quanto questo già avviene per le delta ma sto andando troppo OT

[alberto863]

ci sono novità a riguardo?

Si, ho lavorato e parecchio sull'algoritmo del cerchio Midpoint, per farlo funzionare in senso orario (CW), quest'algoritmo lavora sui numeri interi con una logica matematica e non trigonometrica.

Inoltre con questo algoritmo, non lavorando in virgola mobile, si potrebbe evitare la "predigestione" del gcode.

Alberto.