GRBLHAL e Teensy 4.X

Sezione dedicata ai controlli seriali, usb e Ethernet
Per gli approfondimenti si rimanda ai subforum specifici.
Subforum:
CncDrive
PlanetCNC
RosettaCNC
Twintec
Rispondi
tecno67
Member
Member
Messaggi: 391
Iscritto il: lunedì 26 febbraio 2007, 14:25
Località: Prov. di Milano

Re: GRBLHAL e Teensy 4.X

Messaggio da tecno67 » mercoledì 2 dicembre 2020, 20:17

Direi di riportare la discussione nel giusto alveo.

Se quello che interessa è costruire una CNC da hobbysta ex-novo, concordo sicuramente con hellfire39 che coi costi che ci propone ormai il mercato dei componenti, ci si può benissimo accontentare di guide e viti a ricircolo cinesi e poi a seconda del budget optare per controllo open-source e stepper open loop, oppure controlli tipo planet-cnc, colibrì, rosetta ecc. e stepper closed-loop o brushless. Già così se si fa bene la meccanica si può stare nei 5/100 teorici e nel 1/10 effettivo. Se si vuole salire sopra queste precisioni occorrono una preparazione teorica ed attrezzature che non sono più quelle del Plug'n Play.

Esiste poi il segmento del tentativo di revamping di vecchi macchinari o delle applicazioni non CNC vero e proprio e qui ogni situazione è un caso a se con esigenze a sé.
Junior73 ha avuto sicuramente il merito di aver proposto/sollevato la richiesta di effettuare il controllo diretto della tavola che impone la necessità di una soluzione closed-loop diversa dal semplice driver closed-loop collegato con un generatore di profili più o meno evoluto.
Sta poi agli sviluppatori come dice lo stesso Junior verificare se è fattibile sia come risorse HW che come gestibilità dell'utente finale delle eventuali fasi di taratura, che come numeri commerciali se si tratta di sviluppatori che non lavorano in ambito open source.

Ricordo però che inverter con procedure di autotunig e rilievo automatico dei parametri motore, fino ad una decina d'anni fa o poco più erano il sogno del costruttore medio di macchinari, oggi sono la norma ed anche un non elettrico con un minimo di passione ed un buon manuale avvia un Inverter. Cosa che spesso in elettricista civile di quindici anni fa non sapeva fare in molti casi.

Il discorso di Rosetta (chi più spende meno spende) ha del vero se la passione è effettivamente radicata e duratura, non lo è per nulla in quei casi in cui il CNC è il pallino del momento. In questo caso è sicuramente meglio spendere poco inizialmente magari cercando di riciclare, ma se poi ci si accorge che la passione c'è per davvero bisogna passare alla filosofia da lui descritta e non abbandonarla più già col secondo tentativo.
Io ne sono l'esempio, nonostante tutto felice, ma perché per me il divertimento è costruirla una CNC, non usarla. Un po come per il modellista che prima ancora di finire un modello, sta già pensando al successivo. :D :D Non so se ci siamo capiti! :D

tecno67
Member
Member
Messaggi: 391
Iscritto il: lunedì 26 febbraio 2007, 14:25
Località: Prov. di Milano

Re: GRBLHAL e Teensy 4.X

Messaggio da tecno67 » mercoledì 2 dicembre 2020, 20:33

