Finecorsa meccanico

Salve a tutti. Avrei una domanda da porvi: utilizzando un finecorsa meccanico, è opportuno realizzare un anti-rimbalzo via software o hardware?

si perchè si tratta comunque di un pulsante, sicuramente aiuta dopo diversi cicli

Il piu semplice, e che non porta via tempo allo sketch con i delay, e' una resistenza in serie (anche solo da 1K), con un condensatorino da 100nF in parallelo (fra pin di ingresso e massa)

Etemenanki: Il piu semplice, e che non porta via tempo allo sketch con i delay, e' una resistenza in serie (anche solo da 1K), con un condensatorino da 100nF in parallelo (fra pin di ingresso e massa)

se lo realizzo lato software sicuramente utilizzo millis()

Ma quindi ti serve SW o HW, non s'è capito ;)

Se SW, puoi realizzarlo in diversi modi. Se è un sistema di sicurezza, sicuramente un interrupt è la scelta migliore.

Altrimenti se è una semplice lettura di un pulsante durante l'azionamento pilotato di qualcosa, metti un codicino stupido stupido con un delay piccolissimo:

if (digitalRead(FINECORSA)) {
  delay(30);
  if (digitalRead(FINECORSA)) {
    .........
  }
}

Per una lettura singola che deve solo eliminare i rimbalzi è inutile andare a complicarsi la vita con una gestione di millis, a meno che non si debbano fare più letture separate da tempi più lunghi.

Dovendo realizzare dei controlli multipli simultaneamente ho utilizzato il seguente codice:

#define DELAY 10

int STATO = LOW;
long TIME = 0;

[...]

if((digitalRead(PIN)) != STATO)
{
  TIME = millis();
}
if((millis() - TIME) > DELAY)
{
  if(STATO == LOW)
  {
    STATO = HIGH;
  }else
  {
    STATO = LOW;
  }
}

è corretto?

Leo: sara’ che essendo un’hardwarista, a me non convincono i debounce software … ma mi chiedo sempre, indipendentemente dall’uso di millis o di delay, se le azioni da leggere sono molto veloci, o se gli ingressi da leggere sono tanti, non diventa una complicazione eccessiva, nello sketch ?

Intendo, metti di avere una ventina di ingressi e di doverli poter leggere anche se i cambi di stato sono molto ravvicinati, o se sono necessarie molte letture, non e’ tanto piu semplice infilarci resistenza e condensatore ed ignorare del tutto il problema a livello software, invece di doverci mettere una marea di controlli antibounce che alla fine, per quanto poco, un qualcosa di memoria ti portano via comunque ?

Etemenanki: Il piu semplice, e che non porta via tempo allo sketch con i delay, e' una resistenza in serie (anche solo da 1K), con un condensatorino da 100nF in parallelo (fra pin di ingresso e massa)

Ma è efficace? da molte parti leggo che non risolve del tutto.

nid69ita: Ma è efficace? da molte parti leggo che non risolve del tutto.

Dipende dal pulsante/interruttore/finecorsa che usi ... se genera rimbalzi per un tempo superiore alla costante RC del circuito, non e' piu molto efficace ... ma se hai uno switch che genera rimbalzi per cosi tanto tempo, la soluzione migliore e' fargli un bel funerale in mare (trad: "buttalo nel cesso" :P) e cambiarlo ... :P ;) :D

Io li uso dappertutto, e problemi fin'ora non me ne hanno mai dati ... unico accorgimento, ridurre il valore del condensatore se ci devi leggere cambi di stato molto veloci (ad esempio il micro di una macchina ripetitiva che scatta tipo un paio di volte al secondo, in quel caso meglio usare 22nF o anche 10nF ... e' tutta una questione di bilanciare il valore in base ai tempi, ma per pulsanti o finecorsa usati con tempi "umani", va piu che bene)

Etemenanki: Dipende ....

Thank you !!! E il metodo con IC appositi (oppure con flipflop, mi pare) , è eccessivo ?

