MECCANICA e DINTORNI

Io non mi vorrei sbagliare ma il russo faceva nello stesso modo, nella rutine di interrupt determinava la direzione del encoder, verificando il secondo canale.

Max ma secondo te può funzionare la rampa di accelerazione e decelerazione come la descritta Matteo?

Si certo che funziona, ma io la calcolerei prima come faccio anche per la progressione della filettatura. In questo modo il sistema diventa perfettamente reversibile: se inverti il mandrino non perdi il sincronismo.
Non mi piace particolarmente il metodo del controllo direzione nella routine di interrupt, porta via tempo e perdi risoluzione sull'encoder. Poi a me non piacciono gli if nelle routine di interrupt, se proprio serve se ne fa uno, già 3 sono troppi...

Eccomi, ho trovato il tempo per giocare col codice.
Visto che di millis() e micros() non ci fidiamo, ho fatto altre prove:
1. impostato il pin 8 come output. Messo basso (tramite i registri) a inizio loop e messo alto a fine loop (nel mezzo c'e' la mia routine di interrupt). Attaccato l'oscilloscopio al pin 8 leggo circa 4uS di periodo.
2. ho usato proteus per contare i cicli di clock. Da quello che dice proteus, l'interrupt dovrebbe durare 11uS (stesso codice che ho provato con l'oscilloscopio).
Quando ho tempo provo a vedere il codice che produce il compilatore di arduino confrontato con quello di proteus... uno dei due imbroglia (o io non sono capace di usare proteus, che puo' starci).

McMax, ho capito quello che mi dici, vedro' di modificare il programma per rendere la routine di interrupt piu' snella.
E vedro' di commentare meglio il programma (avevo avvisato che era scritto da cani).
Per quanto riguarda il fatto di leggere un solo canale, se l'encoder ha risoluzione sufficiente perche' non dovrei? Tu usi un encoder da 3-400ppr x 4, io uso un encoder da 2000ppr x 1. Correggimi se sbaglio ma non credo che un encoder da 500ppr x 4 abbia maggior risoluzione rispetto ad un encoder da 2000ppr x 1.
Per quanto riguarda usare logiche esterne, avrei potuto ma a che pro? Mi sarei trovato sempre un segnale di clock e uno di dir. Il clock da mettere sotto interrupt e controllare il dir. Tanto vale farglielo fare direttamente al programma, mi risparmio spazio sul pcb. Sempre se sbaglio correggimi.

@Mimoletti: si, ricordi giusto. La mia routine di interrupt e' praticamente identica a quella del russo. Ho solo fatto qualche adattamento ma il concetto resta quello.
Per le rampe vedremo quando montero' il tutto sul tornio (e' gia' tutto pronto, devo solo collegare l'arduino). Se funziona bene, altrimenti correggeremo il programma (per fortuna non ho scadenze e posso permettermi di fare-disfare quante volte voglio. E non e' una perdita di tempo perche' ogni volta imparo qualcosa di nuovo e mi diverto un sacco )

Permettendo che visti gli anni passati, potrei ricordare male. All'epoca con il traduttore di Google avevo tradotto le pagine del post di Oleg, il codice non è stato scritto da lui ma da uno dei suoi amici che fa il programmatore di mestiere.
Poi se pensiamo che lui e riuscito dove sia io che Max abbiamo fallito, riuscendo in modalità sincrona a inserire le rampe di accelerazione e decelerazione, mi guarderei bene da criticare il suo lavoro.
Per quanto riguarda la rutine di Interrupt è bene che sia il più veloce possibile, ma nei nuovi micro, tra una rutine di interrupt e quella principale, praticamente non ci sono differenze. I limiti di annidamento sono gli stessi che hai nel programma principale.
Per quanto riguarda la stesura del programma ti consiglio di mantenere il sincronismo solo durante la fase di avanzamento (Play) e di retrocedere (Reverse) in modo asincrono. Per me è stato una figata, perché innanzitutto mi ha permesso di aggiungere la rampa di accelerazione e decelerazione almeno nella fase di Reverse con estrema facilità, e poi ti consente di retrocedere anche a mandrino fermo e di farlo con una velocità differente da quella con cui si avanza.
Successivamente potresti prendere in considerazione la possibilità di leggere l'encoder con il Timer e a quel punto, non avrai soprattutto in avanzamento, nessun limite di frequenza.
In ogni caso al di la di tutte le considerazione, non si dovrebbe, è matematicamente impossibile, ecc, l'importante è che il codice funzioni, successivamente gli potrai apportare tutte le modifiche del caso.
A volte il meglio è nemico del bene.

