potenziometro o encoder

[dadduni]

vi aggiorno velocemente sullo stato dell'arte della faccenda, avevo un LCD 2x16 a casa che usavo appena ho iniziato con Arduino qualche anno fa, l'ho montato insieme al STM32 e ho scritto una mini libreria personale per la visualizzazione di stringhe e numeri. Si pone il problema della dimensione, purtroppo per stampare a video 5 parametri in contemporanea un 2x16 non basta e probabilmente neanche il 3x16 che ho qui a casa.
Tolto questo che si può risolvere comprando uno schermo più grande, mi rimane il dubbio sul da farsi

[GuidoB]

Io ti suggerisco di usare i "quadrettoni" per disegnare istogrammi (più è lunga la barra, più sei vicino al 100%).
Poi se riesci puoi farci stare anche le cifre della percentuale.

Un display grafico (comandabile pixel per pixel) sarebbe ancor meglio per quest'uso.

[lelerelele]

Si pone il problema della dimensione, purtroppo per stampare a video 5 parametri in contemporanea un 2x16 non basta e probebilmente neanche il 3x16 che ho qui a casa.

Se usi un LCD grafico tipo 12864, puoi scrivere tutti i valori che vuoi.

L'implementazione dell'encoder è sicuramente più ostica che l'uso dei potenziometri, (ne sto usando uno ed ottimizzarlo mi è costato fatica), sicuramente anche il costo complessivo ne risente maggiormente.

comunque è un buon progetto da realizzare anche a livello amatoriale.

saluti.

[dadduni]

L'implementazione dell'encoder è sicuramente più ostica che l'uso dei potenziometri

posso chederti il motivo? non li ho mai usati in progetti definitivi ma per prova ho interfacciato un encoder con il processore per incrementare/decrementare una variabile e non l'ho trovato ostico: una interrupt su un GPIO e nella routine si controlla lo stato dell'altro pin per ricaavare il senso di rotazione.
Sono convinto che mi stia sfuggendo qualche difficoltà pericolosa che non sto considerando, puoi consigliarmi?

[venexian]

... ho interfacciato un encoder con il processore per incrementare/decrementare una variabile e non l'ho trovato ostico: una interrupt su un GPIO e nella routine si controlla lo stato dell'altro pin per ricaavare il senso di rotazione.

A me non pare sia così semplice: con il metodo che hai descritto, nel caso della sequenza

a) 0 0
b) 0 1
c) 0 0
d) 0 1

se alla lettura 'b' hai un incremento, ne hai un altro anche alla lettura 'd', quando non dovresti averlo avuto.

Non è difficile leggere un encoder in quadratura, ma non è neppure così banale come lo hai descritto.

[lelerelele]

dadduni e venexian questa è la mia esperienza.

in questo periodo sto risolvendo appunto problematiche su una scheda che usiamo, una prima difficoltà sta nella lettura dei canali che sono sporchi, il primo encoder che ci hanno montato era un rottame, muovendo l'albero senza ruotare un contatto si apriva, questo portava inevitabilmente a vistosi errori di lettura.
detto questo ho trovato un encoder decisamente migliore, questo comunque ha bisogno come tutti i modelli meccanici di un filtro RC sui canali, i contatti anche se buoni possono avere autooscillazioni, ed una lettura con microcontrollore se non perfetta da errori vistosi su un semplice display, questo comporta l'uso di una rete che non sovraccarichi il contatto elettricamente, (lo danno per 5ma max), ed allo stesso tempo assicuri che il filtro sia buono in entrambe le rampe di discesa e di salita, questo filtro se troppo blando non eliminerà tutte le imperfezione del contatto, dando falsi incrementi, se troppo spinto impedisce il funzionamento in caso che si giri velocemente l'encoder.

Certo che partendo da un encoder ottico o magnetico il problema sarà di base minore, ma il costo che raddoppia ne rende l'uso in campo industriale limitato ad i casi essenziali.

detto questo è una buona tecnologia.

saluti.

[venexian]

