Arduino - Stöungen am Digitalen Eingang

Mark schrieb:
> Hallo zusammen,
>
> ich habe folgendes Problem:
>
> - Taster (Eingang) mit Widerstand wie überall ...

wie überall?
Also bei uns hier im Forum wird das (so gut wie) nirgends beschrieben. 
Wir hängen die Taster einfach so an. Taster schaltet nach GND und mit 
internem Pullup und der PeDa Entprellung kommt da so schnell nichts 
durcheinander.


> Hat jemand eine Idee?

Nimm eine ordentliche Entprellung, die auch kleine Störungen 
ausfiltert.

Ist der Taster denn entprellt?

MfG Benedikt

Mark schrieb:
> Zur Entprellung verwende ich die Bounce-Library welche auch
> funktioniert.

Funktionieren bedeutet nicht, nur bei schönem Wetter. Da findest du 
haufenweise Libs.

Die Spreu vom Weizen trennt sich erst, wenn das Signal mit Störungen 
behaftet ist, also im Praxiseinsatz. Und da findest Du nur wenige Libs, 
die auch wirklich was taugen.

Da niemand weiß, welche Lib Du meinst, gib mal einen Link zum Quelltext 
der Lib. Erst dann kann man sagen, ob sie wirklich funktioniert.

1

// Protected: debounces the pin

2

int Bounce::debounce() {

3

4

  uint8_t newState = digitalRead(pin);

5

  if (state != newState ) {

6

      if (millis() - previous_millis >= interval_millis) {

7

        previous_millis = millis();

8

        state = newState;

9

        return 1;

10

  }

11

  }

12

13

  return 0;

14

15

}

Da fehlt der else-Zweig.
Wenns nur ne Störung war, muß ja previous_millis wieder neu zählen.

Dater Pennegger schrieb im Beitrag #3064468:
> ...jetzt nicht gleich pingelig werden.

Huch, da ist aber jemand eingeschnappt.
Sei doch froh, daß ich den Fehler gefunden hab.

Pater Dennegger schrieb im Beitrag #3064489:
> Ich vermute den Fehler woanders. Aber danke...

Das kannst du schon vermuten.
Tatsache ist aber das diese debounce() Funktion Schrott ist.
Wenn die nicht in Zeitabständen kleiner als interval_millis aufgerufen 
wird, debounced sie nämlich gar nicht mehr.
Und wie Peter schon sagte: mit kurzen Störungen kommt sie auch nicht 
zurecht.

Kommt dann auch noch beides zusammen (Stichwort: Programm gespickt mit 
delays), dann kommen eben Spikes durch den Debouncer durch.

Dater Pennegger schrieb im Beitrag #3064468:
> ...jetzt nicht gleich pingelig werden.
>
> Ich würde eher mal schauen, ob der Arduino einen Reset macht, wenn der
> Lötkolben angeschlossen wird.

Ich denke, das wär ihm schon aufgefallen, wenn sein Zähler jedesmal 
wieder bei 0 anfängt zu zählen, wenn er den Lötkolben ein/aussteckt.

So blind kann er gar nicht sein, dass er den Unterschied zwischen 'fängt 
wieder bei 0 an' und 'zählt manchmal unmitiviert' nicht bemerkt.

Pater Dennegger schrieb im Beitrag #3064496:
> Es geht hier um Arduinos...was erwartet ihr?

Das sich wer aufrafft und den Arduino Systementwicklern eine Mail 
schreibt und ihnen sagt, dass ihre Debounde Funktion fehlerhaft ist. Von 
mir aus auch mit Hinweis auf dieses Forum, Dann erklären wir ihnen warum 
und was sie dagegen tun können.

Mark schrieb:

> Kann das überhaupt an dem Prellen vom Taster liegen? Beim Stecker
> rein-raus vom Lötkolben wird der Taster doch gar nicht betätigt...
> (sorry für die eventuell dumme Frage)

Dein Lötkolben verursacht irgendwas an der Versorgungsspannung, so dass 
am Eingang ganz kurze Spikes auftauchen.
Eine gute Debounce Library ignoriert derartige Spikes in der Annahme, 
dass ein reinkommender Puls der kürzer als x Millisekunden ist kein 
Tastendruck sein kann.
Deine Lib macht das nicht. Deine Lib akzeptiert jeden Pegelwechsel als 
Tastendruck, egal wie kurz und stellt sich danach für eine gewisse Zeit 
'taub'. Das reicht für Tasten, kann aber kurze Spikes nicht ausfiltern.

Mark schrieb:
> Hallo,
>
> also sollte ich mal eine andere Bounce Lib verwenden?
> Was wäre dafür dann die Empfehlung?

Du kannst ja den Code mal ein kleines bischen erweitern (wie PeDa schon 
vorgeschlagen hat)

1

int Bounce::debounce() {

2

3

  uint8_t newState = digitalRead(pin);

4

  if (state != newState ) {

5

    if (millis() - previous_millis >= interval_millis) {

6

      previous_millis = millis();

7

      state = newState;

8

      return 1;

9

    }

10

  }

11

  else

12

    previous_millis = millis();

13

14

  return 0;

15

}

Jetzt werden auch kurze Spikes ausgefiltert (btw. wie groß ist bei dir 
eigentlich die Intervallzeit eingestellt.)
Allerdings kannst du jetzt die Funktion duration nicht mehr benutzen. 
Ist aber, denke ich verschmerzbar.

> Delays verwende ich nur während der Rollomotor läuft. Sonst nicht...

