MECCANICA e DINTORNI

Da quello che mi ha spiegato Mimoletti (e da quello che ho capito) il suo programma fa quello che dice McMax.
Che poi e' come l'ha pensata il russo.
Per fare i passi frazionari si divide per n e n+1, modificando quante volte si divide per n e n+1 si ottengono le varie frazioni.
Per il resto vi seguo con molto interesse

sono 16 cent ogni 20 mm .... non penso sia proprio il massimo, es. un dado m16 a misura non so se gira e un manicotto filettato (40 mm e quindi 3 decimi abbondanti di errore) quasi sicuramente no.
Probabilmente per questo cercano risoluzioni elevate sia sull' encoder che sul pp.
Ero peró piu orientato sulľaumentare la risoluzione delľencoder per non rallentare troppo la lavorazione con un pp troppo demoltiplicato.
Non so ancora come gestire velocemente ľencoder....quasi quasi torno al pic con il modulo qei per la gestione encoder in quadratura e con il debugger che mi agevola nella risoluzione dei problemi.

E' vero, tanti PIC hanno la QEI interface che è una mano santa per sti lavori....
Adesso provo a fare un esercizio con una sequenza al 100, vediamo che succede. Secondo me possiamo stare su 1000 passi di encoder e 400 di stepper e lavorarndo sul firmware ce la dovremmo fare.
Dovrei ragionarci un po meglio ma se abbiamo già i valori caricati in un array basterà leggerli seuqeunzialmente e processarli senza dover fare conti lunghi durante la lettura dell'encoder. Con 1000 passi/giro a 500 giri (che credo siano già troppi per filettare) abbiamo 120usec di latenza tra un impulso e l'altro.... per quanto la routine di lettura dell'encoder sia complessa con un AVR ATmega a 16Mhz abbiamo risorse da vendere.... sono micro RISC a 1 clock/istruzione; se consideriamo 16MIPS, in 120usec riesce ad eseguire 1920 istruzioni non complesse.

Arduino è più che sufficiente e non è necessario scomodare gli array,
quello che dovete eseguire è una divisione frazionaria,
che si ottiene dividendo per n, successivamente per n+1,
Variando la percentuale di tempo in cui complessivamente il sistema divide per n o n+1,
potete ottenere un qualsiasi valore di divisione.
Facciamo un esempio: immaginiamo che il valore di divisione è 3,1,
il sistema dovrà dividere il treno di impulsi proveniente dall' encoder 10 volte per 3 e la undicesima volta per 4.
Il valore di divisione cosi ottenuto è uguale a: (3+3+3+3+3+3+3+3+3+3+4)\11= 3.09.
Ovviamente il valore di divisione non potrà mai essere inferiore a 1,
pertanto l'encoder e il pp dovranno avere valori di risoluzione simili.
Inoltre scegliendo un risoluzione per il pp troppo bassa otterrete in avanzamento un funzionamento troppo rumoroso, sopratutto ai bassi avanzamenti (2 cent a giro).
Quindi dalle prove che ho fatto non conviene scegliere un'encoder con una risoluzione inferiore a 2000 impulsi a giro.
Io attualmente uso un encoder da 1800 impulsi a giro che con l'uso di una Exor ne diventano 3600.
Il passo passo ha una risoluzione di 4 : 1 e ho un micro step di 1600 passi a giro.
Ovviamente dovrete trovare un giusto compromesso, perché maggiore sara la risoluzione del pp a maggiore dovrà essere la risoluzione dell'encoder (il valore di divisione non potrà mai essere inferiore a 1) e minore la velocità che il pp potrà raggiungere prima di andare in stallo. Io ho preferito avere un motore più fluido anziché avere la possibilità di filettare a reggimi elevati (comunque con passo 2 mm filetto a 250 giri, a passo 1 mm 500, ecc). Se il mio tornio avesse avuto un cambio norton comunque non avrei potuto filettare a più di cento giri. Prima che realizzassi questo progetto ho sempre filettato alla minima velocità ottenibile sul mio tornio che è di 30 giri al minuto.