... il primo encoder che ci hanno montato era un rottame, muovendo l'albero senza ruotare un contatto si apriva, questo portava inevitabilmente a vistosi errori di lettura.

Questo è un caso che non può essere considerato: se l'encoder è guasto non va utilizzato.

... ho trovato un encoder decisamente migliore, questo comunque ha bisogno come tutti i modelli meccanici di un filtro RC sui canali,

Non è vero.

... i contatti anche se buoni possono avere autooscillazioni, ed una lettura con microcontrollore se non perfetta da errori vistosi su un semplice display,

Indipendentemente dall'utilizzo che si faccia dei dati ottenuti dall'encoder, se il firmware è scritto in modo corretto, i rimbalzi di contatto (*) sono gestiti e non creano alcun tipo di problema.

... questo comporta l'uso di una rete che non sovraccarichi il contatto elettricamente, (lo danno per 5ma max),

Non serve alcun filtro, ma anche se fosse, un filtro progettatto con un minimo di logica non caricarebbe mai una sorgente di questo tipo con una corrente superiore a 5 mA.

... ed allo stesso tempo assicuri che il filtro sia buono in entrambe le rampe di discesa e di salita,

Ribadendo che il filtro non serve, se per rampe intendi i fronti del segnale, un filtro progettato correttamente non fa distinzione tra i fronti.

... questo filtro se troppo blando non eliminerà tutte le imperfezione del contatto, dando falsi incrementi, se troppo spinto impedisce il funzionamento in caso che si giri velocemente l'encoder.

No, non ci siamo. I ribalzi non devono essere eliminati analogicamente prima di entrare nel microcontrollore. La codifica in quadratura è nata proprio per essere insensibile ai rimbalzi dei contatti (*) e se il firmware da errori di conteggio a causa dei rimbalzi significa semplicemente che è il firmware ad essere sbagliato e non è un problema di encoder o di filtri (che non servono).

Certo che partendo da un encoder ottico o magnetico il problema sarà di base minore, ma il costo che raddoppia ne rende l'uso in campo industriale limitato ad i casi essenziali.

Il problema con un encoder ottico o magnetico è esattamente lo stesso: invece dei rimbalzi si ha l'incertezza attorno all'angolo di transizione che viene vista esattamente come i rimbalzi di un contatto meccanico.

Se il firmware viene realizzato come descritto in alcuni dei post precedenti, di sicuro risentirà del problema dei rimbalzi, ma solo perché non è stato realizzando comprendendo l'essenza della codifica in quadratura. Se il firmware è realizzato in modo corretto non perde un solo passo, qualsiasi sia la quantità e la durata di rimbalzi e/o incertezze in entrambi i segnali A/B.

(*) o incertezze di commutazione nell'intorno dell'angolo di transizione per gli encoder non meccanici.

[dadduni]

Se il firmware è realizzato in modo corretto non perde un solo passo,

Potresti spiegarti un po' meglio?
Grazie a tutti per le risposte, per motivi soprattutto didattici mi sto indirizzando ad usare l'encoder.
Davide

[venexian]

Il modo corretto di leggere un segnale in quadratura è quello di realizzare una macchina a stati in grado di seguire i passaggi tra le possibili combinazioni degli ingressi A e B.

Utilizzare il sistema con l'interrupt su uno degli ingressi non è la strada giusta. Il modo corretto è quello del polling degli ingressi, la frequenza del quale determina anche la massima velocità rilevabile. Sono sufficienti due bit da riservare alla variabile di stato della macchina e lo spazio desiderato per la variabile del contatore.

Qui a fianco del mouse ho un Atmel che legge un encoder rotativo con questo sistema: necessita di 38 cicli macchina più quanto richiesto dal conteggio, che è variabile in funzione alla dimensione della variabile del contatore. Con un micro a 32 MHz e un polling a 1 ms, occupa poco più dello 0,1 % delle risorse e può rilevare fino a 1000 impulsi al secondo, valore esorbitante per un'applicazione come quella di cui stiamo parlando.

[pusillus]

Qui c'è un bel tutorial:
http://embeddedsystemengineering.blogsp ... l.html?m=1