Comunque ricordo che il discorso retroazione diretta sulle righe fu proposto e forse anche realizzato da alcuni utenti anche di ottimo livello più di una decina di anni orsono forse anche quindici, poi scomparve dal forum... O forse scomparvero gli stessi utenti dal forum. Non mi ricordo.
Non sono riuscito a ritrovare i post esatti. Ci devo dedicare un po di tempo col 'cerca'. In seguito non se ne parlò più. Non so dire se perché un po velleitario, o perché non alla portata dei più (Molti plug'n Play come dice hellfire) o per l'eccessivo costo che avevano allora le righe. Se qualcuno se ne ricorda come me, o si sente chiamato in causa, sarebbe bello che tornasse a farsi vivo e raccontarci come era poi finita la cosa.

rosettacnc
Member
Member
Messaggi: 209
Iscritto il: venerdì 6 settembre 2019, 8:18
Località: Vicenza

Re: GRBLHAL e Teensy 4.X

Messaggio da rosettacnc » mercoledì 2 dicembre 2020, 21:26

Quando si entra nel mondo del controllo assi, soprattutto nei sistemi ad anello chiuso (controllore - asse) è indispensabile conoscere molto bene lo strumento che si utilizza, ovvero la CPU/MCU/MPU/DSP/SOM/etc, e il sistema contesto in cui è applicato e lavorare profondamente con le caratteristiche più low level accessibili.

I tempi ti reazione anello chiuso tra driver e motore non sono comparabili con quelli possibili nel sistema di controllo che di norma viaggia sull'ordine del millisecondo e ben più lento di quanto avviene nel driver.

Spesso questo si risolve aggiungendo una FPGA al controllore per sbrigare a tempi deterministici e ultra veloci le operazioni di loop con i vari algoritmi (proporzionale, integrale, derivativo, feed forward, etc, etc).

L'importante è una gestione realtime degli interrupt-time a pressoché zero latenza o pochi bit encoder introdotti dal jit e si controlla a chiacchere.

Con una FPGA questo viene facile con un arm series M "anche no"...

Bisogna sempre tenere a mente che i sistemi di auto-tuning del costruttore di driver A che muovono motori del costruttore A "sanno nell'intimo" come il motore A si comporta con e senza carico e di norma non si limitano ad un semplice PID+FF ma negli anni son evoluti aggiungendo tante di quelle diavolerie in realtime che hai voglia a metterle dentro ad un Arduino, anche conoscendole,

Il driver oltre alla posizione del resolver ha anche tutte le informazioni su tensione, assorbimento, etc... che processa di norma con una DSP o l'accoppiata DSP/FPGA nell'ordine di poche centinaia di nanosecondi se non più velocemente.

Junior73
God
God
Messaggi: 3614
Iscritto il: lunedì 14 aprile 2014, 10:36
Località: Perugia

Re: GRBLHAL e Teensy 4.X

Messaggio da Junior73 » mercoledì 2 dicembre 2020, 22:19

Ciao Silverio,
premetto che non ho capito granchè di quello che hai appena scritto (mia ignoranza sull'argomento) ma volevo chiederti se quindi escludi che un Arduino Uno fino ad arrivare al teensy 4.1 possano ad esempio leggere una singola riga ottica da 0,005mm di precisione ad una velocità di movimentazione sotto ad 1 metro al minuto (rapidi compresi). Ho preso questa velocità perchè di solito è il massimo o quasi che si usa per i metalli .


Inoltre se come avevo accennato(forse sbagliando) che in Rosettacnc si può fermare la lavorazione, muovere uno o più assi e riprenderla , ed è il software che ricalcola i movimenti successivi.

Se ad esempio devo fare un foro a x10 ma mi accorgo tramite un controllo "ottico" di stare realmente a X9,9 posso fermare (tipo pausa) la macchina spostarmi manualmente di 1 decimo e poi continuare con il foro successivo che magari sta a x20 sapendo che il programma avrà aggiornato l'origine per le successive lavorazioni sullo stesso pezzo ?

@Tecno67

O.k proviamo a formulare un suggerimento per Tereio in italiano per poi tradurlo in un inglese decente? Magari interviene anche Phil Barrett.

Da quel poco che ho capito da Silverio credo che possiamo escludere con controllo, rilevazione delle differenze e correzione in tempo reale.
Non so se sia possibile solo un controllo di istruzioni semplici su singoli assi (gcode modificato appositamente) dove il programma di movimentazione esegue una qualche azione prestabilità dall'utente in caso di differenze .
Sapere comunque di essere al centro di un foro prima di farlo o avere un sistema che lo "segnala" può essere comunque utile nell'ottica di migliorare la precisione delle nostre cnc amatoriali quando serve. Se il primo lo fai sbagliato gli altri difficilmente saranno in posizione (lavoro buttato).

Saluti

Avatar utente
hellfire39
God
God
Messaggi: 3413
Iscritto il: domenica 16 dicembre 2012, 9:04
Località: AN

Re: GRBLHAL e Teensy 4.X

Messaggio da hellfire39 » mercoledì 2 dicembre 2020, 23:29

Io continuo a pensare che sia tutto un po' troppo vago.
Cos'è un foro?
La lavorazione è un listato di g-code: quando si deve fermare il SW? In qualsiasi istante? In corrispondenza di un punto specifico? Quale?

Arduino è già abbastanza al limite. Lo escluderei a priori.
Il Teensy è molto (ma molto) più potente e può farcela, anche se sarebbe un qualcosa molto verticalizzato sul teensy, mentre il concetto base è quello di standardizzare le funzionalità.
E' vero che sono personalizzate sull'hardware, ma questa dsarebbe un'applicazione di nicchia.

Sulla singola riga: che ci fai? Non te ne servono comunque 3?

Come hobbista mi fermerei ai drive closed loop ed investirei più sulla meccanica.

Mi sembra di sentire certi personaggi della mia azienda, secondo i quali si risolve tutto con il sw #-o

Junior73
God
God
Messaggi: 3614
Iscritto il: lunedì 14 aprile 2014, 10:36
Località: Perugia

Re: GRBLHAL e Teensy 4.X

Messaggio da Junior73 » giovedì 3 dicembre 2020, 11:57

Ti rispondo Hell con un esempio pratico (dove magari possiamo ragionarci su) di un singolo foro (per brevità) diametro 6mm messo a x20Y20 spessore piastra 10mm

Vado di Cambam
( T6 : 6.0 )
G21 G90 G64 G40
G0 Z3.0
( T6 : 6.0 )
T6 M6
( Foratura 1 )
G17
G0 X20.0 Y20.0
G98
G81 X20.0 Y20.0 Z-11.0 R0.0 F20.0
G80
G0 Z3.0
M30
---------------------------------------------------------

Se usiamo Grbl normale non supporta il G81 (GRBLHAL si) e quindi lo apro con CNCUSB e risalvo otttenendo quello di seguito ...l'algoritmo interno della planet cnc riporta istruzioni di movimenti" inutili" in quanto già in posizione ....le riporto come sono.
%
G90
G21
G17
G64
G00 Z3
T6 M6
G00 X20 Y20
F20
G61
G00 X20 Y20 Z3
G00 X20 Y20 Z0
G01 X20 Y20 Z-11
G00 X20 Y20 Z3
G64
G80
G00 Z3
M30
M02
%
-------------------------------------------------------

Mi scrivo due righe di codice per un programmino di elaborazione testo che mi prende G00 G01 e ne scorpora i movimenti in modo che la macchina mi esegua un movimento di un singolo asse alla volta, caricando quindi il micro di un certo carico di lavoro. Dato che è un foro passante mi serve di sapere solo se veramente sta a x20y20 ma non mi importa della Z dal momento che gli ho dato 11mm di profondità.

%
G90
G21
G17
G64
G00 Z3
T6 M6
G00 X20 (controllo)
G00 Y20 (controllo)
F20
G61
G00 X20(controllo)
G00 Y20(controllo)
G00 Z3( non mi serve un controllo)
G00 X20 (controllo)
G00 Y20 (controllo)
G00 Z0( non mi serve un controllo)
G01 X20 (controllo)
G01 Y20 (controllo)
G01 Z-11( non mi serve un controllo)
G00 X20 (controllo)
G00Y20 (controllo)
G00 Z3 ( non mi serve un controllo)
G64
G80
G00 Z3 ( non mi serve un controllo)
M30
M02
%
Posto questo ragazzi ma devo finire delle cose ...oggi torno alle 14....posso aver sbagliato qualche correzione sul gcode poichè l'ho fatto a mano ma è il concetto che volevo evidenziare. Le lavorazioni e gli esempio sono tanti. Sapere i "posizionamenti" in simulazione (in aria ) di X ed Y prima di fare fisicamente i fori non sarebbe male....


@Tecno67

Dato che GrblHal si ispira a Linucnc mi chiedevo cosa fa quest'ultimo per gli encoder con le schede Mesa.
Ieri sera ho letto qualcosa sul loro forum ma poi mi sono "addormito" :roll:

Saluti

Avatar utente
hellfire39
God
God
Messaggi: 3413
Iscritto il: domenica 16 dicembre 2012, 9:04
Località: AN

Re: GRBLHAL e Teensy 4.X

Messaggio da hellfire39 » giovedì 3 dicembre 2020, 12:19

Evidenzia su quali righe di codice deve essere eseguito il controllo prima di proseguire.
Dopodiché trova una condizione logica, comprensibile dal computer, che le descriva.

Ragionando da programmatore, ho bisogno di regole semplici e ben definite altrimenti non saprei come codificarle.
Difficile dire al processore

IF "in aria" THEN "controlla quote" :mrgreen:

rosettacnc
Member
Member
Messaggi: 209
Iscritto il: venerdì 6 settembre 2019, 8:18
Località: Vicenza

Re: GRBLHAL e Teensy 4.X

Messaggio da rosettacnc » giovedì 3 dicembre 2020, 12:35

Junior73 ha scritto:
mercoledì 2 dicembre 2020, 22:19
un Arduino Uno fino ad arrivare al teensy 4.1 possano ad esempio leggere una singola riga ottica da 0,005mm di precisione ad una velocità di movimentazione sotto ad 1 metro al minuto (rapidi compresi)
Bisogna sempre capire con che si sistema di ha a che fare.
Ci sono sistemi in cui il driver motore lo controlla in velocità ma non in spazio ed è a monte che si controlla la posizione.
Gran parte dei sistemi che usano gli hobbisti hanno driver che controllano il motore in spazio tramite il resolver sul motore.
A questo punto applicare una riga serve per risolvere a valle le problematiche di posizionamento che un sistema driver-motore ad anello chiuso non può sapere, ma temo che chip con caratteristiche di interrupt non real-time non siano adegauti. Il Jit tra un rilevamento posizione e il successivo darebbe picchi positivi o negativi anzichè rilevare una velocità costante (ad esempio). Per queste cose di solito si usano tecnologie più veloci e anche la regolazione a monte (correzione) deve essere estremamente precisa o invece di correggere qualcosa la si incasina ancor-più. Non son cose per deboli di cuore, come programmazione. Già nel 2004 avevamo sviluppato un driver motore con IGBT e un paio di DSP della motorola e ancora era dura... Poi con l'avvento delle FPGA tutto si semplifica ma è un'altra divagazione...
Junior73 ha scritto:
mercoledì 2 dicembre 2020, 22:19
unInoltre se come avevo accennato(forse sbagliando) che in Rosettacnc si può fermare la lavorazione, muovere uno o più assi e riprenderla , ed è il software che ricalcola i movimenti successivi.

Se ad esempio devo fare un foro a x10 ma mi accorgo tramite un controllo "ottico" di stare realmente a X9,9 posso fermare (tipo pausa) la macchina spostarmi manualmente di 1 decimo e poi continuare con il foro successivo che magari sta a x20 sapendo che il programma avrà aggiornato l'origine per le successive lavorazioni sullo stesso pezzo ?
In Rosetta ci si può fermare in qualsiasi posizione e riprendere dal punto in cui ci si è fermati in modo sicuro e gestito da una macro customizzabile che gestisce tutte le fasi di ripresa, ma capire cosa intendi non è semplice.

Le correzioni che dici tu vanno fatte direttamente nella generazione percorso e sono più complesse di quanto si possa pensare perchè è da capire cosa devono correggere: non corrispondenza tra posizione in driver-motore rispetto posizione asse finale, illinearità asse (vite), etc.

Vi siete addentrati in un terreno pieno di mine :)

Avatar utente
hellfire39
God
God
Messaggi: 3413
Iscritto il: domenica 16 dicembre 2012, 9:04
Località: AN

Re: GRBLHAL e Teensy 4.X

Messaggio da hellfire39 » giovedì 3 dicembre 2020, 13:06

Mi pare di averlo detto anch'io... :D

Visto da fuori, il mondo sembra più semplice di quello che è nella realtà.

tecno67
Member
Member
Messaggi: 391
Iscritto il: lunedì 26 febbraio 2007, 14:25
Località: Prov. di Milano

Re: GRBLHAL e Teensy 4.X

Messaggio da tecno67 » giovedì 3 dicembre 2020, 14:14

Temo che junior73 si stia incasinando la vita tentando di avere cose che su una CNC hobbystica è impensabile di realizzare.

Alla base c'è il tentativo di realizzare posizionamenti precisi su una macchina che ha viti con un notevole gioco e per giunta non costante lungo la vite. Caratteristica tipica delle macchine vecchie senza viti a ricircolo.

Quando si usa una macchina del genere a mano si può tranquillamente fare un posizionamento preciso anche con una vite sballata perché si fa un avvicinamento veloce, si da il tempo di stabilizzarsi alla tavola e poi si fa un avvicinamento lento in una direzione conosciuta che non inneschi oscillazioni, riferendosi alla indicazione del DRO che leggendo la riga (che non ha giochi) da una indicazione precisa. In questa fase ce se ne frega altamente dell'indicazione del nonio sul volantino (o per omologo della posizione letta sul motore), ma questo funziona perché la bassa velocità permette essere sicuri di fare l'avvicinamento da una direzione e soprattutto durante il posizionamento l'unica forza che agisce sulla tavola è la spinta della vite. Durante la lavorazione invece (a differenza di quanto avviene in tornitura) l'azione dell'utensile sottopone la tavola ad una serie di forze che cambiano di verso e direzione in continuo e qui come dice Rosetta ci vorrebbe una elettronica e dei motori con una dinamica semplicemente folle per starci dietro con le correzioni (ricordate l'esempio del veicolo con la scatola dello sterzo usurata?). Un cedimento elastico dell'assieme vite chiocciola ai vari carichi forse lo si potrebbe anche gestire, ma un gioco random No.
Quindi su una macchina di questo tipo possiamo scordarci un controllo traiettoria preciso con assi che sono per forza di cose sbloccati ed utensile in lavorazione. La tavola semplicemente oscilla casualmente attorno a quella che dovrebbe essere la traiettoria ideale con una ampiezza che è quella data dal gioco della vite in quel punto.
Cosa diversa è quella che se interpreto bene ha in mente Junior73, ma che non riesce a far capire. Solo che è una strategia attuabile solo per quelle lavorazioni che prevedano l'uso di un solo asse alla volta, come la foratura. Mi posiziono, ricontrollo la posizione grazie alla guida, correggo se serve, (blocco gli assi X ed Y - Questo è indispensabile altrimenti mi ritrovo che una punta da 6mm mi fa un foro da 6.1 o peggio) e poi scendo a fare il foro. In più lui dice se già che ce l'ho uso la riga anche per risistemare l'offset quando faccio un pre-posizionamento risolvo pure magari una qualche perdita di passo (ma non è cosi che si risolve il problema perché se non so in quale punto del gioco della chiocciola mi trovo, non so se l'errore è una perdita di passo o meno e non posso spostare l'origine a casaccio ad ogni posizionamento).
Detto questo le sue esigenze sono semplicemente quelle di poter avere la lettura delle righe nel GRBL. Ed eventualmente la possibilità di vincolare l'esecuzione della successiva istruzione ad una verifica di corrispondenza tra la quota a cui si trova l'asse secondo il generatore di profili e la sua posizione effettiva letta tramite la riga (in caso contrario servirebbe la possibilità di movimento relativo di valore pari alla differenza tra posizione teorica ed effettiva). Poi però sara lui a dover programmare in GCODE tutti le verifiche dove servono #-o #-o #-o