mimoletti scusa ma non concordo, le routine di interrupt devono sempre essere tenute al minimo anche su nuovi micro, per la semplice ragione che l'interrupt generato dall'esterno è sempre arbitrario e ci possono essere perdite poichè se sei in una routine, cambi ad esempio la velocità del mandrino mentre il micro gestisce l'interrupt perdi il nuovo interrupt che ti arriva.
il secondo punto è il termine usato "asincrono", è una forzatura, se il sistema non prevede il multithreading non puoi fare niente in asincrono, hai un solo processore puoi fare una sola cosa alla volta, e non credo nemmeno che abbiate programmato o usato uno schedulatore per i vostri programmi, quindi come hai implementato una funzione asincrona nel pic/arduino (tanto non c'è a livello logico differenza)?

Ciao!!

" e poi ti consente di retrocedere anche a mandrino fermo e di farlo con una velocità differente da quella con cui si avanza."
Oibo' ... questa mi è nuova ... mi ricordo che andando in "tradizionale" nella filettatura , se si sgancia il sincronismo carro-vite madre-mandrino, e si riaggancia in un punto qualsiasi , a meno che non si stìa facendo un filetto multiplo della vite madre il mandrino deve fare N°numero di giri prima di ritrovare la posizione corretta , c'è anche un esempio sul libro del tornitore moderno... come hai risolto questa cosa ?

@ Mimoletti: Non ho le capacita' per criticare il lavoro degli altri, posso solo imparare. E il programma di McMax e' scritto bene ed e' istruttivo.
Il programma di Oleg (che, in realta', dovrebbe essere ucraino, neanche russo) e' scritto un po' col mio stile (commenti un po' artistici) ma ha implementato tante belle cose e tutto con un atmega2560 (qualche periferica in piu' ma stessa potenza di calcolo dell'atmega328, se non vado errato). Per quello ho seguito la linea del russo.
Il ritorno lo faccio in modo asincrono, alla massima velocita' possibile (dello stepper) e con le rampe (indipendentemente dalla velocita' in filettatura).

@ Davide: la figata dell'ELS e' proprio questa. Avendo un microprocessore che tiene d'occhio il mandrino e comanda il carro puoi fare un po' quello che vuoi.
Come similitudine col metodo di filettatura tradizionale, se tu riuscissi a mettere il mandrino nella stessa posizione angolare e agganciare la chiocciola nella stessa posizione in cui sei partito a filettare puoi fare quello che vuoi (sganciare la chiocciola fine filettatura, far girare il mandrino al contrario, ecc...).
Sostanzialmente il micro fa questo, memorizza la posizione angolare quando e' partita la filettatura e sposta il carro indietro in modo che parta sempre dalla stessa posizione. Quando il carro e' alla posizione di partenza e il mandrino e' nella posizione giusta, l'utensile riprendera' il filetto senza problemi.

@Umbez:

Come ho già scritto in altri post la routine di interrupt, deve essere il più breve possibile in modo da poter gestire, un eventuale interrupt successivo.
Nel mio caso tra un interruzione e la successiva, anche nel peggiore dei casi, ci sono almeno 50-60um e la mia rutine di interrupt ne dura 7-8us.
Ma fondamentalmente non c'è nessun motivo per cui non si possano usare gli annidamenti. Anche perché può capitare di dover gestire interrupt da fonti diversi, e non vedo come si possa fare senza annidamenti.

Per quanto riguarda la possibilità di retrocedere in asincrono non mi sono inventato niente di nuovo, come spiegato da Matteo lo si può fare anche con un cambio meccanico, io ho solo avuto la furbata di replicarlo con un cambio elettronico.

