MECCANICA e DINTORNI

Grazie...

Ciao Max ed amici del forum, sempre studiando i due thread sul tuo ELS mi sembra di avere capito che, tranne che in filettatura, contare tutti i passi encoder per ricavare la velocità mandrino è dispendioso e potrebbe essere la cosa sostituta da un encoder con index, non facile da trovare e per giunta tutti quelli che hanno già realizzato il tuo ELS dovrebbero retrofittare a livello hardware il proprio tornio per la sostituzione, cosa da escludere.

Ma non si potrebbe fare un "retrofit" elettronico usando un arduino Nano con il quale prelevare i due segnali encoder e con poche righe di codice contando generare un segnale di index "software" da passare all'ELS ?

Non so se ho detto una sciocchezza a livello di segnali, non sono un grande elettrotecnico ma penso che essendo gli ingressi di arduino ad alta impedenza l'uscita dell'encoder non dovrebbe avere problemi ad passare il segnale ad entrambe gli arduino.

Ovvio poi dovresti riscrivere (rendendolo portabile) le routine di gestione velocità mandrino (tranne che in filettatura dove ovvio devi contare i passi) ... quindi non prenderla come una "proposta" di modifica o come sono stato già rimproverato di volere "aggiungere" ad una cosa che già va ... sto solo usando il forum (mentre sistemo il tornio per l'ELS) per studiare ;-)

non hai bisogno dell'index per il calcolo della velocità, basta contare il numero di step dell'encoder nell'unità di tempo.

Ovvio, infatti proponendo di usare un circuito esterno proprio contare volevo fare, mi sembrava di avere capito , forse male, che sarebbe stato utile avere avuto interrupt meno frequenti (da parte dell’encoder sui passi) per gestire meglio (con più tempo) la gestione del passo passo (accelerazioni, altro) … ma forse ho capito male …

Non cerco di inventarmi niente ma sto solo rileggendo meglio tutti i thread capendo le scelte progettuali :-)

@FlyHappy: se ben ricordo, in qualche messaggio precedente McMax si era gia' espresso in proposito.

Se ci si deve complicare la vita con una piattaforma che e' gia' stata tirata all'osso, tanto vale fare un passaggio di livello e orientarsi su piattaforme di calcolo molto piu' prestanti.
Queste piattaforme piu' prestanti (STM32 per fare un esempio) integrano ingressi dedicati alla lettura degli encoder. Ingressi che non perdono i passi e non caricano il processore. Offrono anche altri vantaggi che potrebbero tornare utili.

Non voglio spegnere gli entusiasmi. Personalmente ammiro (e cerco di imparare da) quanto McMax e' riuscito a spremere dall'Arduino. Io lascerei questo progetto cosi' come e'. Se qualcuno se la sente avvii un nuovo progetto con piattaforma avanzata. Anche perche', detto tra noi, se si migliora la lettura encoder, presto o tardi arrivera' un'altra richiesta e poi un'altra, etc...

I miei due centesimi.

Ciao :-)

Mauro

HappyFly/FlyHappy (immagino siate la stessa persona), per favore:
- sistema questa cosa degli utenti e usa sempre lo stesso. Consiglierei FlyHappy visto che hai già inserito la residenza
- evita di usare il tasto quote, soprattutto quando non è strettamente necessario: a che serve quotare un messaggio immediatamente sopra al tuo ?

il circuito con XOR e FLIP FLOP l'ho provato ma, come avevo detto, sull'inversione esiste un'incertezza ed è possibile perdere passi.
se mai farò una nuova versione del ELS utilizzerò sicuramente un STM32; questi micro hanno timer multi ingresso che possono leggere direttamente l'encoder senza bisogno di interrupt e senza impegnare la CPU, un altro mondo rispetto ad arduino.
Sistemerò (prima o poi) i vari bug che ci sono sulla attuale versione con arduino ma non implementerò nuove funzionalità perché ormai con la flash (e pure con la RAM..) siamo a tappo. Usare un altro micro per leggere l'encoder è una complicazione inutile, soprattutto se l'altro micro è sempre un ATMega (arduino): l'encoder va comunque letto con interrupt e il limite è la velocità del clock e di processamento dell'interrupt. Con i timer di STM32 il limite virtualmente non esiste...