Ho bisogno di un integrato che mi gestisca il segnale proveniente da un
> encoder incrementale. Ne ho trovato 1 ma in Italia è impossibile da
> reperire...
> Qualcuno ha qualche dritta?
Potresti usare un PIC appositamente programmato, costa molto meno degli IC dedicati però la frequenza massima in ingresso è limitata a pochi kHz. Se devi leggere frequenze molto alte allora occorre usare un IC dedicato oppure elettronica discreta (tanta). La soluzione è pure legata ad altre considerazioni, tipo se devi leggere solo avanti oppure avanti/indietro e se ti serve la quadratura.
Qui stiamo parlando di fare la quadratura di un encoder incrementale, operazione tutto sommato pesantuccia sul profilo software, dentro i pic non esistono periferiche integrate che possano essere di aiuto. Poi facciamo pure due conticini sulla velocità del pic, se prendiamo un classico 16xxx a 20MHz avremo 5mips di velocità, ovvero 5 milioni di istruzioni al secondo, che tutto sommato non è male. Poi facciamo due conti sui tempi di latenza dell'interrupt e scopriamo che tra invocarlo eseguire la prima istruzione del nostro programma e tornare al punto originale prima dell'interruzione si perdono circa 13us. Questo valore già di per se limita molto la massima frequenza gestibile in input da un pic, infatti siamo a poco più di 700 KHz, nell'ipotesi che bastino solo 4 o cinque righe per la gestione dell'input. Peccato che gestire una quadratura richieda diverse decine di righe (in assembler) pertanto ecco che nella migliore delle ipotesi (se sei molto bravo a programmare) arriviamo a gestire frequenza massime dell'ordine di
50-60 KHz, andare oltre è quasi impossibile se vuoi fare una quadratura vera con gestione del conteggio avanti e indietro.
P.S. Magari ci sono persone più brave di me che riescono a fare la quadratura di un encoder, gestendo anche l'output dei dati su bus I2C verso altri dispositivi, a frequenze maggiori ma finora non ho mai visto nessuno che ci sia riuscito.
Considerato che il 18f452 funziona a 40 Mhz (10 Mips) ed ha disponibile un pin di PORTB che serve le interrupt-on-change... Inoltre il tempo di latenza è certamente minore di 13 us (mi farebbe piacere sapere come lo calcoli ...) Sei arrivato facile a 70 Khz... (dicevi pochi khz, quanti 1 2 3 khz?) per un encoder ottico è una bella frequenza di rotazione ... forse un PIC è quello che occorre!
La frequenza dipende dalla velocita' e dalla risoluzione dell'encoder, se non specifichi questi dati qualunque discorso sulla frequenza non ha senso. Generalmente, per il controllo di motori si prevedono frequenze di almeno parecchie centinaia di KHz, per poter gestire anche le vibrazioni dell'asse. In caso contrario c'e' un errore che via via si accumula e puo' portare a risultati disastrosi.
">" ha scritto nel messaggio news:88EPa.29857$ snipped-for-privacy@news2.tin.it...
Mi sembra abbastanza sbagliato fare una cosa simile con un microcontrollore, considerando con una CPLD da mezzo dollaro si puo` arrivare tranquillamente a qualche decina di MHz. Basta un contatore bidirezionale:
[FIDOCAD] LI 155 29 157 30 LI 157 30 155 31 RV 155 20 185 70 LI 185 45 210 45 MC 210 45 0 0 073 TY 156 58 5 3 0 0 0 * u/*d TY 174 42 5 3 0 0 0 * out TY 142 14 5 3 0 0 0 * Contatore up/down MC 115 30 0 0 073 TY 110 20 5 3 0 0 0 * seno TY 110 51 5 3 0 0 0 * coseno LI 125 30 155 30 LI 125 60 155 60 MC 115 60 0 0 073
">" ha scritto nel messaggio news:bBTPa.20819$ snipped-for-privacy@news1.tin.it...
Allora non ho capito cosa intendi con "quadratura". In effetti "fare" la quadratura mi sembra un'espressione formalmente scorretta, i due segnali di un encoder relativo "sono" in quadratura (il che vuol semplicemente dire che sono sfasati di +/- 90 gradi a seconda del verso di rotazione).
Normalmente con l'espressione fare la quadratura di un encoder si indica l'operazione che legge il verso di marcia e dice di quanti step ti sei spostato, però moltiplica per quattro la risoluzione fisica dell'encoder perchè considera valida ogni transizione di stato dei due canali.
00
01
11
10
Come vedi dalla tabella sopra abbiamo quattro transizioni complessive considerando i due canali simultaneamente e non singolarmente come nel tuo circuito dove la risoluzione è unitaria, uno step ogni ciclo completo.
Si concordo sull'uso di CPLD o FPGA appositamente programmate, anzi nell'industria solitamente il problema si risolve proprio così. Purtroppo a livello hobbystico non tutti sono in grado di usare simili componenti e allora tocca andare su soluzioni alterntive quali possono essere i pic che per moltissime applicazioni possono andare benissimo e costano abbastanza poco. Il tuo nuovo schema è decisamente meglio ma ora conta solo il doppio degli impulsi, grazie all'xor, ma non il quadruplo come dovrebbe, la soluzione hardware completa è decisamente un pochino più complessa.
">" ha scritto nel messaggio news:dJ_Pa.36569$ snipped-for-privacy@news2.tin.it...
In realta` il mio circuito e` proprio sbagliato! Gli impulsi rilevati sono effettivamente quattro per periodo, ma il segnale della direzione non e` corretto. Occorre decisamente usare un rete piu` complessa, anche per considerare i casi delle inversioni di rotazione. Forse sarebbe utile usare un clock a frequenza piu` alta e fare un oversampling, usare i due segnali come clock potrebbe essere una brutta idea.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.