Massimo così facendo però costringi il programma a ricalcolare di continuo per ottenere lo stesso medesimo risultato. Il tempo e le risorse della CPU vengono messe a dura prova. La mia idea di usare un array di valori è proprio perchè il calcolo va fatto solo all'inizio e non serve doverlo fare continuativamente. Una volta caricato l'array il sistema dovrà solo leggere gli impulsi dell'encoder, dare il passo ed incrementare l'array per leggere la divisone successiva.

Il problema qui non è il calcolo da eseguire, ma capire con che risoluzione si riesce a lavorare senza dover per forza prendere un encoder da 1800 passi/giro.... e poi, se il calcolo lo eseguiamo una sola vota e carichiamo i valori in array, possiamo anche perderci un po' più di tempo e farlo meglio.
Per fare 3,1 perchè usi una sequenza a 11 valori ? Con 10 valori (9 volte 3 e 1 volta 4) ottieni esattamente 3,1..... mi sono perso qualcosa ?

Per curiosità, come fa il tuo firmaware a calcolare le divisioni per un rapporto a 2 decimali tipo 3,65 ?

non ho ben afferrato il fatto della divisione, ho capito il concetto ma non riesco a capire come portarlo su un microcontrollore.
Il controllo dell'encoder secondo me e' meglio lasciarlo al timer e al suo interrup, al massimo mettere un contatore all'interno della routine per aumentarne la capacita'
ma non lasciare il processore sempre in conteggio.
Ora sto' cercando qualche integrato che lo faccia autonomamente e che possa essere programmato per mandare un segnale al raggiungimento di un dato valore.
Mi vengono in mente anche altre opzioni, non so quanto valide, ma le espongo.
-Mettere un encoder con risoluzione molto alta rispetto al passo per limitare l'errore e la sua influenza sulla filettatura
-Modificare il driver per riuscire a cambiare la risoluzione del motore pp tramite arduino, es se ho un filettatura a passo molto lungo imposto il pp a 1/2 passo e se ne
ho una a passo fine setto il driver a 1/4 o 1/8

Riguardo alla velocita' di filettatura, non e' mai troppo alta se e' arduino a fermare l'utensile alla misura giusta.
Si velocizza molto l'operazione senza pericolo di collisioni, senza dover ogni volta spegnere il mandrino( come nei torni di produzione o cnc), gli utensili lavorano meglio e abbiamo una finitura migliore.

si può lasciare la gestione dell'encoder al timer (anzi, AI timer visto che le uscite sono 2, in quadratura), ma se vogliamo gestire il bit di direzione per determinare il verso di rotazione è necessario un controllo dei due segnali un po più accurato. Il cambiamento di fase delle due uscite in quadratura è quella che determina il cambio del verso di rotazione.
E' vero che se partiamo con una filettatura ed abbiamo una velocità di rotazione ad un certo regime è imossibile che si verifichi una inversione del senso di rotazione, ma discriminare questa condizione potrebbe essere più complesso che gestirla ad ogni ciclo.... ma ci devo ancora pensare.

Per quanto rigurada il conto io con la mia teoria degli array eseguirei una routine di calcolo complessa PRIMA di iniziare il cicli di lavorazione. Una sequenza a 10 valori viene semplice ma credo serva a 100. Ottenuto il valore a due decimali (es 3,54) estrapoliamo la parte intera e separiamo quella decimale. Quella intera determinerà il divisore "n"; quella decimale il numero di divisioni n+1. Considerando sempre 3,54, su una sequenza a 100, avremo 54 valori con divisione n+1(4) e 100-54=46 valori a divisione n(3).
L'idea di cambiare il passo dello stepper in funzione della vite da fare è buona ma non vorrei inserire troppe complicazioni; anche perchè questa funzione dovrebbe prevedere la possibilità da parte del micro di impostare con delle uscite digitali il passo sul driver.... troppe variabili secondo me.

Si puo' far gestire il segnale dell'encoder da una logica esterna al micro.
Metto lo schemetto fatto dal russo, ma si puo' implementare anche in modo diverso.
Cosi' abbiamo un solo segnale per i passi dell'encoder (somma di A+B o solo A, a seconda se si usa un xor o un and) e un livello alto o basso a seconda della direzione.
In teoria, cosi' si dovrebbe semplificare la gestione dell'encoder da parte del programma.

