Drehencoder "Zwischen der Rastung"

Nein.

Wenn dem so wäre, würde es beim schneller drehen ja extrem auffallen.
Das ist aber nicht der Fall.

Regelrecht wenn ich den Encoder sehr langsam drehe, gerade dort wo er 
nicht einrastet. Das heißt ich drehe innerhalb der Rastung.

Richard B. schrieb:
> Jetzt ist mir bei einem Drehencoder aufgefallen, dass wenn ich ihn zu
> langsam drehe (wirklich langsam...) das er aufeinmal beide Richtungen
> erkennt.

Dein Encoder prellt.
Sowas ist normal.

Es gibt hier Leute, die auf Polling und softwaremäßige Entprellung 
schwören, aber ich gehöre nicht dazu.

Mein Rat wäre deshalb, den Encoder hardwaremäßig zu entprellen.

Das Einfachste ist ein 10..100nF Kondensator über die Kontakte.
Sowas hilft schon mal sehr. Wenn dann dein µC-Eingang auch noch 
Schmitt-Trigger-Verhalten kann, ist die Sache hardwaremäßig komplett 
erledigt.

Dann kannst du mit Interrupts arbeiten und bist mit dem Drehgeber fast 
völlig unabhängig von der Drehgeschwindigkeit. Ich mache das seit vielen 
Jahren so und bin's zufrieden.

W.S.

W.S. schrieb:
> Das Einfachste ist ein 10..100nF Kondensator über die Kontakte.

Die brennen beim Schließen des Kontaktes dann auch gleich die 
Kontaktflächen etwas frei.

Richard B. schrieb:
> Jetzt ist mir bei einem Drehencoder aufgefallen, dass wenn ich ihn zu
> langsam drehe (wirklich langsam...) das er aufeinmal beide Richtungen
> erkennt.

Ja, was soll der arme Kerl denn machen, wenn sich der Kontakt vom einen 
Kanal an der Schaltschwelle immer öffnet und schließt. Das ist doch 
völlig richtig, dass er dann immer vor- und zurück zählt. Schlimm wäre 
es, wenn der Wert dann in eine Richtung weglaufen würde.

Was du brauchst, ist eine Hysterese in deiner Richtungsauswertung, die 
verhindert, dass die Vor- und Rückzappelei an deinem Ausgang erscheint.

Richard B. schrieb:
> Das heißt ich drehe innerhalb der Rastung.

Nenn das Kind ruhig beim Namen.

Du eierst auf dem Schaltpunkt des einen Encoderkanals rum.

Kann ich die Hysterse auch in Software abbilden?

Richard B. schrieb:

> Kann ich die Hysterse auch in Software abbilden?

Scheinbar nicht, wenn du das fragen musst.

Falls die Frage eigentlich war: "Kann man die Hysterese auch in Software 
abbilden?", dann ist die Antwort: Ja, natürlich kann man das.

Wie bilde ich diese denn in Software ab?

Dafür habe ich die Tabelle angepasst.

1

.Table      = {0,0,-1,0,0,0,0,0,1,0,0,0,0,0,0,0}

wahrscheinlich falsch.
Es wird jedoch wenn ich normal drehe, nur +1 Incrementiert.

Musste gestern feststellen, je langsamer ich werde, desto mehr prellen 
die Kontakte...

Richard B. schrieb:

> Musste gestern feststellen, je langsamer ich werde, desto mehr prellen
> die Kontakte...

Das dürfte normal sein.

Bei hochwertigen Encodern ist die Phasenlage zwischen mechanischem Klick 
und elektrischem Schaltvorgang definiert. Der Schaltvorgang erfolgt an 
einer Stelle, wo die Kraft minimal ist, so dass man sich beim normalen 
Drehen dort möglichst kurz aufhält.

Bei Billigencodern ist die Zuordnung mechanischer Klick  <--> 
elektrische Kontakt undefiniert und exemplarabhängig. Ich hatte schon 
welche, die in der stationären Ruhelage geschaltet haben. Da reicht dann 
schon Trafobrummen um ausreichend Vibration zu erzeugen um Pulse zu 
generieren. Die Mark mehr für Alps oder Panasonic ist da schon gut 
investiert.


Optische Encoder (Grayhill, Copal, etc) sind nahezu prellfrei.

Richard B. schrieb:
> Musste gestern feststellen, je langsamer ich werde, desto mehr prellen
> die Kontakte...

Du verstehst die Funktion überhaupt nicht, wahrscheinlich auch weil du 
weder die Antworten hier noch Knowhow-Artikel dazu lesen willst. Die 
Kontakte mögen prellen oder auch nicht, an einem bestimmten Punkt 
schalten sie nun einmal um, das ist ihre Aufgabe. Und wenn man genau an 
diesen Umschaltpunkt positioniert, bewirkt eben die kleinste Veränderung 
das Umschalten; dass der Ausgang zwischen 0 und 1 hin- und herspringt 
ist also völlig normal auch bei prellfreien Schaltern. Da aber eine 
korrekte Auswertung dabei einen Schritt aufwärts zählt, beim 
Zurückspringen aber wieder abwärts, wird der Zählerstand nicht 
verfälscht.

Das Springen beim Umschaltpunkt kann nur durch eine Hysterese eliminiert 
werden, aber der Drehencoder kann keine mechanische Hysterese haben, 
daher muss die Hysterese in der Auswertesoftware realisiert werden. 
Sofern das Auf/Ab in der letzten Stelle überhaupt stört.

Georg

Wenn man 4 Widerstände und 2 Kondensatoren in SMD-Bauform "spendiert", 
erspart man sich langwieriges Anpassen des Programmes. So, wie das hier 
"Johnny SGT" getan hat:
http://www.mikrocontroller.net/attachment/297926/rot.png

Eine Hardware ist keine Lösung.
Wenn der Encoder an seinem Schaltpunkt schaltet, ist das seine Aufgabe.
Ein RC-Netzwerk gibt dieses Schalten auch weiter, muß es ja auch, sonst 
ist der Encoder sinnbefreit.
Wenn das Netzwerk das Umschalten weitergibt, wird immer ein 
nachgeordneter Zähler zählen. Soll er j auch.

Also hilft ein Netzwerl nix gegen das Schalten am Umschaltpunkt.

Das einzige was hilft: die Umschaltungen richtig interpretieren.

... Aber das überlassen die Spezialisten ja einem RC-Netzwerk. So wird 
das nix. Nicht heute und nicht zu einem anderen Zeitpunkt.

Jobst M. schrieb:
> Evtl. gibt es ja Stecksockel für den Drehgeber.
Eventuell gibt es auch Stänkerer.
> Der findet das nämlich
> nicht witzig, ständig den Kondensator kurz zu schließen.

Ich habe das in dieser Form bei > 10 Geräten mit den unterschiedlichsten 
Typen seit Langem im Einsatz. Es kümmert sie alle nicht im Mindesten, 
daß sie mit ihren Kontakten die beiden Kondensatoren kurzschließen.

HALT--
Ich muß mich korrigieren: Figure 2 auf der rechten Seite enthält die 
korrekte Schaltung, bei der die Kondensatoren nicht direkt an den 
Richtungskontakten liegen

http://www.dream-dimensions.de/2015/10/using-rotary-encoders/