Junior73
God
God
Messaggi: 3614
Iscritto il: lunedì 14 aprile 2014, 10:36
Località: Perugia

Re: GRBLHAL e Teensy 4.X

Messaggio da Junior73 » giovedì 3 dicembre 2020, 18:41

Rieccomi ...Tecno67 nella seconda parte del discorso è entrato quasi perfettamente in quello che Gcodesender dovrebbe integrare. Sono passato alle nostre cnc con (nella maggior parte dei casi) viti e guide cinesi . Non parlavo più delle macchine vecchie con forte gioco sulle viti.
Mi riallaccio al discorso di stamattina commentando le prime righe :

%
G90
G21
G17
G64
G00 Z3 (qui anche se ci fosse una riga per Z non è necessario che avvenga nulla. Nel menu ci potrebbe essere una spunta che attiva o disattiva il controllo per ogni asse e Z verrebbe disattivato)
T6 M6
G00 X20 (qui dopo il movimento ci dovrebbe essere un confronto tra la posizione ipotizzata nel dro relativo e quella "reale" riportata nel dro dell'"Encoder Position". Un confronto probabilmente tra due variabili che può essere :

-Evidenziato se il valore numerico supera una certa soglia stabilita dall'utente all'interno di un setup dedicato . Se mi serve una precisione dentro i 5 centesimi con la mia cnc (la seconda cnc è leggermente meglio ) non son sicuro di averla, in special modo se non è il primo foro dallo zero pezzo ma è il trentesimo della serie non in linea (sparsi). Di solito nei percorsi eseguo prima i fori (ma anche asole , sedi di cuscinetti etc) e il resto meno importante.
Quando dico "simulazione in aria" voglio dire alzare di 20mm lo zero sulla Z ed effettuare il percorso senza forare nulla . In un eventuale" log" dalle discrepanze rilevate deciderei se procedere o meno.
Una perdita di tempo sicuramente ma se devi fare 10-20 piastre ne vale la pena!!!

-Parte Attiva, che nella mia fantasia vorrebbe dire compensare quella differenza con un movimento fisico del motore incrimiminato di X. Quindi dovrebbe partire una istruzione gcode , una serie di impulsi etc nella giusta direzione che non modificano il dro delle quote normale ma solo quello dell'econder.
Qui sorge il problema tra l'entità del movimento e ciò che la vite/chiocciola possono permettere a seconda
del passo , risoluzione ,stato d'usura etc In un ipotetico setup di quanto compensare ogniuno decide in base ai valori più vicini che riesce ad ottenere con la sua meccanica. A quel punto i valori dei dro di X devono combaciare (ipotetico ed encoder)

Esempio

Dro normale 20,000
Dro Econder 20,150 (macchina da buttare!!!) :? :lol:

Quindi un G00 X-0,150 teorico sapendo che non sarà un movimento perfetto al centesimo.

Se il programma non è in grado di generare in tempo reale un tale movimento prima del effettuare il movimento successivo magari potrà inserirlo in un nuovo gcode da eseguire dopo la simulazione.


........


Ora prima di fare una figuraccia con Tereio (con Phil già l'ho fatta credo) vorrei capire come fate a calcolare le potenzialità dei micro per questa applicazione di letture di una riga ottica.

-Quanti "impulsi" tira fuori una riga ottica con risoluzione 0,005mm andando ad un metro al minuto?
-Quanti impulsi riesce a catturare al massimo Arduino uno se fa solo questo?
-Quanti impulsi riesce a catturare al massimo il Teensy 4.1 se fa solo questo?
-Eventuali perdite di impulsi quanto possono influire sulla misurazione ? Possono avvenire anche senza "stressare" il micro? A causa di disturbi o cosa?

Saluti

Posto una foto in cui ho aggiunto una scritta Encoder position con una "spunta" che sempre nelle mie fantasie dovrebbe visualizzare non le coordinate assolute ma quelle dell'encoder. Gcode Sender di Tereio sta eseguendo veramente il programmino di cui sopra con un nano e grbl normale.
Non hai i permessi necessari per visualizzare i file e le foto allegati in questo messaggio. Per visualizzare tali file devi registrarti ed effettuare il Login

Avatar utente
hellfire39
God
God
Messaggi: 3413
Iscritto il: domenica 16 dicembre 2012, 9:04
Località: AN

Re: GRBLHAL e Teensy 4.X

Messaggio da hellfire39 » giovedì 3 dicembre 2020, 19:20

Un altro milione di parole che un programmatore non sa che farci.
Non mi sono spiegato: servono poche regole chiare e valide sempre, anzi... semprissimissimo (senza eccezioni).

IF GCODE E' G0 ESEGUI IL CONTROLLO ALLA FINE DEL MOVIMENTO
IF GCODE E' G0 ALLORA NON MANDARE AL PORO ARDUINO PIU RIGHE, MA MANDANE UNA SOLA PER VOLTA

(altrimenti il look-ahead le accoda per evitare di accelerare/decellerare ad ogni movimento).

Se vuoi che un programmatore ti ascolti e/o capisca quello che vuoi, devi essere in grado di esprimere i tuoi desideri in questo modo stringato e non equivocabile. Tenendo presente tutte le casistiche di codice che potrebbero essere date in pasto.
Attenzione inoltre a non confondere ciò che fa Arduino da ciò che fa il programma di controllo, qualunque esso sia

tecno67
Member
Member
Messaggi: 391
Iscritto il: lunedì 26 febbraio 2007, 14:25
Località: Prov. di Milano

Re: GRBLHAL e Teensy 4.X

Messaggio da tecno67 » giovedì 3 dicembre 2020, 21:19

@Junior73
A parte le giuste precisazioni di hellfire, mi pare che sfugga un concetto essenziale:

Se il controllo funziona, i motori sono adeguati, magari sono pure dei closed-loop e tu ti trovi delle discrepanze tra la posizione teorica e quella reale letta dalle righe, questo è imputabile solo ed esclusivamente ad una non rigidezza assoluta del collegamento meccanico tra il motore e la tavola. (gioco vite-chiocciola, gioco assiale dei cuscinetti, gioco del giunto di accoppiamento tra motore e vite o dell'eventuale riduzione interposta tra i due e financo insufficiente rigidezza strutturale.
In una macchina tradizionale tu risolvi questo con le varie tecniche di recupero gioco (il classico mezzo giro indietro del volantino e poi di nuovo avanti) cosa che entro certi limiti fanno anche programmi come cnc-planet ed altri. Ma si tratta di fenomeni tutti di tipo random, non è che se io faccio dieci simulazioni di posizionamento mi ritrovo un gap tra le due posizioni costante in tutte e dieci le simulazioni, per cui inserisco nel programma Gcode definitivo le correzioni e sono apposto. Non funziona. Perché ad ogni simulazione mi troverò errori diversi a caso. Se proprio voglio seguire la strada della correzione dopo il posizionamento, devo posizionare, verificare, riposizionare lentamente sperando di non andare oltre, ri-verificare e se va bene bloccare fisicamente gli assi (presumibilmente x e Y) e scendere a forare. La simulazione non mi serve a un tubo. Poi giustamente, come fa notare hellfire, c'è il fatto che il generatore di profili per velocizzare anticipa il movimento successivo. Se vuoi posizionare e verificare, devi per forza imporre al controllo di non anticipare i movimenti, ma dato che non puoi farlo per ogni segmento elementare della traiettoria, devi essere tu nel GCODE a dire dove vuoi che il sistema si fermi, verifichi, corregga e riparta. Non puoi pretendere che il SW lo faccia in automatico, perché il SW non può sapere da solo quali posizioni sono importanti e quali no. Nella programmazione dei robot, proprio per ottenere questa cosa, esistono istruzioni per cambiare la tolleranza ammessa sul posizionamento, (Per la verità non è esattamente così. Ci sono delle istruzioni che quando seguono una istruzione di movimento in automatico impongono al controllore di movimento di portare gli assi esattamente sul punto richiesto e non 'entro una certa distanza da quello'), ma devi sempre essere tu che scrivi la traiettoria ad inserire queste istruzioni dove serve.
Mi pare che pur avendo detto, ora di voler usare delle viti a ricircolo invece che le tradizionali, tu ti stia ostinando a voler ottenere da una macchina che non ha una classe di precisione meccanica del livello che desideri quella classe di precisione. Cosa possibile in alcune situazioni particolari, ma non sempre ed a prescindere.
Poi se vogliamo chiedere agli sviluppatori del SW di creare la possibilità di leggere le righe per farne un uso, quale che sia e che al momento non sappiamo quale sarà, ben venga. Le possibilità è sempre meglio averle che non averle.

Per quanto riguarda la frequenza degli impulsi generati dalla riga è presto detto: Se usi una riga ad 1um di risoluzione, questa genera un impulso per ogni micron (in effetti genera due onde quadre con un periodo di 4um sfasate tra loro di 90°, ma questo alla fine disturba il micro, come minimo una volta ogni um percorso), per cui se ti muovi a 6000mm/minuto disturbi il micro 6,000,000 di volte in un minuto ovvero 100,000 volte in un secondo e questo per ogni asse da leggere... Per Arduino è impossibile, per il Teensy un po meno, se lo fai usando le perferiche QEI integrate (che sono solo 4), se lo fai nel SW è comunque un lavoro non da poco. Forse è meglio accontentarsi di 5um.

Quanto al carico di lavoro sopportabile non puoi porre la questione in questi termini, se tu valuti solo il numero di operazioni necessarie a fare quello che vuoi e lo compari col numero di operazioni al secondo che il micro può svolgere, magari può sembrare che ci stai ampiamente, ma se hai due o più cose che devi fare assolutamente entro un certo tempo, ti frega assai che nel tempo totale il micro ha un sacco di cicli di clock a disposizione, di centometrista a disposizione tu ne hai solo uno e o sta qui, o sta la.
Finché non scendi nel dettaglio del programma, non puoi sapere con certezza se ci stai dentro o meno.

rosettacnc
Member
Member
Messaggi: 209
Iscritto il: venerdì 6 settembre 2019, 8:18
Località: Vicenza

Re: GRBLHAL e Teensy 4.X

Messaggio da rosettacnc » giovedì 3 dicembre 2020, 22:05

La lettura di un encoder, a fasi A/B o quadratura di fase, come specificato da tecno76 da 4 valori per ogni impulso dichiarato in quanto conta i fronti e in un impulso sono 4. Detto fatto se hai un encoder da 1000 impulsi giro ne leggerai 4000, in quanto le fasi servono appunto per discriminare la direzione .

Per la lettura veloce di di encoder, sia rotativi che da riga, quando questa esce in quadratura di fase e non in uno specifico formato bus,
si può fare in tanti modi:

- se molto lenta si usano due ingressi in interrupt del micro (PESSIMA IDEA ma funziona).
- entro certe velocità ci son micro che hanno la funzionalità già integrata nei moduli TIMER della MPU.
- se si ha dimestichezza con i bus SPI ci sono chip che ti leggono le quadratura di fase fino a 400Khz ed oltre e li leggi con quel protocollo.
- se le hai "quadre" ti fai un bel programmino in VHDL e con una FPGA hai una lettura iper-precisa a frequenze enormi direttamente sul data-bus.

Poi di righe ottiche ce ne sono con le due fasi, in CANBUS, in ProfiNET, in SPI, etc. etc

Il succo è : ma a cosa serve avere i dati da riga ?

Se serve per correggere il tiro in un sistema già closed-loop tra driver/Motore tramite resolver sullo stesso stai per fare qualcosa di veramente complesso che richiede interventi da CNC PRO direttamente nel generatore di percorso della CNC utilizzando algoritmi adattativi del percorso che poi vanno ad interessare la pianificazione dello stesso sia in velocità che in traiettorie, roba da Heidenhain e similari.

Se pensi che possa essere utile per una correzione manuale siamo già fuori tema.
Le viti hanno giochi variabili, spesso dovute all'usura in determinate zone o perchè non sono retifficate o di qualità scadente.

Non si linearizzano non si risolvono i giochi neanche con riga.
Pensa che nelle CNC Pro recuperi giochi in sistemi con motore in closed-loop e riga purchè inveriori al centesimo di mm e poi anche questo è tutto da vedere...

Inoltre è praticamente impossibile compensare gioco in interpolato (quando vi sono più di un asse che si muove in contemporanea cambiando direzione di uno o più assi durante il tragitto).

Oltre alle forze necessarie per il movimento del mandrino (punto di interpolazione) ci sono forze contrarie o imprevedibili date dalla lavorazione (sia essa concorde o discorde) che ti mescolano le carte di qualsiasi analisi vettori direzione fatti in CNC...

Junior73
God
God
Messaggi: 3614
Iscritto il: lunedì 14 aprile 2014, 10:36
Località: Perugia

Re: GRBLHAL e Teensy 4.X

Messaggio da Junior73 » giovedì 3 dicembre 2020, 23:03

Capito ragazzi ora è più chiaro....a questo punto possiamo solo proporre l'argomento senza nessuna richiesta e vedere cosa fa Tereio nello sviluppo della sua Gui per GRblHal. Le richieste per Arduino Uno erano perchè coem avrete letto IOsender può lavorare sia con grbl normale che Hal.

Nel mio caso particolare dovrò continuare a dire di no a richieste esterne quando le precisioni sono troppo elevate per la mia meccanica. A me dispiace in quanto ad esempio i laseristi mi fanno prezzi sempre ottimi , mi danno lamiere a prezzi stracciati (ormai siamo amici).Spesso mi rivolgo al mio amico con l'officina meccanica per qualche sgrossatura o tornitura di roba grande e so quanto tempo ci vuole per lavorare su macchine manuali.
L'uso del backlash non l'ho mai preso in troppo in considerazione e non ho verificato eventuali benefici . Le chiocciole hanno un 1-2-3 centesimi di gioco e non penso che risolva molto o meglio che possa una soluzione cui mi posso affidare ciecamente per avere una precisione entro i 5 centesimi come da richieste particolari.
In passato avevo valutato l'ipotesi di prendere i dro con alte risoluzioni ma essendo non legati alle schede di controllo ci fai ben poco , a meno di non lavorare in "manuale" , cosa impossibile solo per i tempi :shock: . Senza un automazione dei processi di controllo e rettifica della posizione si torna a metodi di lavorazione del passato in cui non mi ci ritrovo , troppo macchinosi e lenti.

Attendiamo allora eventuali altre adesioni alla scheda di Phil Barrett e Teensy . Forse portare qui le prime impressioni può rimanere un po "pesante" per coloro che leggeranno queste lunghe discussioni.

Saluti

Rispondi

Torna a “Controlli Seriali, Usb e Ethernet”