Quello del contare anche gli impulsi inversi era un cosa che volevo fare anche io.
Il motivo e' che se noi abbiamo un encoder a grossa risoluzione e lo usiamo in x2, potrebbe contare in maniera errata in caso di vibrazioni sul mandrino.
Purtroppo tutte queste considerazioni mi portano sempre piu' verso un chip dedicato alla decodifica dell'encoder e, nel mio progetto, programmato a inviare un segnale al raggiugimento di un valore impostato dall'arduino che governa il tutto.
Ho fatto delle ricerche sui chip qei ma nessuno di questi puo' essere programmato per una comparazione.
Volevo anche segnalare il fatto che i calcoli non necessariamente devono essere fatti nella isr.
Si potrebbe fare solo il passo e lasciare i calcoli fuori, abbinati a un flag di "calcolo aggiornato" che verra' solo verificato nella isr. Un'idea buttata li.
Per la variazione del passo sul driver, basta sostituire il microswitch con un qualche cosa tipo interruttore controllato da un bit di arduino....ma per adesso obbiettivamente questo passa in secondo piano, diciamo un'ottimizzazione quando tutto funzia.

Mandi Mecha

Ciao Max,

esatto divido 9 volte per 3 ed 1 volta per 4, avvolte scrivo dal cellulare e mi capita di scrivere delle inesattezze.
La mia routine di interruzione e molto breve e dura solo pochi us. Forse una decina in tutto.
L'importante è caricare immediatamente il valore di divisione nel timer.
Se non si ha intenzione di usare una Xor per raddoppiare la risoluzione del encoder non sono necessari altri componenti esterni,
soprattutto per stabilire il senso di rotazione del mandrino.
Io eseguo la divisione degli impulsi esattamente come fa il russo (in linea di principio, ma in modo leggermente diverso) è l'unica cosa che il mio listato ha in comune con il suo. Quando ho sviluppato il progetto con Proteus, ho utilizzato due micro, uno per generare un numero finito di impulsi, ed un secondo per testare la routine di divisione, il risultato era privo di errori.
Ad esempio generando 65000 impulsi e utilizzando un qualunque valore di divisione ottenevo sempre il risultato corretto.
Per quanto riguarda le vibrazioni io non ho riscontrato nessun tipo di problema, ormai lo uso da diversi mesi e ho fatto numerose filettature.

Mi riprometto sempre di mettermi a fare prove durante il week end ma non ci riesco mai!
Ho però dato un occhiata meglio all'interfaccia in quadratura e sto valutando che forse conviene trattare il segnale prima con della logica per semplificare al micro la gestione.
Tra i vari circuiti che ho trovato non mi dispiace questo:


Con due flip flop si separano gli impulsi per direzione di avanzamento.... in questo modo si può evitare al micro di fare il controllo sulla direzione di avanzamento e si possono usare gli impulsi per incrementare da un lato e decrementare dall'altro lo stesso contatore.L'ideale sarebbe avere due uscite classiche step e dir e non escludo che elaborando un po questo schema co un paio di logiche in più si possa fare.... e con step e dir a cosa diventerebbe ancora più semplice.....

alla fine dovrebbero essere giusto un paio di integrati, nulla di super sofisticato, giusto?

concordo che meno roba deve calcolare il processore + si puo' andar di fino sulla gestione dell'avanzamento

in pratica in questo modo si hanno 2 ingressi digitali alto/basso per la direzione e uno su cui arrivano gli impulsi che equivalgono ai passi dell'encoder?

io addirittura, avevo ancora + semplificato la cosa, proponendo di gestire l'inverter con l'arduino in modo che la direzione non era da determinare leggendo il treno di impulsi ma era comandata direttamente dalla logica...

Con lo schemetto allegato si ha un treno di impulsi pari al doppio della risoluzione dell'encoder (A+B) e un segnale alto/basso a seconda della direzione.

carino questo schema! Clock x4 con segnale dir.... da provare.
con questi due segnali il micro dovrá solo incrementare o decrementare un contatore.