Anche li, dipende tutto da cosa ci devi fare ... per circuiti "generici", l'RC e' piu che sufficente nel 99% dei casi, se invece serve per forza una temporizzazione molto precisa degli impulsi o dei fronti di salita ripidi, si possono usare anche i debounce "hardware", come il MAX812R e simili ... oppure usare i flip-flop (ma richiedono un deviatore) o i monostabili non-retriggerabili (che ti danno un'impulso di larghezza fissa), o anche semplicemente l'RC seguito da una porta schmidt, anche solo un 40106, che ne contiene 6, o 4093, che ne contiene 4, per "squadrare" i fronti, in caso l'ingresso non avesse un'isteresi per conto loro (gli ingressi di Arduino ce l'hanno gia)

Etemenanki:

Leo: sara' che essendo un'hardwarista, a me non convincono i debounce software ... ma mi chiedo sempre, indipendentemente dall'uso di millis o di delay, se le azioni da leggere sono molto veloci, o se gli ingressi da leggere sono tanti, non diventa una complicazione eccessiva, nello sketch ?

Intendo, metti di avere una ventina di ingressi e di doverli poter leggere anche se i cambi di stato sono molto ravvicinati, o se sono necessarie molte letture, non e' tanto piu semplice infilarci resistenza e condensatore ed ignorare del tutto il problema a livello software, invece di doverci mettere una marea di controlli antibounce che alla fine, per quanto poco, un qualcosa di memoria ti portano via comunque ?

Nel caso di più ingressi ti do ragione, gestire multi debounce in SW complica non poco il codice. Ma se devi leggere un semplice finecorsa una tantum un delay(30) basta e avanza.

Scusate se mi intrometto ma siccome sto facendo una cosa simile la domanda mi sorge spontanea. Io ho realizzato una protezione software, ma se introduco anche quella HW ci potrebbero essere problemi? Siccome non ho la minima idea di come potrebbe essere usato leggendo questo post mi è sorto il dubbio.

Quella HW esclude quella SW. Quest'ultima è infatti un ripiego in assenza della prima.

Comunque metterli entrambi non crea problemi, a limite si può dire che è inutile, ma non può creare dammi. Esempio se inizialmente hai dimensionato un debounce sw, mettiamo i 30msec di leo, e questi sono adatti al lavoro da fare, se dopo si aggiunge il debounce hw senza toccare il codice, questo non comporterà problemi

Diciamol in chiaro. Il debounce serve solo in casi dove un treno di impulsi (5 a 10 Volte cambio stato dopo aver premuto il pulsante) significa un cambio di stato del SW. Per un finecorsa questo non vale. Al primo segnale di intervento finecorsa il movimento del motore deve essere modificato. Non é significante che il finecorsa si apra e richiude ancora alcune volte. Percui un debounce sui finecorsa non é necessario.

Sul pulsante é diverso. Se il loop lo controlla nel tempo di rimbalzo lo interpreta come ripetutamente premuto e di conseguenza modific aripetutamente la direzione del motore. Qua un rimedio semplice é mettere un delay di 10mS dopo la lettura del pulsante.

Ciao Uwe

uwefed: Diciamol in chiaro. Il debounce serve solo in casi dove un treno di impulsi (5 a 10 Volte cambio stato dopo aver premuto il pulsante) significa un cambio di stato del SW. Per un finecorsa questo non vale. Al primo segnale di intervento finecorsa il movimento del motore deve essere modificato. Non é significante che il finecorsa si apra e richiude ancora alcune volte. Percui un debounce sui finecorsa non é necessario.

Sul pulsante é diverso. Se il loop lo controlla nel tempo di rimbalzo lo interpreta come ripetutamente premuto e di conseguenza modific aripetutamente la direzione del motore. Qua un rimedio semplice é mettere un delay di 10mS dopo la lettura del pulsante.

Ciao Uwe

Dipende in quale situazione si utilizza il finecorsa. Nel mio caso deve intervenire quando realmente è aperto, perchè anche solo 0,20 mm mi creano problemi (si tratta di una stampante 3D).

Il finecorsa si apre elettricamente quando viene azionato meccanicamente. I rimbalzi ci sono quando il contatto mobile si muove e incontra il contatto fisso. In quel momento a causa dela elasticitá del contatto mobile rimbalza e riapre il contatto. Se usi un NC il problema del rimbalzo non esiste perché il contatto non balza tra i 2 contatti (NC e NO) ma non resta attacato a quello dove deve arrivare.
Ciao Uwe