GRBLHAL e Teensy 4.X

[Junior73]

Si è proprio quella ricerca manuale della posizione con la giusta tolleranza con un occhio sul dro che ti fa perdere molto tempo prima di bloccare se necessario gli assi (su quelle frese non lo è dati gli attriti che hanno). Immagina fare 20-30-40 fori per ogni piastra ..
Se manualmente si riesce perchè non poterlo fare motorizzando gli assi?

Tutte queste macchine sono destinate al macero ed è un peccato perchè potrebbero ancora dire la loro in contesti meno produttivi come quelli hobbistici.
Vedere macchine usate da 20 quintali al costo di un giocattolo cinese da 20 kili .....insomma mi fa un certo effetto!!!
Saluti

[tecno67]

Beh! Direi che il problema del gioco random, è risolvibile effettuando la retroazione sulla riga ottica, ma se poi non blocco l'asse, questo si muove, sia sotto l'effetto dell'inerzia della tavola dopo il posizionamento, sia per effetto delle forze generate dalla lavorazione, considera anche semplicemente l'effetto di un utensile mono-tagliente o di un utensile a più taglienti non perfettamente affilato o di una fresa a candela che taglia una circonferenza di diametro maggiore del suo. Quindi direi che se si tratta di lavorazioni di foratura il problema lo puoi semplicemente risolvere con uno spostamento in rapido vicino alla quota, seguito da un posizionamento lento alla giusta posizione, seguito poi da un bloccaggio assi (da comandare magari con una uscita a relé per ogni asse), che a questo punto è la parte da automatizzare anche a livello meccanico. L'importante è che la distanza tra il punto di arrivo in rapido e l'effettivo punto di arrivo sia almeno superiore al doppio-triplo del massimo gioco meccanico, meglio ancora se tra il rapido ed posizionamento effettivo ci si piazza un ritardo di stabilizzazione. Un'altra accortezza è quella di effettuare i movimenti di fresatura solo su un'asse per volta con gli altri assi bloccati, che è poi quello che si fa sulle macchine tradizionali. Non credo invece che vi sia soluzione, se non sostituire le viti con viti più precise, per le lavorazioni oblique o per le interpolazioni curvilinee.
Prima di fare modifiche per bloccaggi ed altro direi che una prova da fare sarebbe quella di retroazionare sulle righe e poi fare sempre un doppio posizionamento prima in rapido, poi pausa e poi lo stesso posizionamento in lento. Io comunque rimango dell'idea che senza viti a ricircolo, bloccare gli assi non in movimento è necessario. Anche per macchine grandi.

[tecno67]