Auch da solltest du sie nicht benutzen!
Delays sind oft das Problem, aber selten die Lösung. Und in deinem Fall, 
bei dem Zusammenspiel mit dieser Debounce Funktion, sind sie sogar ein 
großes Problem, weil sie die Unterdrückung von Spikes aushebeln. Diese 
Debounce Funktion MUSS in kurzen Zeitabständen aufgerufen werden, 
ansonsten kommt das ganze Zeitmanagement auf dem alles beruht 
durcheinander.

Mark schrieb:

> Gibt es von euch Experten eine Lib welche ihr empfehlen könnt?

Die wenigsten hier benutzen irgendwelche Arduino Libs. Wir programmieren 
selber :-)

> Bei den Intervallen hatte ich auch rumprobiert. Von 10 bis 200 hat sich
> nichts dabei verbessert...

Das kann auch jetzt noch so sein, solange du deine delays in der loop() 
nicht los wirst. Immer drann denken: Das Ausfiltern der Spikes 
funktioniert nur dann, wenn du diese debounce Funktion oft genug 
aufrufst. Tust du das nicht, dann Bye-Bye-Ausfilterung / Welcome 
sporadische Zähler

Mark schrieb:
> Hallo,
>
> aber ihr erfindet doch das Rad in Bezug auf das Bounce-Problem nicht
> jedesmal neu, oder? Könnte jemand von euch eine funktionierende Lib zur
> Verfügung stellen? Das wäre echt klasse...

Entprellung

> In der Loop selbst befinden sich keine delay's. Erst dann wenn der
> Taster betätigt wurde...

Ich feilsch jetzt aber nicht herum.
delay ist delay. Und der muss weg. Wozu brauchst du den delay überhaupt 
bei einer Rollladensteuerung?

Mark schrieb:

> Dazu messe ich die Zeiten von z.B. Position 1 bis Positio 2 und lasse
> dann den Motor dementsprechend lange laufen. Gleichzeitig merke ich mir
> die aktuelle Postion damit ich die Richtung einstellen kann.
>
> Die Anzahl der Tastendrücke werden innerhalb von zwei Sekunden gezählt.
>

Und wozu brauchst du da jetzt delays.

Der Arduino-Trick ist eigentlich immer der gleiche. Man merkt sich in 
einer Variablen den Wert von millis() zum jetzigen Zeitpunkt und 
vergleicht beim nächsten Aufruf von loop() ob diese Zeit schon 
abgelaufen ist. Bei dir kann man das abwandlen, dass wenn der Motor 
eingeschaltet wird, dann merkt man bzw. rechnet sich aus, wann er wieder 
abzuschalten ist, basierend auf dem Wert von millis(). Die erste Aktion 
in loop() besteht dann einfach darin diese Zeit zu prüfen (und 
nachzusehen ob der Motor gerade läuft) und wenn die Zeit drüber ist, 
dann wird abgeschaltet.

1

unsigned long stopMotorAt;

2

bool          motorRunning;

3

4

void loop()

5

{

6

  if( motorRunning && stopMotorAt < millis() )

7

  {

8

     Motor ausschalten

9

     motorRunning = false;

10

  }

11

12

13

  if( ....... irgendwas, was den Motor eine bestimmte Zeit lang laufen

14

      lassen soll )

15

  {

16

    stopMotorAt = millis() + 5000;   // Motor soll 5 Sekunden laufen

17

    motorRunning = true;

18

    Motor einschalten

19

  }

20

}

kein delay und trotzdem schaltet sich der Motor 5 Sekunden nachdem er 
gestartet wurde ab. Ja. Ist ein bischen aufwändiger als die banale

    einschalten
    warten
    ausschalten

Lösung, aber dafür funktioniert das auch immer und der µC kann auch noch 
andere Dinge tun (zb Tasten abfragen, zb Endschalter abfragen, zb den 
Motorstrom überwachen) anstatt einfach nur stupide im Schritt 'warten' 
mit den Däumchen zu drehen.

> Wie gesagt das Programm funktioniert so weit. Nur der "Lötkolben-Effekt"
> ist derzeit das Problem.

:-)
Also funktioniert es eben nicht.
'Funktioniert' bedeutet bei mir: unter allen Umständen. Einzig das 
Abschalten des Stroms könnte man vielleicht gerade noch geltend machen, 
warum ein µC nicht mehr seine Arbeit tut. :-)
Aber abgesehen davon, hat ein µC seine Aufgabe korrekt zu erfüllen.
Das bedeutet bei mir 'funktionier'.

Warum schrieb:
> Netzfilter, Abblock- Cs, Drossel, Erdung/
> Schirmung....?

Man kann sich dumm und dusslig filtern, ohne großen Effekt. MCs sind 
nunmal verdammt schnell, kein Vergleich zu früheren Relaissteuerungen.
20MHz filtert man nicht eben so einfach weg.

Ich hab auch ein älteres Gerät mit TTL-Steuerung, da ist schon die halbe 
Platine mit RC-Tiefpässen zugepflastert.
Sowas muß man sich heutzutage nicht mehr antun. Alles in Software kriegt 
man zum Nulltarif, also sollte man soviel wie möglich die Software 
erledigen lassen.
Jede Lötstelle, jedes Bauelement kostet aber und kann ausfallen. Eine 
SW-Lösung ist daher auch zuverlässiger.

SW läßt sich auch viel leichter testen, man läßt sie einfach im 
Simulator laufen und kann sich jeden Schritt ganz bequem angucken. Die 
Störungen emuliert man mittels Stimuli.

Der Simulator ist z.B. im AVRStudio dabei. Dazu muß man das Programm 
auch mit dem AVRStudio compilieren.

Die Stimuli muß man selber schreiben.
Man kann aber auch den Pin als Ausgang setzen und dann im Programm auf 
verschiedene Werte setzen, z.b. aus einem Array.