@mimoletti non ho capito, ma va bene così non è importante in questo contesto.
Se ci riuscite sono il primo ad installare le cose che funzionano ;-)
Ciao!!

Esattamente cosa non hai capito?

"@ Davide: la figata dell'ELS e' proprio questa. Avendo un microprocessore che tiene d'occhio il mandrino "
No no ferma, questo l'ho capito , ma mimmoletti parlava di retrocedere il carro a mandrino fermo ...
Se sposti il carro a mandrino fermo ok, ma poi per riprendere la sincronizzazione devi fare girare il mandrino N_volte fino a ritrovarla...

... O forse, non intendeva durante la filettatura ?!?

No, deve semplicemente riprendere dalla stessa posizione angolare. Quindi prima di riprendere farà un po’ meno di un giro completo.

Hai tre fasi, play-reverse-pause.
Play e' la fase quando l'utensile taglia, il carro si muove in sincro col mandrino (quindi se il mandrino si ferma, il carro si ferma).
Pause e' la fase quando l'utensile e' arrivato a fine filettatura o e' all'inizio filettatura. E' in attesa del comando per tornare a inizio filettatura (reverse) o per cominciare la passata (play).
Reverse e' la fase quando il carro ritorna da fine filettatura all'inizio.

Nella fase di pause e reverse, il carro e' svincolato (elettronicamente, la chiocciola e' sempre agganciata) dal mandrino, cioe' si muove per i fatti suoi senza seguire il movimento del mandrino (che puo' anche essere fermo).
Ovviamente, quando sarai nella fase di play, il mandrino dovra' girare per riprendere il sincronismo (finche' il mandrino e' fermo, anche nella fase di play, il carro resta ferma).
Spero di essere stato chiaro.

@ Mimoletti: ho riletto la spiegazione dell'uso del timer ma non mi e' chiara una cosa: come fai a leggere l'encoder e incrementare il timer? Usi l'encoder come clock per il timer? E allora la routine di interrupt perche' ti dura 8uS? La mia routine dura 11uS (diciamo che abbia ragione proteus e prendiamo il caso peggiore) ma nella mia routine leggo l'encoder, decido da che parte gira, faccio le divisioni e le rampe di accelerazione e decelerazione (e secondo McMax faccio troppa roba nell'interrupt).

Si, uso l'encoder come clock per il timer. La mia routine di interrupt ha una durata variabile che dipende dalla fase che sta gestendo. La sua durata massima è di circa 8us perché come fai tu, faccio troppa roba nell'interrupt, benvenuto nel club!
Il vero vantaggio nel utilizzare il timer è che non sei costretto a generare un'interrupt per ogni fronte di salita.
Immaginiamo che tu voglia effettuare una divisione per 5, caricherai nel timer un valore tale che si generi un over flow con conseguente interrupt, esattamente ogni dieci impulsi.
Un altro vantaggio dell'utilizzo del timer è che gli puoi abbinare il prescaler diminuendo a tuo piacimento la risoluzione in ingresso.

Il modo in cui leggi la durata della routine di interrupt non tiene conto del tempo speso dal micro per salvare la posizione, da cui dovrà riprender il programma principale, forse Proteus ne tiene conto.

Spero di essere stato chiaro.

"No, deve semplicemente riprendere dalla stessa posizione angolare. Quindi prima di riprendere farà un po’ meno di un giro completo."
Mimoletti abbi pazienza , capisco che è un mio limite ma questa cosa non mi è chiara.
Se torni indietro con mandrino fermo, il sincronismo con l'encoder va a farsi friggere o no ?!
come fa a fare mezzo giro il mandrino per riprendere il sincronismo se non sa dov'è ?
Nel caso di una filettatura, mezzo giro ( o un quarto o un x ) del mandrino potrebbe voler dire che l'utensile è perfettamente centrato nel cavo filetto come che sia esattamente sulla cresta o un po' più avanti o un po' più indietro ...
Scusa ma mi sfugge qualcosa ...