Riguardo i bloccaggi e ripensando alla scheda di Phil Barret. Mi pare abbia l'enable separato per ogni singolo asse, forse si potrebbe fare il tutto con questo segnale, l'Enable negato, lo si potrebbe utilizzare per fare lo sblocco dell'asse, per cui gli assi fermi sarebbero in automatico bloccati.
Ovviamente (non l'ho detto prima perché mi sembrava ovvio) il blocco dell'asse per funzionare deve essere effettuato direttamente sulla giuda e non sulla vite, ma in generale le macchine tradizionali hanno già un sistema di blocco degli assi di questo tipo, il problema è che in molte macchine questo è di tipo oleodinamico e quindi troppo lento sia nel bloccare che nello sbloccare.

[hellfire39]

Guarda che se togli l'enable, l'asse non è più in coppia e quindi è libero. Non Bloccato.

[tecno67]

Ovviamente (non l'ho detto prima perché mi sembrava ovvio) il blocco dell'asse per funzionare deve essere effettuato direttamente sulla giuda e non sulla vite

Probabilmente ti è sfuggita questa frase.

Se collego l'Enable negato con un blocco meccanico che agisce direttamente sulla tavola, l'asse è controllato dal motore durante il movimento. Quando il motore si arresta si blocca meccanicamente la tavola ed a questo punto va benissimo che il motore sia libero. E' il modo con cui hanno sempre lavorato le frese tradizionali. Poi nelle macchine più piccole e semplici questo bloccaggio era una semplice vite che premeva sulla guida con un tampone in bronzo interposto. Nelle macchine più grandi il sistema era lo stesso, ma il comando era oleodinamico.

[tecno67]

A proposito della retroazione della posizione sulla riga mi viene in mente invece un'altra considerazione. I driver passo-passo closed loop utilizzano l'informazione di posizione dell'asse motore anche per mettere in fase il campo rotante generato tramite il microstep con l'orientamento magnetico del rotore al fine di avere una corretta ottimizzazione dell'angolo di cedimento e quindi della coppia. In tale situazione (con un gioco meccanico tra la posizione della tavola e dell'asse motore) il sistema non potrebbe funzionare. Quindi credo che in tal caso dovremmo avere un loop di velocità direttamente sul motore a frequenza più elevata, mentre quello di posizione dovrebbe lavorare sul feedback di posizione della riga.
In effetti i Driver brushless che impiego per lavoro offrono appunto questa possibilità di separare il feed-back di velocità da quello di posizione e ricordo che parlando col programmatore che li aveva creati, mi disse che questa caratteristica era stata sviluppata per i sistemi di taglio al volo sui macchinari di tranciatura delle lamiere, dove a causa dell'inevitabile scivolamento sulle calandre di traino la velocità era regolata sul motore mentre la misura era fatta con ruote metriche a bassissima inerzia.

[hellfire39]

Stiamo parlando di ben altri ordini di grandezza.
Ben lontani dai sistemi "parsimoniosi" degli hobbisti.

[tecno67]

Certo! Stavo solo rispondendo agli ultimi post di Junior73 dove parla di vecchi macchinari pesanti cui vorrebbe evitare una fine ingloriosa con un re-impiego hobbystico.

[hellfire39]

Beh, spero non si offenda, ma penso che Junior73 appartenga alla categoria degli utenti molto risparmiosi...

Comunque, su movimenti di più assi interpolati il gioco è sempre una rogna. Il recupero del gioco all'inverione di un asse può portare a dinamiche molto spinte.
Non per nulla lavorano meglio con i brushless che hanno una dinamica molto migliore.

Soluzioni amatoriali non ne vedo.

[Junior73]

Ieri sera sono andato alla ricerca di prodotti commerciali (sempre a basso costo cinese.... ) e larga diffusione e non ho trovato prodotti tipo dro con righe ottiche che potevano interagire con motori o viceversa controlli offline con feedback di encoder esterni.
Ho visto che arduino ha varie cose già scritte per leggere encoder sino anche i calibri. Stasera vedo di aprire qualche programma per capire come funziona una riga ottica lineare e come la legge arduino .
Chiaramente ragazzi se me lo spiegate come ad un bambino di 3 anni .....

Procedendo a step (per rimanere in tema!!!):

-Come prima mossa GrblHal potrebbe integrare una sola lettura di encoder per 3 assi da assegnare all'interno dei 5-6 assi disponibili. Quindi accanto alle coordinate assolute e relative del programma di movimentazione ci sarebbe la sola visualizzazione della poszione data dalle righe ottiche.Ci potrebbero essere funzoni di segnalazione (semaforo rosso) di discrepanze precedentemente settate dall'utente a seconda delle sue necessità tra le posizioni ipotetiche e quelle diciamo reali rilevate.

- Una seconda fase potrebbe essere la parte "attiva" che potrebbe essere svolta dal programma o parzialmente anche da noi utenti a seconda del tipo di lavorazione. Non vorrei sbagliarmi ma Rosettacnc avevea un qualcosa in cui si poteva fermare la lavorazione , muovere manualmente gli assi e il programma si preoccupavva di aggiornare le coordinate di lavoro.

Per la prima ipotesi da proporre come idea a Tereio dal punto di vista delle risorse hardware ci sono problemi ? Non solo per il teensy4.1 ma anche per Arduino semplice. Voglio dire la gerazione dei percorsi e la continua lettura/visualizzazione di tre encoder può mettere in crisi i micro? Può bastare abbassare la velocità di lavoro? Bisogna scomporre i movimenti dove possibile in singoli assi?

@Hellfire

Oculati Hell razionalmente oculati Non mi offendo riconosco i miei limiti.

Saluti

[hellfire39]

Le righe ottiche (gli encoder in generale) posso resistuire la posizione assoluta oppure incrementale.
Per la posizione assoluta esistono delle interfacce seriali (ad es. EnDat) attrverso le quali l'encoder comunica continuamente la posizione al controllore.
Queste potrebbero essere più ostiche da implementare. Non ho mai cercato su internet se esistono soluzioni già implementate.

Gli encoder incrementali utilizzano due segnali digitali (in quadratura, ovvero sfasati di 90 gradi). Attraverso l'analisi dei fronti di salita e discesa di questi due segnali, il micro capisce se l'encoderha fatto un passo avanti o indietro. In questo caso la posizione è relativa.

Arduino non ha risorse hardware per rilevare automaticamente questi segnali e lo deve fare via SW. Questo lavoro è oneroso, e potrebbe ridurre le già scarse prestazioni in termini di impulsi/secondo raggiungibili. Soprattutto se la riga ottica ha una risoluzione molto alta (ad es. un impulso ogni micrometro).

Processori più performanti hanno delle risorse hardware dedicate al loro interno (chiamate QEI - quadrature encoder interface) che svolgono questo compito in modo indipendente dal processore, che deve limitarsi a leggere il valore quando vuole. In questo caso hai due vantaggi: processore più performante e nessuna penalizzazione nell'implementare la lettura.
Ma queste risorse sono scarse e non sono presenti in tutti i micro.

Di base, l'interfaccia QEI è dedicata a quei micro che nascono per controllare un motore, quindi, di solito, è presente un'unica interfaccia di questo tipo. A volte due. Finora non mi è mai capitato di vedere un micro con 3 interfacce QEI.

----------------------

Detto questo: se mi dovesse capitare un problema del genere, partirei con il farmi un DRO completamente separato da GRBL. Solo un visualizzatore esterno, da utilizzare manualmente. In questo caso la mia prima scelta sarebbe arduino + display esterno (ad es. i nextion che non portano via molte risorse ad arduino). Sempre verificando le frequenze massime delle righe ottiche.

Io ho già fatto una cosa del genere, ma ho utilizzato un micro differente (famiglia microchip pic ds33) e per una sola riga ottica, che utilizzo come comparatore centesimale (la riga ottica risolve 0,5 um ed ha una escursione di 12 mm).
In quel caso il micro ha un QEI hardware integrato.

[Junior73]

Grazie per il momento Hell stasera ti rispondo....volevo segnalare velocemente questo video completo di codice con un inglese "elementare" facile da capire.

https://www.youtube.com/watch?v=mFWOOtJPVAs

Saluti

[hellfire39]

Arduino ha la sua bella liberia encoder!
Io e Tecno67 ne abbiamo già "dibattuto" molto nel recente passato

La soluzione adottata funziona, ma è un po' troppo brutale per un sistema industriale. Se non vuoi avere rogne dovute ai distrurbi è meglio trovare righe ottiche che abbiano uscite differenziali e interporre un chip convertitore 422/TTL nel mezzo.
Cosa semplice, basta utilizzare un IC come il UA9637 che c'è anche in versione DIP.

[rosettacnc]

Come già detto: Un aereo da milioni di euro resta a terra per una rondella da 10 centesimi non valida...

In industria, quando i prodotti son di qualità, questa è una regola da non dimenticare mai.
Ma non ci si limita solo alle componenti hardware.

Anche il software, i tool di sviluppo come compilatori e linguaggi devono seguire questa regola, utilizzando strumenti che aderiscano i vari livelli SIL richiesti. Non basta un semplice compilatore C, ad esempio, ma questo deve essere a norma e validato, come i sistemi real-time da usare nelle schede e tutto il resto.

[rosettacnc]

Come già detto: Un aereo da milioni di euro resta a terra per una rondella da 10 centesimi non valida...

In industria, quando i prodotti son di qualità, questa è una regola da non dimenticare mai.
Ma non ci si limita solo alle componenti hardware.

Anche il software, i tool di sviluppo come compilatori e linguaggi devono seguire questa regola, utilizzando strumenti che aderiscano i vari livelli SIL richiesti. Non basta un semplice compilatore C, ad esempio, ma questo deve essere a norma e validato, come i sistemi real-time da usare nelle schede e tutto il resto.